Re: BOOT LOADER IS TOO OLD. PLEASE UPGRADE.

From: Warner Losh <imp_at_bsdimp.com>
Date: Sun, 04 Aug 2024 03:51:49 UTC
On Sat, Aug 3, 2024 at 1:00 PM bob prohaska <fbsd@www.zefox.net> wrote:

> On Sat, Aug 03, 2024 at 08:47:54AM -0600, Warner Losh wrote:
> > On Sat, Aug 3, 2024, 8:28 AM bob prohaska <fbsd@www.zefox.net> wrote:
> > > Is there some reason installworld (or some other make target) doesn't
> > > do this by default? The msdos filesystem is mounted and writeable any
> > > time the host is running.
> > >
> >
> >
> > I have the doodle of a design to have a make installboot that would do it
> > based on parameters set for their system. But i got bogged down when
> uboot
> > and powerpc ofw got into the mix.
>
> Could the problem be made less intractable by limiting the scope per
> board or board family? I've not played with any but Raspberry Pi in
> the past 9 years so have little idea what's in use today.
>

Well, not really...

But writing one for just UEFI isn't terrible for the typical case. We set
loader variables in EFI variable space to say what the loader was. So
we can look at them to see. We can translate the path to the actual ESP
that was updated, and we can know the full path to the last booted thing.

But... there's a fair amount of variation even in that. Some safeguards
are needed. We know the path of what booted, but we don't necessarily
know what the .efi file in FreeBSD is that needs to be copied over. And
that's before we have the 'old bootloader' from FreeBSD 11 or earlier
that doesn't have a big enough ESP to do the upgrade. Most of these failure
cases though we just need to fail-safe: Sorry, you can't upgrade
automatically.

Really old loaders don't set the variables, So we'd have to fall back to
looking
at efibootmgr -v to work it out.

armv7 and some systems that don't have efi will both have problems,
since we can't get the efi variables we want. So do you puzzle out
these, or ???

And finally, even if we know exactly what to upgrade and where, there's
several people that have mirrored setups, exiter explicitly or implicitly.

So should a uefi-update handle some or all of these cases? With or without
explicit fallbacks? Should unmounted ESPs be mounted for a minute to do
the update?

Maybe I'm overthinking this, eh?

Warner

p.s. the uboot stuff was even more of a convoluted mess.