Hi Mathieu! Mathieu Othacehe <[email protected]> writes:
> The problem here is probably caused by the "free-parted" procedure > returning before all the partitions are properly created by the kernel. > > You could maybe try to run a custom installer image with the hideous > attached patch to confirm this theory. I built a new installer image with the fix you provided and it unfortunately didn't resolve the issue. I did see the sleep occur after I confirmed the partitioning dialog, so the patch is definitely in place. I spent a lot of time on Sunday investigating this and I'm pretty confused as to why it's happening. It seems that for some reason `read-partition-uuid' is returning `#f' for one of my partitions in the installer but I'm not sure which one it is. Is it the case that it should only be looking at the partitions that I'm mounting? Take a look at these logs from a `guix repl' session (sorry for the image, couldn't copy text from that machine): https://0x0.st/-_no.jpg The two partitions that I'm setting as mount points in the graphical installer are: - /dev/nvme0n1p1: An existing vfat EFI partition created for the original Windows install on this machine - /dev/nvme0n1p6: A fresh ext4 partition that I created and formatted myself in the shell with `cfdisk' and `mkfs.ext4'. As you can see from the logs, both `read-partition-uuid' and `uuid->string' are both returning the expected outputs. I've double-checked the UUIDs with `cfdisk' and they match up perfectly. The reason why I think this isn't related to `free-parted' is because I'm not actually creating or changing any of the partitions in the partitioning page; the only setting I change is to set the mount point of /dev/nvme0n1p6 to `/'. The EFI partition is already detected and set to mount at /boot/efi. Any thoughts on what else I can try? I'm happy to try anything since I have a very reliable repro in front of me :) Thanks! David
