Discussion:
grubenv vs. diskfilter
(too old to reply)
Andrey Borzenkov
2013-06-03 04:48:18 UTC
Permalink
While grub itself can be installed on diskfilter devices (LVM, Linux
MD, ...), diskfilter devices are read-only. As grubenv is automatically
assumed to be in /boot/grub, this makes it impossible to set variables
from within grub. So grub cannot reset boot once indicator, cannot save
currently selected menu entry etc.

Just looking for ideas here. Thank you.
Phillip Susi
2013-06-18 18:57:04 UTC
Permalink
Post by Andrey Borzenkov
While grub itself can be installed on diskfilter devices (LVM,
Linux MD, ...), diskfilter devices are read-only. As grubenv is
automatically assumed to be in /boot/grub, this makes it impossible
to set variables from within grub. So grub cannot reset boot once
indicator, cannot save currently selected menu entry etc.
I've been kicking around the thought that grub-pc should just put
grubenv in the embed area attached to the core img, and grub-efi
should put it in the ESP. That would solve grubenv not working on
btrfs too.
Andrey Borzenkov
2013-06-19 06:31:21 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Andrey Borzenkov
While grub itself can be installed on diskfilter devices (LVM,
Linux MD, ...), diskfilter devices are read-only. As grubenv is
automatically assumed to be in /boot/grub, this makes it impossible
to set variables from within grub. So grub cannot reset boot once
indicator, cannot save currently selected menu entry etc.
I've been kicking around the thought that grub-pc should just put
grubenv in the embed area attached to the core img, and grub-efi
should put it in the ESP.
This still leaves the case when core.img cannot be embedded (and
adding extra space obviously increases chances of that) or delilberate
blocklist installs (openSUSE defaults to booting from partition). And
we still have PPC, SPARC and hopefully ARM to handle.

And we need some way for user space to auto-detect where environment
block is located ...
That would solve grubenv not working on
btrfs too.
Does btrfs guarantee that bootloader area is always located on a
single physical device?
Phillip Susi
2013-06-19 15:34:01 UTC
Permalink
Post by Andrey Borzenkov
Post by Phillip Susi
I've been kicking around the thought that grub-pc should just
put grubenv in the embed area attached to the core img, and
grub-efi should put it in the ESP.
This still leaves the case when core.img cannot be embedded (and
adding extra space obviously increases chances of that) or
delilberate blocklist installs (openSUSE defaults to booting from
partition). And we still have PPC, SPARC and hopefully ARM to
handle.
Blocklist installs already are unsupported and have plenty of
problems, including not working with diskfilter. They should still be
able to work with grubenv in a regular file on a plain ext4 regular
disk partition.

As for embed size, there are really only two classes in practice: 2048
sector, which has plenty of room, and 63 sector, which already doesn't
fit for non trivial configurations including diskfilter.
Post by Andrey Borzenkov
And we need some way for user space to auto-detect where
environment block is located ...
Stick a pointer to the location in the grubenv file?
Post by Andrey Borzenkov
Post by Phillip Susi
That would solve grubenv not working on btrfs too.
Does btrfs guarantee that bootloader area is always located on a
single physical device?
Not sure what you mean.

Continue reading on narkive:
Loading...