bug#44872: Installer crash: 'uuid->string' is passed #f in lieu of a UUID

[David Wilson]

Hi Mathieu!

Mathieu Othacehe <othacehe@gnu.org> 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