Re: BOOT LOADER IS TOO OLD. PLEASE UPGRADE.

On Sat, Aug 03, 2024 at 09:51:49PM -0600, Warner Losh wrote:
> On Sat, Aug 3, 2024 at 1:00 PM bob prohaska <fbsd@www.zefox.net> wrote:
> 
> > > 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 ???
> 

Probably start by asking the user. That at least lets him know what
to look for.

> 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?

If the admin executed a command intended to do just that, I don't see
why not. Nothing wrong with warning "I don't think you're gonna like
what happens next, are you sure?" 8-) Users who know enough to mess
with the system config _might_ know enough to help themselves.

> 
> Maybe I'm overthinking this, eh?
> 

Certainly not overthinking, but maybe perfectionist. Finding one
case that's popular enough to be useful and easily made fail-safe
seems like a somewhat more attainable goal. 

I suppose one approach would be to rank platforms by popularity
and then select the most common one(s) that boot compatibly. 

Thanks for explaining the nuances of the problem!

bob prohaska