Re: RFC: A partition for grubenv, etc.

[Daniel Kiper <dkiper@net-space.pl>]

CC-ing a few folks who may be interested in this thread...

First of all, sorry for late reply but I am really busy. I hope I will
be able to reply in more timely manner starting from now.

On Thu, May 27, 2021 at 04:08:45PM -0600, Chris Murphy wrote:
> On Thu, May 27, 2021 at 2:59 AM Michael Chang <mchang@suse.com> wrote:
> >
> > On Wed, May 26, 2021 at 08:36:05PM -0600, Chris Murphy wrote:
> > > So is the next era going to be we recommend /boot on FAT?
> >
> > No. I meant a new partition type only for grubenv files and keep
> > everything else as is. The filesystem can be extX or FAT whichever is
> > writable by grub.  For efi, we probably don't need to define new
> > partition, as we can reuse the efi system partition.
>
> Or use the same partition for consistency instead of yet another exception?
>
> But also, GRUB strictly speaking doesn't write to any file system.
> It's overwriting a sector or two, no file system metadata is updated,
> hence the problem.
>
> > It is easier to handle in script as we only need to point to the new
> > writable location if available, the concern to admin is that we also
> > have to define mount point for linux (eg /boot/grubenv).
>
> That'd be three partitions needed by BIOS GRUB: BIOS Boot, grubenv,
> and /boot. Plus ~440 bytes on LBA 0, quasi-partition. Seems like a
> lot.
>
> What about a FAT formatted file system at /boot/grub and everything
> just lives there? Deprecate BIOS Boot, use blocklists instead. Grubenv
> partition proposal isn't needed, it can just stay where it is,
> unchanged and can be reliably written to. And whether UEFI or BIOS,
> grub looks to /boot/grub/ for all modules and configuration files?

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.

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.

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.

Daniel

[1] https://lists.gnu.org/archive/html/grub-devel/2020-03/msg00126.html