Re: RFC: A partition for grubenv, etc.

[Michael Chang]

On Wed, May 26, 2021 at 08:36:05PM -0600, Chris Murphy wrote:
> On Wed, May 26, 2021 at 3:17 AM Michael Chang via Grub-devel
> <grub-devel@gnu.org> wrote:
> >
> > 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 (?).
> > >
> > > 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.
> >
> > The grubenv should be treated as property per grub.cfg, not per image.
> > This means that the grubenv partition may have to be divided into slots
> > to store settings for each and every grub.cfg, and then additional data
> > to record the change (add/removal) and identification - which sounds
> > like to work out a filesystem.
> >
> > So the question is why not use filesystem writable by grub for the
> > proposed grubenv partition ? For UEFI we already have one, the EFI
> > System Partition.
> 
> Upstream GRUB doesn't use this location. Distros who create and sign
> their own grubx64.efi (et al) OSLoaders may assume the grub.cfg and
> grubenv are in the same path as the *efi OSLoader, but I can't say
> whether this is common. Certainly it leaves out sufficiently common
> cases including all of BIOS which still represents most virtual
> machines even if not most new hardware, and suggests abandoning the
> entire "/boot on $nameyourfilesystem" approach. Fedora no longer keeps
> the primary grub.cfg on the ESP, it's moved to /boot with a static
> grub.cfg on the ESP that fowards to the real one. I thought (open)SUSE
> did this too. *shrug*
> 
> 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.

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

Thanks,
Michael

> 
> 
> -- 
> Chris Murphy
>