GRUB with multiple partitions with identical bzImage

Vagrant Cascadian wrote on 16 Nov 2017 00:36

Recipients:(address . bug-guix@gnu.org)

Message-ID:87mv3n2jys.fsf@aikidev.net

I've been exploring GuixSD for the past few days. Very cool! Even if alittle rough around the edges...
Ran into an ugly problem with GRUB being unable to load the initrd, dueto having multiple GuixSD installs on the same machine, with identicalpaths for the bzImage files, but not identical paths for initrd files...
Confusingly, when I loaded the kernel+initrd by hand from the grubcommandline, it would work! But that was because I was specifying whichdevice to load from...

With some help from the folks on #grub on freenode (Thanks to TJ- andJordan_U!), we identified it was an issue with the way GRUB wasconfigured to search for files:
menuentry "GNU with Linux-Libre 4.13.12 (beta)" { search --file --set /gnu/store/q9q8y9rh3jw1qcx6bic1v18qag80z74a-linux-libre-4.13.12/bzImage linux /gnu/store/q9q8y9rh3jw1qcx6bic1v18qag80z74a-linux-libre-4.13.12/bzImage \ --root=/dev/mapper/cryptic \ --system=/gnu/store/bsxnm36vvx2wxc9h3q5l8b5286gw75hr-system \ --load=/gnu/store/bsxnm36vvx2wxc9h3q5l8b5286gw75hr-system/boot \ initrd /gnu/store/7w9dzb6b9vb9gzj61zyqsg4zg6ys4hgb-raw-initrd/initrd}
I had two partitions, one on (hd0,msdos4) and one on (crypto0) whichboth contained/gnu/store/q9q8y9rh3jw1qcx6bic1v18qag80z74a-linux-libre-4.13.12/bzImage,and the search command was returning the one on (hd0,msdos4), and thussetting root (hd0,msdos4).
Unfortunately,/gnu/store/7w9dzb6b9vb9gzj61zyqsg4zg6ys4hgb-raw-initrd/initrd was onlypresent on the (crypto0) partition.
So, when it booted, I would get the confusing error message:
error: file `/gnu/store/7w9dzb6b9vb9gzj61zyqsg4zg6ys4hgb-raw-initrd/initrd' not found
And then a kernel panic, as there was no initrd...

The suggestion from the #grub folks was to use a UUID or some other morereliable method of finding the correct device to load the kernel andinitrd files from.

A quick workaround might be to also add a search line for the initrdafter loading the kernel:
menuentry "GNU with Linux-Libre 4.13.12 (beta)" { search --file --set /gnu/store/q9q8y9rh3jw1qcx6bic1v18qag80z74a-linux-libre-4.13.12/bzImage linux /gnu/store/q9q8y9rh3jw1qcx6bic1v18qag80z74a-linux-libre-4.13.12/bzImage \ --root=/dev/mapper/cryptic \ --system=/gnu/store/bsxnm36vvx2wxc9h3q5l8b5286gw75hr-system \ --load=/gnu/store/bsxnm36vvx2wxc9h3q5l8b5286gw75hr-system/boot \ search --file --set /gnu/store/7w9dzb6b9vb9gzj61zyqsg4zg6ys4hgb-raw-initrd/initrd initrd /gnu/store/7w9dzb6b9vb9gzj61zyqsg4zg6ys4hgb-raw-initrd/initrd}
I'm not sure this is the best approach, as it could potentially loadkernel+initrd from an untrusted filesystem which may contain a maliciouskernel or initrd that simply matches the file paths...

I'll look into a proper solution at some point, but it'd be fine ifsomeone beats me to it!

live well, vagrant

Ludovic Courtès wrote on 16 Nov 2017 15:30

Recipients:(name . Vagrant Cascadian)(address . vagrant@debian.org)(address . 29312@debbugs.gnu.org)

Message-ID:87a7zmfg8x.fsf@gnu.org

Hey Vagrant,
Vagrant Cascadian <vagrant@debian.org> skribis:

Toggle quote (15 lines)> menuentry "GNU with Linux-Libre 4.13.12 (beta)" {>     search --file --set /gnu/store/q9q8y9rh3jw1qcx6bic1v18qag80z74a-linux-libre-4.13.12/bzImage>     linux /gnu/store/q9q8y9rh3jw1qcx6bic1v18qag80z74a-linux-libre-4.13.12/bzImage \>           --root=/dev/mapper/cryptic \>           --system=/gnu/store/bsxnm36vvx2wxc9h3q5l8b5286gw75hr-system \>           --load=/gnu/store/bsxnm36vvx2wxc9h3q5l8b5286gw75hr-system/boot \>     initrd /gnu/store/7w9dzb6b9vb9gzj61zyqsg4zg6ys4hgb-raw-initrd/initrd> }>> I had two partitions, one on (hd0,msdos4) and one on (crypto0) which> both contained> /gnu/store/q9q8y9rh3jw1qcx6bic1v18qag80z74a-linux-libre-4.13.12/bzImage,> and the search command was returning the one on (hd0,msdos4), and thus> setting root (hd0,msdos4).

Oh.

Toggle quote (15 lines)> Unfortunately,> /gnu/store/7w9dzb6b9vb9gzj61zyqsg4zg6ys4hgb-raw-initrd/initrd was only> present on the (crypto0) partition.>> So, when it booted, I would get the confusing error message:>>   error: file `/gnu/store/7w9dzb6b9vb9gzj61zyqsg4zg6ys4hgb-raw-initrd/initrd' not found>> And then a kernel panic, as there was no initrd...>>> The suggestion from the #grub folks was to use a UUID or some other more> reliable method of finding the correct device to load the kernel and> initrd files from.

