On Sat, Sep 07, 2024 at 02:50:52AM +0900, Tomoaki AOKI wrote:
Some additional explanation.
Before, loader.efi itself could not be kicked directly from UEFI
firmware and needs boot1.efi to kick loader.efi.
In this case, boot code in ESP (uEFI System Partition, formatted with
FAT32, 16 or possibly 12) was completely different
with /boot/loader.efi.
But now (by default for new UEFI installations), loader.efi can be
kicked directly by UEFI firmware if it is put with proper directory
and name in ESP. This would be what confusing you. With
`make installworld` or usual freebsd-update, everything need updating
in /boot/ should be updated, but nothing in ESP is updated
automatically. This causes what you're experiencing.
Unfortunately, how loader.efi should be installed in ESP depends on the
environment it is installed. Old or buggy UEFI firmware could force you
installing it as, for example for amd64, BOOT/EFI/BOOTx64.EFI in ESP to
work, but usually BOOT/FreeBSD/loader.efi would work if UEFI boot
manager is properly configured for it.
Some would need ESP on all drives and keep all of them in sync.
Yes, hard to automate properly for every possible situations,
unlike /boot/.
Thanks for the explanation.
The machine is headless. I grab the console from another pi via a
usb <-> ttl cable. I've always associated (probably wrongly) UEFI with
graphical-based installs and had to make a boot.config file in / to
always use -h in order to get console output down the serial while booting.
I'd use 'legacy' on this hardware if possible, rather than UEFI.
if it's relevant, in /boot/efi there's, amongst other files, bcm2711-rpi-4-b.dtb
bootcode.bin armstub8.bin fixup*.dat start*.elf u-boot.bin ubootefi.var
These are all from the ESP from the image
FreeBSD-15.0-CURRENT-arm64-aarch64-RPI-20240725-82283cad12a4-271360 [1]
Maybe I need to download latest -current snapshot and copy the contents of its
ESP over to
update the loader?
[1] running bsdinstall [2] doesn't take care of the ESP completely. One has to
run bsdinstall
to the desired disk, then boot with the original image running, then copy
the ESP from the
original image to the ESP partition on the new disk, then reboot after
unplugging the original
image.
[2] this was to facilitate a zfs-on-root install.
[3] what I am trying to do now is source update the system in-situ in the
normal way, on reboot
the error popped up in the (ascii) beastie menu. It persists even after
following the instructions
in man 8 loader.efi
--
