On Tue, May 25, 2021 at 04:58:23PM -0600, Chris Murphy wrote: Hi,
It's not possible for GRUB pre-boot environment to write to grubenv when it's on Btrfs, ZFS, LVM, mdadm raid, or LUKS. Also, at least XFS upstream is super skeptical of anything except kernel code making any kind of modification inside the file system region, and I suspect it's the same concern with ext4 developers too. While there are file system specific locations for bootloader usage, they're all different and quite small. XFS has none. ext4 has 512 bytes. Btrfs has maybe 1 or 2 MiB, ZFS (?), mdadm (?) and LVM (?).
Aren't most distro setups using EFI which in effect means GRUB has to deal most of the time with FAT32 file system? Does that work?
Also OpenZFS does have space and API to access area called “bootenv”. Data is stored there in nvlist structures, there is userland library (libzfsbootenv). From boot loader point of view, zfs module already does have ability to read nvlist packed data, to implement ability to read this data is not that hard. Updates are a bit harder because nvlist encoding needs to be implemented too.
wrapping this as storage based backend callbacks and implementing generic front end is a nice excercise;)
rgds, toomas Proposal: A new partition type for MBR and GPT, functionally a replacement for the BIOS Boot partition, but it would be a partition owned by the bootloader for whatever it wants to use it for. It'd be up to the bootloader to figure out how to segment it for bootloader and environmental portions. We definitely need both MBR and GPT partition types, it should be a partition exclusively reserved for the bootloader. This effectively deprecates the use of the MBR gap, and BIOS Boot partition types, and further it deprecates the use of file systems (all of them, for consistency sake) for the use of grubenv.
Variation: Keep BIOS Boot and repurpose it to include grubenv, while also specifying an MBR type code for its equivalent.
Use case: For example, Fedora has a "hidden grub menu" feature where by a variable in grubenv is reset (written to) by grub pre-boot. And then a systemd unit changes that variable to indicate a successful boot once some time and/or tests have been met. If grubenv indicates successful boot, the next boot's grub menu is hidden. If it wasn't successful the next boot's grub menu is displayed. It's only possible to achieve this with some reliable bidirectional way of communicating between the preboot and booted environments, which is the point of grubenv, but it can't work much of the time due to the above limitations.
-- Chris Murphy
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.orghttps://lists.gnu.org/mailman/listinfo/grub-devel
|