Indeed. You can force GuixSD to use a file system label or a UUID bydeclaring your file system with a label/UUID. So you would write:
(file-system ;; … (mount-point "/") (title 'uuid) (device (uuid "f549617a-07b0-430a-9723-36c43b98c748")))
or:
(file-system ;; … (mount-point "/") (title 'label) (device "my-root"))
When you do that, the generated grub.cfg searches the file system bylabel/UUID, which should be more reliable as you write.
Would that work for you?

Toggle quote (13 lines)> A quick workaround might be to also add a search line for the initrd> after loading the kernel:>> menuentry "GNU with Linux-Libre 4.13.12 (beta)" {>     search --file --set /gnu/store/q9q8y9rh3jw1qcx6bic1v18qag80z74a-linux-libre-4.13.12/bzImage>     linux /gnu/store/q9q8y9rh3jw1qcx6bic1v18qag80z74a-linux-libre-4.13.12/bzImage \>           --root=/dev/mapper/cryptic \>           --system=/gnu/store/bsxnm36vvx2wxc9h3q5l8b5286gw75hr-system \>           --load=/gnu/store/bsxnm36vvx2wxc9h3q5l8b5286gw75hr-system/boot \>     search --file --set /gnu/store/7w9dzb6b9vb9gzj61zyqsg4zg6ys4hgb-raw-initrd/initrd>     initrd /gnu/store/7w9dzb6b9vb9gzj61zyqsg4zg6ys4hgb-raw-initrd/initrd> }

The assumption is that there’s only one /gnu/store that matters and thatit contains both the kernel and the initrd. So I think the realsolution is for the first ‘search’ command to be appropriate.
Thanks for your report!
Ludo’.

Vagrant Cascadian wrote on 16 Nov 2017 17:13

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 29312@debbugs.gnu.org)

Message-ID:87k1yq2odq.fsf@aikidev.net

On 2017-11-16, Ludovic Courtès wrote:

Toggle quote (10 lines)> Vagrant Cascadian <vagrant@debian.org> skribis:> Indeed.  You can force GuixSD to use a file system label or a UUID by> declaring your file system with a label/UUID.  So you would write:>>   (file-system>     ;; …>     (mount-point "/")>     (title 'uuid)>     (device (uuid "f549617a-07b0-430a-9723-36c43b98c748")))

Yes, this fixed it for me!

Toggle quote (13 lines)> or:>>   (file-system>     ;; …>     (mount-point "/")>     (title 'label)>     (device "my-root"))>> When you do that, the generated grub.cfg searches the file system by> label/UUID, which should be more reliable as you write.>> Would that work for you?

Using UUID worked; didn't test using a label, but I imagine it wouldalso resolve the issue.

Toggle quote (2 lines)

>> A quick workaround might be to also add a search line for the initrd>> after loading the kernel:

...

Toggle quote (4 lines)

> The assumption is that there’s only one /gnu/store that matters and that> it contains both the kernel and the initrd. So I think the real> solution is for the first ‘search’ command to be appropriate.

Agreed.
For the record, spelling it out, apparently the issue wasn't searchingin each menu entry, but:
# Set 'root' to the partition that contains /gnu/store. search --file --set /gnu/store/0lwyzz8ayixwvdm1b3xhh26mlh0jz36b-grub-2.02/share/grub/unicode.pf2
Where it set the initial root.

After updating to mount by UUID, the corresponding search line became:
search --fs-uuid --set 1234ab-cdef-...1234ab
So it then only loaded files from the appropriate filesystem.

Since this is an issue caused by configuration, perhaps thedocumentation could clarify the importance of using UUID or filesystemlabels rather than raw devices:
https://www.gnu.org/software/guix/manual/html_node/Proceeding-with-the-Installation.html#Proceeding-with-the-Installation

I guess all of the install examples use labels:
http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/examples/

And I'm not sure how many people have multiple GuixSD installs on theirsystems, so perhaps it's just me putting myself into a corner case. :)

Toggle quote (2 lines)

> Thanks for your report!

Thanks for the prompt response and solution!

live well, vagrant

Ludovic Courtès wrote on 16 Nov 2017 22:50

Recipients:(name . Vagrant Cascadian)(address . vagrant@debian.org)(address . 29312@debbugs.gnu.org)

Message-ID:87y3n5c2rb.fsf@gnu.org

Vagrant Cascadian <vagrant@debian.org> skribis:

Toggle quote (13 lines)> On 2017-11-16, Ludovic Courtès wrote:>> Vagrant Cascadian <vagrant@debian.org> skribis:>> Indeed.  You can force GuixSD to use a file system label or a UUID by>> declaring your file system with a label/UUID.  So you would write:>>>>   (file-system>>     ;; …>>     (mount-point "/")>>     (title 'uuid)>>     (device (uuid "f549617a-07b0-430a-9723-36c43b98c748")))>> Yes, this fixed it for me!

Awesome.

Toggle quote (15 lines)> For the record, spelling it out, apparently the issue wasn't searching> in each menu entry, but:>>   # Set 'root' to the partition that contains /gnu/store.>   search --file --set /gnu/store/0lwyzz8ayixwvdm1b3xhh26mlh0jz36b-grub-2.02/share/grub/unicode.pf2>> Where it set the initial root.>>> After updating to mount by UUID, the corresponding search line became:>>   search --fs-uuid --set 1234ab-cdef-...1234ab>> So it then only loaded files from the appropriate filesystem.

I see.

Toggle quote (6 lines)

> Since this is an issue caused by configuration, perhaps the> documentation could clarify the importance of using UUID or filesystem> labels rather than raw devices:>> https://www.gnu.org/software/guix/manual/html_node/Proceeding-with-the-Installation.html#Proceeding-with-the-Installation

Currently it reads:
Preferably, assign partitions a label so that you can easily and reliably refer to them in ‘file-system’ declarations
What would you suggest?

Toggle quote (4 lines)

> I guess all of the install examples use labels:>> http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/examples/

Right.

Toggle quote (3 lines)

> And I'm not sure how many people have multiple GuixSD installs on their> systems, so perhaps it's just me putting myself into a corner case. :)

It’s arguably a corner case :-), but it’s better if it can be handledcorrectly.
Thank you,Ludo’.

Ludovic Courtès wrote on 16 Nov 2017 23:58

control message for bug #29312

Recipients:(address . control@debbugs.gnu.org)

Message-ID:87a7zlbzkx.fsf@gnu.org

tags 29312 notabugclose 29312

Your comment

This issue is archived.

To comment on this conversation send email to 29312@debbugs.gnu.org

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date