Date: Sat, 23 Dec 2023 00:16:22 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: Toomas Soome <tsoome@me.com> Cc: Konstantin Belousov <kostikbel@gmail.com>, Mark Millard <marklmi@yahoo.com>, Current FreeBSD <freebsd-current@freebsd.org> Subject: Re: symlink to /boot/loader.efi Message-ID: <20231223001622.d65ce2b783ea9490273bf5ff@dec.sakura.ne.jp> In-Reply-To: <6276D9E8-D1D6-4ED5-96FB-BBF2875E079E@me.com> References: <AF65AD57-5D93-4FC2-84E8-58E1D7C0C3BC.ref@yahoo.com> <AF65AD57-5D93-4FC2-84E8-58E1D7C0C3BC@yahoo.com> <94C108FE-3D2F-4116-B071-810F64DECEC4@me.com> <ZYWYMRNWKYhCslVc@kib.kiev.ua> <6276D9E8-D1D6-4ED5-96FB-BBF2875E079E@me.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 22 Dec 2023 16:15:42 +0200 Toomas Soome <tsoome@me.com> wrote: > > > > On 22. Dec 2023, at 16:07, Konstantin Belousov <kostikbel@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 <marklmi@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 <dim@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 Additional note. boot1.efi looks for /boot/loader.efi with the order below. This is implemented when smh@ fixed the fatal issue which disallow booting from memstick when ESP alreay exixts among internal drives. *Prefer ZFS pool over UFS (first sniff ZFS pool, if not exixts, UFS) on each drives checked. *Look for the drive which boot1.efi itself is loaded from. *If none found both on ZFS pool nor UFS, try drives with the order UEFI firmware recognizes. This is also the way how the boot1.efi with the patch on Bug 207940 applied decides the default. > > > > > >> 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 > -- Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20231223001622.d65ce2b783ea9490273bf5ff>