bug#29312: GRUB with multiple partitions with identical bzImage

bug#29312: GRUB with multiple partitions with identical bzImage

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 2879 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#29312: GRUB with multiple partitions with identical bzImage

[Ludovic Courtès]

Hey Vagrant,

Vagrant Cascadian <vagrant@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’.

bug#29312: GRUB with multiple partitions with identical bzImage

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 2292 bytes --]

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!


> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#29312: GRUB with multiple partitions with identical bzImage

[Ludovic Courtès]

Vagrant Cascadian <vagrant@debian.org> skribis:

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

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