grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: A partition for grubenv, etc.


From: Daniel Kiper
Subject: Re: RFC: A partition for grubenv, etc.
Date: Tue, 26 Oct 2021 16:22:44 +0200
User-agent: NeoMutt/20170113 (1.7.2)

On Thu, Sep 23, 2021 at 08:59:14PM -0600, Chris Murphy wrote:
> On Wed, Jul 28, 2021 at 6:23 AM Daniel Kiper <dkiper@net-space.pl> wrote:
> >
> > At this point I am not fully convinced the /boot/grub should be on
> > a separate filesystem. Though after going through this thread it seems
> > to me we should add full write support to the GRUB for a simple file
> > system. The FAT looks like a good candidate. Does not it? This way we
> > will be able to support writable grubenv without any limitations and have
> > flexibility to add other writable files without bigger hassle if needed.
>
> On UEFI, the firmware's FAT driver should be write capable, but I
> don't know if GRUB can make use of it directly rather than using
> GRUB's own FAT driver?

IIRC it uses own driver. I am not sure at this point we can piggyback
on the UEFI FAT driver. If not we have to be sure both drivers,
the GRUB and UEFI ones, do not conflict with each other in some ways.

> On non-UEFI systems, we still need GRUB to have its own read-write
> capable driver. I think parity between BIOS and UEFI is important, but
> I'd also say if there's a faster/easier/more maintainable path with
> some other file system for other bootloaders, that'd be even more
> preferred. I don't know of such a file system. But UDF is in the same
> ballpark, long since supported in the kernel, supports optical,
> removable, hard drive use cases.

We can consider UDF too. Though FAT is much more common and I think we
should take it into account.

> > Additionally, it is worth mentioning the [1] work which adds a save_env
> > redirection layer. It allows us to choose target for grubenv. However,
> > if we want make it more generic then we could redirect any writes to any
> > target which can be potentially useful.
>
> Btrfs has two fairly large areas for exclusive bootloader usage,
> ~64KiB from partition start to the superblock. And ~1-2 MiB after the
> first superblock and before the first block group. But no other file
> system I'm aware of has such a large reservation for the bootloader.
> XFS has none. ext4 might have 512 bytes. I think it's valid to ask for
> an explicit reservation for bootloader usage, but this is just more of
> the same issue as grubenv and BIOS Boot. There is no file system in
> such a location so in effect it's up to GRUB to internally implement
> something, in which case it might as well just have a dedicated
> partition for grubfs or whatever it'd be.

I think we should use well know simple filesystem to write/store the
GRUB data. Coming up with own structure to store the data requires
maintaining this custom structure and write e.g. tools which checks and
fix their integrity. If we choose filesystem solution we have these
tools out of the box and they are maintained by others. So, (potentially)
less work for the GRUB folks... :-)

> > Last but not least, I think we do not need to change anything in current
> > partitions usage. In particular it seems to me the BIOS Boot Partition
> > usage should stay as is.
>
> I don't mind just retasking BIOS Boot into a  general "bootloader"
> partition that bootloaders can use. Or even make it explicitly a GRUB
> bootloader partition type GUID. It's better if each bootloader has its
> own? Originally BIOS Boot wasn't "owned" by GRUB, any bootloader can
> use it, but insofar as I'm aware it's the only bootloader that uses
> this partition type GUID.

I think the BIOS boot partition should stay as is and we should
introduce separate partition type called e.g. Bootloader data partition.
Then it should be formatted as FAT and have relevant directory structure,
e.g. the GRUB should store its data in /bootloader/grub directory.

Daniel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]