Subject: Re: bug#44717: ISO grub config points to nonexistent drive UUID.

From: Maxim Cournoyer <[email-masked]>
Date: Fri, 14 May 2021 23:33:06 -0400

Hi,

I've unearth this forgotten issue (now fixed, thank you Mathieu!) from
my INBOX.  Sorry for failing to address myself at the time!

Jesse Gibbons <[email-masked]> writes:

> On 11/18/20 10:17 AM, Ludovic Courtès wrote:
>> Hi Jesse,
>>
>> Jesse Gibbons <[email-masked]> skribis:
>>
>>>> For example, if you pick
>>>> <https://alpha.gnu.org/gnu/guix/guix-system-install-1.2.0rc1.x86_64-linux.iso.xz>,
>>>> it boots just fine.  In the GRUB menu entry (type ‘e’ in the menu), you
>>>> can see both the DCE UUID for ‘--root’ and the ISO UUID for ‘search.fs’,
>>>> which are actually the same.
>> [...]
>>
>>> guix system disk-image -t iso9660 --root=$(mktemp -p /tmp -d
>>> install.XXX)/install-x86.iso --system=i686-linux
>>> gnu/system/install.scm
>>>
>>> and I mounted the ISO itself and took a look at it. The grub.conf
>>> specifies both UUIDs as you described.
>>>
>>> When I try it on a VM, it opens a repl with a completely different
>>> error which I'm too lazy to type out by hand. See attached screenshot.
>> Do you observe the same problem with the image I linked to above?  It’s
>> built with ‘guix system disk-image -t iso9660 --label=GUIX…
>> gnu/system/install.scm’.
>>
>> The error you sent looks as if it’s trying to mount the root file system
>> read/write.
>>
>> Thinking about it: does it work if you pass ‘--volatile’ on the
>> ‘disk-image’ command line?  This flag was added recently on ‘master’
>> (commit 41f27bf8702838f19b1dc5ffee8eec1d4315d4e6), so perhaps what
>> you’re seeing is a regression here.
>>
>> Maxim, could it be that we need (volatile-root? #t) for the ISO9660
>> image type and/or passing ‘--volatile’ in Makefile.am (‘release’ target)
>> and updating the “Building the Installation Image” node of the manual?
>>
>> Thanks,
>> Ludo’.
> Passing --volatile to the iso build command fixes the issue with the
> VM. I'm flashing an the resulting to my external drive right now. In a
> few hours, I should be able to test if the problem was that the drive
> didn't fully sync, and hopefully we can close this issue tonight.

For the record, this was fixed by Mathieu by special-casing the ISO9660
so that it always has the volatile-root? property set to #t in commit
83de7ee662fd42cce410dd8c395922647f3aeb13.

Thanks,

Maxim