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

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 15 May 2021 03:34:02 +0000

Your bug report

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

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
44717: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=44717
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#44717: ISO grub config points to nonexistent drive UUID.
From: Maxim Cournoyer <[email-masked]>
To: Jesse Gibbons <[email-masked]>
Cc: Bengt Richter <[email-masked]>, Ludovic Courtès <[email-masked]>, [email-masked]
Date: Fri, 14 May 2021 23:33:06 -0400
List-Id: <debbugs-submit.debbugs.gnu.org>

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

Subject: ISO grub config points to nonexistent drive UUID.
From: Jesse Gibbons <[email-masked]>
To: [email-masked]
Date: Tue, 17 Nov 2020 21:56:32 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

On multiple computers, when I try to copy a custom operating system iso 
to an sd card and boot, the boot operation fails. Here's the output on 
one of the computers:

GC Warning: pthread_getattr_up or pthread_getattr_getstack failed for 
main thread
GC Warning: couldn't read /proc/stat
Welcome, this is GNU's early boot Guile.
Use --repl for an initrd REPL.

loading kernel modules...
waiting for partition '31393730-3031-3031-3139-333534353239' to appear...
waiting for partition '31393730-3031-3031-3139-333534353239' to appear...
waiting for partition '31393730-3031-3031-3139-333534353239' to appear...
[    5.044226] sd 0:0:0:0: [sda] No Caching mode page found
[    5.044336] sd 0:0:0:0: [sda] Assuming drive cache: write through
No file system check procedure for /dev/sda; skipping
ice-9/boot-9.scm:1669:16: In procedure raise-exception:
In procedure mount: Permission denied

Entering a new prompt. Type `,bt' for a backtrace or `,q` to continue.
GNU Guile 3.0.2
Copyright (C) 1995-2020 Free Software foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help\ for help.
scheme@(guile-user)>

When I type ,q or C-d I trigger a kernel panic.

This happens on at least three different computers:
- a lenovo ideapad s100 (intel atom, only successfully boots 32-bit 
image, output above)
- a laptop (unidentified brand) with an amd athlon-x2, only tried 64-bit iso
- an acer aspire one (cnet says intel atom), only tried 64-bit iso

I can confirm the lenovo successfully boots the i686 install iso 
(version 1.1.0) on the guix website and lets me see the info page on 
installing the system by hand, though the UI installer fails (most 
likely because the network hardware is disgustingly blobby).

I built the install image for i686-linux and flashed it to the sd card. 
It looks for the exact same partition and falls back on a boot guile repl.

$ guix describe
Generation 334    Nov 17 2020 17:52:52    (current)
   guix 129b9b1
     repository URL: https://git.savannah.gnu.org/git/guix.git
     branch: master
     commit: 129b9b16d9b588316cc997cf8f4fefe30961a417

I generated the iso with the command
`guix system disk-image -t iso9660 --root=installer.BaNl/install-x86.iso 
--system=i686-linux gnu/system/install.scm`
and flash the sd card with the command
`sudo bash -c "echo success" && time sudo dd if=install-x86.iso of=/dev/sdc`

When I inspect the GRUB menu, I see the option
--root=31393730-3031-3031-3139-333534353239
but in the gnome disk utility on my main laptop I do not see the above 
UUID in any of the partitions on the SD card I'm using, still with the 
freshly built install iso flashed onto it. Instead I see the UUIDs 
1970-01-01-19-49-46-83 for partition 1 and 3495-32E0 for partition 2.

Thanks,
-Jesse