GNU bug report logs - #29312
GRUB with multiple partitions with identical bzImage

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29312 in the body.
You can then email your comments to 29312 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vagrant Cascadian <vagrant <at> debian.org>
To: bug-guix <at> gnu.org
Subject: GRUB with multiple partitions with identical bzImage
Date: Wed, 15 Nov 2017 15:36:11 -0800

[Message part 1 (text/plain, inline)]

I've been exploring GuixSD for the past few days. Very cool! Even if a
little rough around the edges...

Ran into an ugly problem with GRUB being unable to load the initrd, due
to having multiple GuixSD installs on the same machine, with identical
paths for the bzImage files, but not identical paths for initrd files...

Confusingly, when I loaded the kernel+initrd by hand from the grub
commandline, it would work! But that was because I was specifying which
device to load from...


With some help from the folks on #grub on freenode (Thanks to TJ- and
Jordan_U!), we identified it was an issue with the way GRUB was
configured 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) 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).

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.


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
}

I'm not sure this is the best approach, as it could potentially load
kernel+initrd from an untrusted filesystem which may contain a malicious
kernel or initrd that simply matches the file paths...


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


live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 29312 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Vagrant Cascadian <vagrant <at> debian.org>
Cc: 29312 <at> debbugs.gnu.org
Subject: Re: bug#29312: GRUB with multiple partitions with identical bzImage
Date: Thu, 16 Nov 2017 15:30:22 +0100

Hey Vagrant,

Vagrant Cascadian <vagrant <at> debian.org> skribis:

> 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.

> 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 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")))

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?

> 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 that
it contains both the kernel and the initrd.  So I think the real
solution is for the first ‘search’ command to be appropriate.

Thanks for your report!

Ludo’.

Message #11 received at 29312 <at> debbugs.gnu.org (full text, mbox):

From: Vagrant Cascadian <vagrant <at> debian.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 29312 <at> debbugs.gnu.org
Subject: Re: bug#29312: GRUB with multiple partitions with identical bzImage
Date: Thu, 16 Nov 2017 08:13:05 -0800

[Message part 1 (text/plain, inline)]

On 2017-11-16, Ludovic Courtès wrote:
> Vagrant Cascadian <vagrant <at> 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!


> 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 would
also resolve the issue.


>> A quick workaround might be to also add a search line for the initrd
>> after loading the kernel:
...
> 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 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.


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


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 their
systems, so perhaps it's just me putting myself into a corner case. :)


> Thanks for your report!

Thanks for the prompt response and solution!


live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Message #14 received at 29312 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Vagrant Cascadian <vagrant <at> debian.org>
Cc: 29312 <at> debbugs.gnu.org
Subject: Re: bug#29312: GRUB with multiple partitions with identical bzImage
Date: Thu, 16 Nov 2017 22:50:00 +0100

Vagrant Cascadian <vagrant <at> debian.org> skribis:

> On 2017-11-16, Ludovic Courtès wrote:
>> Vagrant Cascadian <vagrant <at> 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.

> 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.

> 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?

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

Right.

> 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 handled
correctly.

Thank you,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.