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

[David Wilson <david@daviwil.com>]

Hey Mathieu, thanks for looking into this!

Mathieu Othacehe <othacehe@gnu.org> writes:

> I fixed this issue with f5d9d6ec68f78f5651bd5a698f489ab57bf77d5d. The
> rationale is that any partition that will be mounted and not formatted
> ("Format the partition? No) must have a valid UUID. The installer
> now prevents going further if this is not the case.
>
> That said, I think you are experiencing a different issue. The REPL
> commands you ran show that your nvme0n1p1 and nvme0n1p6 partitions have
> valid UUIDs.

Your change seems to have exposed the real (and totally unexpected)
problem!  For some reason, the installer is trying to get the UUID of
a partition on my USB stick that contains the installer.

It seems that for some reason the installer has automatically picked a
mount point of `/boot/efi' for `/dev/sda2' in addition to the mount
points on my actual hard drive.  I now see an error dialog saying that
it can't retrieve the UUID of /dev/sda2 when I try to proceed past the
partitioning page.  If I clear the mount point for /dev/sda2, I am now
able to proceed to the page to with the generated system configuration!

At this point I think I should be able to proceed with making the
installation video I was working on, I'll just let viewers know that
they may need to clear that mount point if the same thing happens for
them.

> I'm not sure if you are aware of this feature, but generating
> uncompressed ISO9660 image is a serious time saver when debugging the
> installer:
>
> --8<---------------cut here---------------start------------->8---
> guix system image -t uncompressed-iso9660 gnu/system/install.scm
> --8<---------------cut here---------------end--------------->8---

I wasn't aware, thanks for letting me know!  Creating the image was a
lot faster this time :)

David