> On 22. Dec 2023, at 16:07, Konstantin Belousov <kostik...@gmail.com> wrote: > > On Fri, Dec 22, 2023 at 11:36:24AM +0200, Toomas Soome wrote: >> >> >>> On 22. Dec 2023, at 11:09, Mark Millard <mark...@yahoo.com> wrote: >>> >>> Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp> wrote on >>> Date: Thu, 21 Dec 2023 23:21:00 UTC : >>> >>>> On Thu, 21 Dec 2023 14:22:14 +0100 >>>> Dimitry Andric <d...@freebsd.org> wrote: >>>> >>>>> Yeah, my procedure is the same as yours: I first copy >>>>> /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, >>>>> then copy the freshly built and installed /boot/loader.efi to >>>>> /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why this >>>>> could not be just another step in the installworld procedure. >>>>> >>>>> That said, I am unsure if the pathname /boot/efi/efi is always the same, >>>>> at least for all UEFI systems. It is the default layout when you do a >>>>> regular install with recent installer onto a UEFI system, but some users >>>>> may use completely different mount points. So you should still have some >>>>> way of configuring the default location for loader installation. >>>>> >>>>> Also, on default installations a fallback entry named >>>>> /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of >>>>> loader.efi but with a different name. Namely, the default name that UEFI >>>>> (on x86_64 at least) searches for, if it doesn't know anything else. I.e. >>>>> if it isn't configured via efibootmgr(8), or the EFI variables have been >>>>> junked for some reason. It might make sense to also update that file. >>>>> >>>>> -Dimitry >>>> >>>> Just an idea. >>>> >>>> It would be nice if loader.efi (hopefully, boot1.efi,too) could pass >>>> "where am I placed?" info, maybe via kenv. >>>> >>>> Would need boot1.efi to pass something (ideally, "where am I booted >>>> from?", but "boot1_used=1" is sufficient). >>>> >>>> To do so, loader.efi can confirm whether it was loaded via boot1.efi or >>>> directly from UEFI firmware. If nothing is passed to it, it can probe >>>> "where it is?" using UEFI call and set it, otherwise, it should >>>> be /boot/loader.efi, so nothing is needed to do. >>> >>> To my knowledge aarch64 and armv7 never use the copy in >>> /boot/loader.efi during a boot. It has to have been copied >>> into the appropriate msdosfs such that it has an >>> appropriate path and name there. That is what is found >>> and used during the boot. >> >> >> All UEFI systems start from ESP (EFI System Partition). The only good reason >> to install boot1.efi there is when you have very small ESP and need to save >> that space - and in that case the boot1.esp will search and execute >> /boot/loader.efi. >> > No, this is not the only good reason, or even the least important reason. > > boot1.efi is extremely convenient for the normal (*) configuration where > machine is dedicated for a single FreeBSD system. It finds and chain-load > real loader.efi from the first UFS GPT partition which I always assign to > the root. This means that I do not need to care about updating loader.efi > at all, it is done during normal installworld. > > * at least for me > > I use this setup for >5 years on all my disk-booting machines.
Yes, that one is also [good] reason, however, I personally do consider it missing feature of bectl/beadm activate;) rgds, toomas > >> The problem about boot1.efi (or any other UEFI chainload) is that loading >> file and executing it will not replace current program in memory, but will >> add new one, this may be problem with systems with minimal memory >> configurations. And yes, boot1.efi is not really platform specific - it is >> just another EFI application - one can build and use it on arm (or any >> other) systems and then it will load and start /boot/loader.efi. >> >> starting loader directly from ESP has few advantages — you wont waste memory >> for boot1.efi, you save a bit of boot time, you can use auxiliary files from >> ESP to pass some information to loader.efi (for example to tell where your >> rootfs is in case of multiboot setups). >> >> the boot1.efi could be a bit more appealing if it would be able to load and >> start kernel directly, allowing to build very memory limited setups, but >> then again, it does sound like very specific corner case. >> >> rgds, >> toomas >> >> >>> >>>> If no related kenv is set and freebsd-boot partition exists, it should >>>> be booted with legacy (BIOS) boot. >>> >>> If there even is a "legacy (BIOS) boot" is a platform >>> specific issue as far as I know. >>> >>>> The easiest to be set by loader.efi and/or boot1.efi would be raw UEFI >>>> device path. So would need analyzing where actually is on booted >>>> FreeBBSD environment. >>> >>> See the earlier point about aarch64 and armv7 not using >>> /boot/* files while loading the FreeBSD loader: the >>> FreeBSD loader variant used is the first stage able to >>> look inside UFS or ZFS file systems. Loading and >>> starting the FreeBSD loader happens before that stage >>> in those types of contexts. >>> >>>> . . . >>> >>> Also, to my knowledge, powerpc (32-bit), powerpc64, and >>> powerpc64le do not involve any variant of loader.efi or >>> UEFI/ACPI or UEFI/DeviceTriee in their boot sequnces. >>> Again: more platform specific rather than generic. >>> >>> === >>> Mark Millard >>> marklmi at yahoo.com
