GRUB with multiple partitions with identical bzImage

  • Done
  • quality assurance status badge
Details
2 participants
  • Ludovic Courtès
  • Vagrant Cascadian
Owner
unassigned
Submitted by
Vagrant Cascadian
Severity
normal
V
V
Vagrant Cascadian wrote on 16 Nov 2017 00:36
(address . bug-guix@gnu.org)
87mv3n2jys.fsf@aikidev.net
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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEcDardHbDotegGFCHt4uC1IFLkbYFAloMz2sACgkQt4uC1IFL
kbbm8g/9Fn2e9lel8TInwxoGwWc/x3nW6Djj3WA09OaQ6vuGM6MiEbCPHXP+aY9O
Tm4/8URZ+S5h5Yt+ybkmJfO6sVyRxC+/2QiVOnfsHuAgFgSR5Ev97XpGNEF5Se7F
mJ7SL2v+dpiHI823EkvOp4GOuDG4OnvdMQyDs35WY3kqQPOpWDdK34sFLCOSLeby
mPuwqPEnzTqnYVQhd4fZgqyBEr4jeSJNZAuVE9AbXYVYNqaiHSTr0czUTj0ZXdz/
xa+3ldcuGE6sWFvnEPzSw2zjMndrxNKwTewvmHKjFzztt8mEdEht0B0TqvAz6bxw
2SGR7OrG7STuC9jHoGAJiYCJKhmECLKxdvZnIXwfb//LoFGX1Yk4fkGAYbX4RCN7
MQdvyM4mv9ok0et4m5IauDBH9mE6D+wY8GEDbWgazBnK8GFGqNbABE5XKIaB1vNm
S+yxIsx9+Oi35hmGDASSukPhDAQvNRKxPgqkhBNgigWrbSGQjc3TdMJTwoRN8pKo
0UBCmWDlLD5GqgGoqALnpeugqPt1ojMo42HqYC099fdFvpsdS2YDXLC/iTonL/B3
8tGQSaRCPOvjZRgVTf7XsnJLcnMB8hXsgh//WqpKs598Ls2RMz97fZVU3rFficyd
imI5+oftFcSay9obBo4QiKT74xcopMHPIFh+gx2gZLJ299PbQ/o=
=mYEj
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 16 Nov 2017 15:30
(name . Vagrant Cascadian)(address . vagrant@debian.org)(address . 29312@debbugs.gnu.org)
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 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?

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 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’.
V
V
Vagrant Cascadian wrote on 16 Nov 2017 17:13
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 29312@debbugs.gnu.org)
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 would
also 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 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:



I guess all of the install examples use labels:



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


Toggle quote (2 lines)
> Thanks for your report!

Thanks for the prompt response and solution!


live well,
vagrant
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEcDardHbDotegGFCHt4uC1IFLkbYFAloNuREACgkQt4uC1IFL
kbYpuQ//UEFt1S65YVLfzDNoL4TauCFeio9tgm8S+gzP6VKk3Kz+QKHD87JrP2hE
r0MQ8ubucrfmuVQDEC9Ncu+KwVeuikZVzcUoNIKDRa3GwRe1U+Hy3AStlti8BB38
Ki0iV9jKqURjtVgU4hZB/D+15ketXDMJdqdF0WB+AzBePFfnrDmk2TdJnvG9aOFD
DT8rK0iU0nSyfW4C8vy4dDfnAfxfYsHquHOGoJQYSo6mnTVTirB/U86qS81gHtLv
NbwPVJGFFVhK/wYsqPCrbRPguos8QxWfxHDzVI9arZpOmkdm4V5kXlQ649GVM/f2
468jhpAl0AsObAI0JvvCXbwHXI3MzWRvHyY8kunmvRjVbn4iekg6Ddcr5ol6PYPs
e6UpAH43cF6cgGnwR6wE5i34LW2aIrsP/6O7JMtucOrBTlt20QMuaAyyrdY1dDg2
zi7yykAhE2wX9ujFkCinJI/SpxdusnX1p+3J5lvALz8mS4KPHTFeGg8ZJGu67CGX
OHsv36aV0X+SPT62GVY2zAXhbHriX199GBbERX6RQ47A3LckxlyNBm+oaISF5OAv
92XflBYVsEk+gxhuCx4zZNSrOxX2rC+gTygWfhAb05Dpo28nUBQR/+15OktriNnR
sKijsw00XE3c1EuI5juzZcS9zqaV4VSNvEBZmJnc3jVeVPF4CDQ=
=hhj3
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 16 Nov 2017 22:50
(name . Vagrant Cascadian)(address . vagrant@debian.org)(address . 29312@debbugs.gnu.org)
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 handled
correctly.

Thank you,
Ludo’.
L
L
Ludovic Courtès wrote on 16 Nov 2017 23:58
control message for bug #29312
(address . control@debbugs.gnu.org)
87a7zlbzkx.fsf@gnu.org
tags 29312 notabug
close 29312
?
Your comment

This issue is archived.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 29312
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch