Proposed Enhancements to the EFI booting

[Mark Johnston]

On Fri, Aug 11, 2017 at 01:48:02PM -0600, Warner Losh wrote:
> > There is also a "bootme" GPT flag that is currently ignored when booting
> > using boot1.efi. We use it to avoid in-place upgrades: there are two
> > root filesystems, only one of which is mounted during boot. Upgrades are
> > done by installing the to-version of the OS to the inactive root
> > filesystem, flipping the "bootme" flag off on the active partition,
> > flipping it on on the inactive partition, and rebooting.
> >
> 
> Correct. EFI Boot Manager has a concept of profiles being active or not
> active. That's how this functionality will be implemented. There's no
> standardized notion of a partition being bootable or not. That's a FreeBSD
> extension. same with bootnext and bootfail flags.
> 
> So upgrades would become flipping the boot order in UEFI:BootOrder and/or
> toggling active on the two UEFI:BootXXXX variables. It just changes the
> command you need to issue from gpart <mumble> to efibootmgr <mumble>.
> 
> 
> > How should this interact with step 4 of your algorithm? Should we prefer
> > a GPT "bootme" entry over a filesystem on the same device as boot1.efi?
> 
> 
> No. We shouldn't. That duplicates functionality, and the flags bits we need
> to make these decisions are a pain to get to in boot1.efi. They are FreeBSD
> specific, but won't be carried forward since better functionality already
> exists in the BootOrder and BootXXX variables.
> 
> This is much more flexible as well, since it allows you to have multiple
> profiles that point to the same partition, but have different parameters,
> only one of which is active at any time, which is impossible with the old
> GPT scheme.

Ok, that's fine with me. I just wanted to point out that that
functionality is both useful and currently missing, so I'm glad that
there will be a replacement with a simple interface.