Date: Fri, 6 Sep 2024 23:08:04 +0100 From: void <void@f-m.fm> To: freebsd-current@freebsd.org Subject: Re: Loader needs to be updated message Message-ID: <Ztt9RFQ4DzI5kKbz@int21h> In-Reply-To: <20240907025052.c93cd502dba60910f47a4c00@dec.sakura.ne.jp> References: <ZtsN-Z-qDfgU4zzk@int21h> <CANCZdfpgCyLOPrhnuWaHL_Sb6qDR9Pdqxy9CnPcxOq6AOehrYA@mail.gmail.com> <ZtsVQav0_oHU2H0x@int21h> <CANCZdfoH2_UhjpMhDtGdkH04zHUZc4SS6Ua80iSBoToJQBxMPA@mail.gmail.com> <20240907025052.c93cd502dba60910f47a4c00@dec.sakura.ne.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
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
--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Ztt9RFQ4DzI5kKbz>