Date: Sun, 4 Aug 2024 15:21:42 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Warner Losh <imp@bsdimp.com> Cc: Mark Millard <marklmi@yahoo.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: BOOT LOADER IS TOO OLD. PLEASE UPGRADE. Message-ID: <Zq_-9nYcudCuwZ7U@www.zefox.net> In-Reply-To: <CANCZdfrR6KbixK9ubReXQv2Ak%2BNVuCxO6V8S3Mv91S3hLkXayA@mail.gmail.com> References: <Zq2Tn6XycReuifF6@www.zefox.net> <D4358DC6-E1FD-4558-80CF-1A0F62CBE58F@yahoo.com> <Zq25RlA8XtCJetH-@www.zefox.net> <FA91BB64-A9B3-485B-9BC9-6C8426AB50A5@yahoo.com> <Zq4-jgWn9FTEyNc2@www.zefox.net> <CANCZdfqb%2Bs0f3QuVAHzY54wg=9TrvLXrJ2VgnznFbjhA8JHUUA@mail.gmail.com> <Zq5-TZs86Kfkf2Rk@www.zefox.net> <CANCZdfrR6KbixK9ubReXQv2Ak%2BNVuCxO6V8S3Mv91S3hLkXayA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Zq_-9nYcudCuwZ7U>