loader.efi architecture for replacing boot1.efi

[Warner Losh]

On Sat, Dec 16, 2017 at 8:31 AM, Eric McCorkle <eric at metricspace.net> wrote:

> On 12/16/2017 00:49, Warner Losh wrote:
>
> > CD/DVD booing won't break. We'll still load a kernel from them. No
> > boot.config needed for this case (though it might be for others).
>
> How is that possibly going to work for a liveDVD on a random system?
> People expect it to "just work" (meaning, it correctly guesses the
> kernel, then loads it).
>
> I can see it working with boot.config (which I'd be fine with), but if
> we don't search the CD drives, there's no way it can work.


And it will. It booted off the CD device, and will search the CD device
(and only the CD device) for the kernel. It will find it there. How could
that not work?


>
> >     But for now, loader.efi has got to work whether installed
> >     in a boot1/loader (legacy) configuration, or installed directly to
> the
> >     ESP.  Otherwise, there's going to be a lot of unhappy people out
> there.
> >
> > Correct. My proposed behavior will do just that, and if we get it wrong
> > by default (a) you can be explicit with boot variables or (b) you can
> > type something into the OK prompt, which you didn't have before.
>
> No, I'm talking about people with existing installations, which still
> have both boot1 and loader.efi.  A change this big needs to be phased in
> over time, which means both modes of operation need to be supported for
> a while.


Unless they have a totally whacked out system, the proposed thing that I'm
suggesting will just work for them.

If they are booting with multiple disks where /boot/loader comes from a
different disk than the boot disk, they will have to do something to
configure it. The number of such people is likely zero given how fragile
this setup is (it breaks when you plug in a thumb drive with a release on
it, for example).

>     As for the fallback search, it's just that: a fallback mechanism.  Its
> >     job is to make a sane guess as to where to find the system, but
> >     ultimately it's not doing anything the user can't do themselves.
> And it
> >     will only run if the EFI vars aren't set anyway, so it can't possibly
> >     interfere with any of that.
> >
> >
> > And the fallback mechanism of typing what you want is wrong because?
>
> Because every single person out there with an install is going to
> suddenly have to type, and that's going to lead to a whole bunch of
> people saying we broke loader.


I maintain no such people will have to do that. The UEFI BIOS is required
to set BootCurrent and BootXXXX. However, even in the absence of this,
we'll look for a ZFS pool (and disks) or UFS partition on the same disk.
This should generally work by default.


> > But it's job isn't to guess. If we don't know for sure what to boot, it's
> > our job to fail so the next OS in the list gets a shot at booting.
>
> That won't happen though.  If loader fails to find an installed system,
> it drops out to a prompt, but it doesn't exit.  Given that, it makes
> sense to make an effort at finding an installed system.
>

No. It doesn't. You're assuming that if we fail, the system won't boot.
That's false. If we fail to boot device X, it's our job to fail so that if
there's a Y or a Z it can be next. We have no knowledge of whether the user
would prefer Y or Z as the next one to try, but the boot manager that runs
inside every single UEFI firmware does and it will go to the next one. Y
might be a recovery disk or copy of a freebsd memory stick release and Z
might be a redundant copy of X to use in cases where X fails. Or vice
versa. Do we want to boot to the installer? Not as a first choice, but
maybe as a last resort. But we should let UEFI orchestrate the retries.
Trying to second guess is fundamentally wrong, especially in UEFI where the
boot order and boot recovery stuff is so extensively and particularly
defined. Having fought the "oh, I'm going to guess" code in boot1.efi for
over a year and after having it consistently pick the wrong thing to boot
on some tiny fraction of the hundreds of systems I've had deployed give me
strong empirical data that shows the guessing too hard bit is actually
actively harmful. I've thought about this a lot. I've thought through all
the supported scenarios. I've written up documents and solicited feedback.
Nobody to date has said "oh no! I really want the random installed system
roulette! I love it! Don't kill it."

Warner