Re: symlink to /boot/loader.efi

On Dec 22, 2023, at 13:49, Konstantin Belousov <kostikbel@gmail.com> wrote:

> On Fri, Dec 22, 2023 at 02:03:56PM -0700, Warner Losh wrote:
>> Yes. I'd prefer to make this more parameterized, maybe with sanity checks.
>> 
>> That is, there'd be a tool that would do the right thing, based on what you
>> tell it to do. we'd set the defaults to be a default install. If you want
>> something other than defaults, you'd need to set a make variable (or a
>> command line arg if you ran the tool by hand.
>> 
>> You can know what type of system you are on: if arm, arm64 or riscv64, then
>> it's UEFI. If i386 then it's BIOS (though you can confirm this by looking
>> at machdep.bootmethod to see if it is BIOS, UEFI or something else), with
>> amd64, it's the same check as i386. If it's powerpc, then you someone with
>> powerpc skills will have to fill in the blanks here.
>> 
>> If it is BIOS, we can infer the boot disk from where / lives. This isn't
>> always correct, so that needs to be overiden. kenv might be useful, but it
>> exports loaddev/currdev in the Boot Loader's namespace (disk0, etc) which
>> may or may not match up with anything on FreeBSD.
>> 
>> If it's UEFI, then we can use efibootmgr to find what was booted (or at
>> least locate the ESP). Once we have the ESP, we can look at other bits of
>> the boot variables to know if it's /efi/boot/bootx64.efi or if it's
>> /etc/freebsd/loader.efi to update (and optionally, we could to both). Then
>> you also have 'automount vs. fail' if the ESP isn't mounted.
>> 
>> I'd recommend against autodetecting boot1 vs loader, except maybe as a
>> safety measure that can be overriden. It's another reason having boot1.efi
>> around complicates things needlessly.
>> 
>> This is the sort of thing I was hoping to code up. I got bogged down by
>> including 'also update the primary loader (aka the freebsd-boot partition,
>> the u-boot stuff that needs to be dd', etc), so I think we shouldn't do
>> that until phase 2.
>> 
>> So maybe we should write a man page for this tool, and maybe a paragraph
>> for how it would hook into the build system if we wanted to have a 'make
>> installboot' target that lives logically before installkernel.
>> 
>> Comments?
> 
> Can we remove boot1.efi from the picture of the updating tool at all?
> 
> Lets make the boot1 explicitly limited for very simple configuration
> where it searches for first UFS GPT partition and loads loader.efi
> from there.  The autoupdate tool would be not used at all in such
> config, by administrator choice.

If done, sounds like a good thing for aarch64 and armv7 small
arm board snapshots to use.

(Similarly if there ever is an analogous amd64 snapshot to dd
to, say, USB media: something I'd use for testing activities
with such official builds if they existed. I like to avoid
submitting notes based on my personal builds if official
builds show the behavior of interest. Setting up such an
amd64 install the normal way is just busy work for this
purpose. I do the same sort of thing for aarch64 and armv7,
testing if I can avoid my personal builds that I normally
use, including with the HoneyComb and MACCHIATObin Double
Shot that are not small arm boards.)

===
Mark Millard
marklmi at yahoo.com