Re: BOOT LOADER IS TOO OLD. PLEASE UPGRADE.
- Reply: bob prohaska : "Re: BOOT LOADER IS TOO OLD. PLEASE UPGRADE."
- In reply to: bob prohaska : "Re: BOOT LOADER IS TOO OLD. PLEASE UPGRADE."
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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.