Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)

On Sat, Jan 19, 2019 at 9:32 AM Rodney W. Grimes <
freebsd-rwg_at_pdx.rh.cn85.dnsmgr.net> wrote:

> > On Sat, Jan 19, 2019 at 9:00 AM Rodney W. Grimes <
> > freebsd-rwg_at_pdx.rh.cn85.dnsmgr.net> wrote:
> >
> > > >
> > > > On January 19, 2019 at 2:52:28 AM, Lev Serebryakov (lev_at_freebsd.org
> > > (mailto:lev_at_freebsd.org)) wrote:
> > > >
> > > > > I have never seen such item in BIOS Setup. I've checked two MoBos
> now
> > > (one is
> > > > > Supermicro X9something and other is brand-new Goldmont-based
> Chinese
> > > MiniPC
> > > > > like Intel NUK): both have one knob in setup about boot type
> > > > > (Legacy/UEFI/Auto) and if UEFI is selected, Supermicro MoBo (but
> not
> > > Chinese
> > > > > one) could be booted to "UEFI Console" which is not documented
> > > anywhere.
> > > > >
> > > > > Ok, I've checked my desktop Asus Z170-A, but it is graphical and I
> > > could
> > > > > not find or understand anything in this home-rown UI with
> crazy-fast
> > > mouse.
> > > > >
> > > >
> > > > On ASUS systems you normally press F8 during POST to bring up the
> boot
> > > menu, and F11 on Supermicro systems.
> > >
> > > ASUS should learn to put that stuff on screen... like everyone else.
> > > I've been hitting the delete and going to the bios/boot tap which
> > > also has a boot selection screen on one of my machines because I
> > > did not know F8 existed.
> > >
> >
> > I've been generally reluctant to add old-style boot0 selection to UEFI
> > stuff. The BIOS already does it, so we don't need to. I've not needed it
> at
> > all.
>
> The BIOS does NOT do what our boot0 does, I have seen no BIOS that
> well allow me to select a partition on a drive, you can only select
> the drive.
>

True, but you need more than knowing which partition to boot from with
UEFI. Sadly, it's no longer that simple for multiple partition setups. UEFI
knows how to boot the primary loader (our boot1.efi or loader.efi), but
from there there's no standard way to tell how to select from multiple
different notions. I've created a standard for FreeBSD (which is what each
OS is supposed to do), but making it happen is tricky as you somehow have
to know which of several options you want to use. There's several ways to
do this in FreeBSD, but they aren't super easy (if you get to the loader
prompt, you can set anything to boot there).


> I think this is the feature that Lev is missing, and I am sure
> others shall miss it to.
>
> IIRC whistle used a version of this so you could install a new system
> to partion 2, keeping your current system in partion 1, and changing the
> active back and forth.  If we have lost that basic functionality with
> the growth of GPT and UEFI that is a sad day.
>

If you set it up properly, that's trivial to do. We do it all the time at
Netflix. Most of the changes I made to loader.efi was to make this
possible, regular and easy.

> However, we start the boot in lua. We already allow an interruption of
> > loader.efi, so it would be super easy (assuming we got the lua bindings
> > right) to implement something that would show you all the BootXXXX envs
> and
> > let you select one to boot instead. We already have the ability to
> > interupt the boot loader. It would also be trivial to implement a
> 'efiboot
> > XXXX' command to give that to you in cli mode. Both would set BootNext to
> > XXXX and exit. We already have a menu, we could just add it to that. This
> > would solve the hassles people are having with their BIOS (either because
> > it's incomplete or hides the functionality too well) and would obviate
> the
> > need to make boot1.efi do the selection (which has issues of its own due
> to
> > boot1's limited scope).
>
> Loader and such is far too late... as part of what the boot0 mbr gets you
> around is when your loader in the new partition is what is stopping you
> from getting booted because it got screwed up.
>

In UEFI land, this is handled by the UEFI shell or the BIOS. It's a
fundamentally different environment where /boot/loader.efi is not too late.
In UEFI your primary loader lives on the ESP and is responsible for getting
the rest of the OS running. If you just want to boot FreeBSD, it's plenty
sophisticated to boot any bootable FreeBSD partition by setting currdev to
the right value and reloading the kernel. If you want to boot another OS,
however, you'll need to slot into the standard UEFI stuff, which is setting
up a boot variable and telling UEFI to use it instead of what you just
booted (which is what we can't do today: we can't set BootNext and then
exit the boot loader).

All the functionality that used to be in mbr has moved into the BIOS. The
bootstrap has gone from "read this one block from location 0" to "read this
file from this FAT partition and pass it this extra goo". We are an
imperfect fit into that now, I won't deny. We're closer to being not a
terrible fit than we have been in the past, but we have a ways to go. But
to get there, we have to stop thinking MBR-ly and start thinking UEFI-ly.

Warner


> > The only drawback here is that we'd not be able to create new boot envs
> in
> > the loader, or you'd need to create a new one if you haven't yet run
> > efibootmgr(8), but if that's really an issue, someone will write code to
> > cope.
> >
> > Warner
>
> --
> Rod Grimes
> rgrimes_at_freebsd.org
>