Date: Fri, 22 Dec 2023 14:03:56 -0700 From: Warner Losh <imp@bsdimp.com> To: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> Cc: Toomas Soome <tsoome@me.com>, Mark Millard <marklmi@yahoo.com>, Current FreeBSD <freebsd-current@freebsd.org> Subject: Re: symlink to /boot/loader.efi Message-ID: <CANCZdfrwq%2BLS6vXcewruZBFo6RMZi-2q2vWkdYFeN4en7hK0QQ@mail.gmail.com> In-Reply-To: <20231223000015.766b94fe0e3a3b742fd386c5@dec.sakura.ne.jp> References: <AF65AD57-5D93-4FC2-84E8-58E1D7C0C3BC.ref@yahoo.com> <AF65AD57-5D93-4FC2-84E8-58E1D7C0C3BC@yahoo.com> <94C108FE-3D2F-4116-B071-810F64DECEC4@me.com> <5879A778-0522-4E0F-A569-731E5EC85C18@yahoo.com> <8711C4A5-6329-4FB2-9D7A-4C7215595110@me.com> <20231223000015.766b94fe0e3a3b742fd386c5@dec.sakura.ne.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000009e019b060d1f8e2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 22, 2023 at 8:00=E2=80=AFAM Tomoaki AOKI <junchoon@dec.sakura.n= e.jp> wrote: > On Fri, 22 Dec 2023 12:02:54 +0200 > Toomas Soome <tsoome@me.com> wrote: > > > > On 22. Dec 2023, at 11:54, Mark Millard <marklmi@yahoo.com> wrote: > > > > > > On Dec 22, 2023, at 01:36, Toomas Soome <tsoome@me.com> 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, the= n > 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 th= e > 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 pa= ss > > >>>> "where am I placed?" info, maybe via kenv. > > >>>> > > >>>> Would need boot1.efi to pass something (ideally, "where am I boote= d > > >>>> from?", but "boot1_used=3D1" 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 goo= d > reason to install boot1.efi there is when you have very small ESP and nee= d > to save that space - and in that case the boot1.esp will search and execu= te > /boot/loader.efi. > > Or if you need the functionality the patch at Bug 207940 [1] provides, > which is not yet implemented on loader.efi. ;-) > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207940 > > > > > Yep. May be I misinterpreted what the text strongly tied to > > > "it should be /boot/loader.efi" and so ended up not pointing > > > out an actual distinction. > > Ah, sorry for mis-leading words. > > > > >> 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 memor= y > configurations. And yes, boot1.efi is not really platform specific - it i= s > just another EFI application - one can build and use it on arm (or any > other) systems > > > > > > Not powerpc (32-bit), powerpc64, or powerpc64le: these are > > > not UEFI systems at all, if I understand right. > > > > > > Yes, building EFI application implies platform with UEFI support. > > > > rgds, > > toomas > > > > > > > > Of course, if only tier 1 is documented, such would not be > > > covered. But documentation that is limited to tier 1 should > > > say so explicitly --but various examples have historically > > > not done so. > > > > > >> and then it will load and start /boot/loader.efi. > > >> > > >> starting loader directly from ESP has few advantages =E2=80=94 you w= ont 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 tel= l > 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. > > > > > > Thanks for the UEFi-context notes that go well beyond anything > > > I referenced. Good stuff. > > > > > >> 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. > > And most constraints in resource. Not sure about pxeboot and uboot > cases. > > But at the point of view from "automatically updating boot codes", > pxeboot could be ommitted from concerns, as it should be done by > server-side admins. > > Putting these cases aside, to automatically update bootcodes, > appropreate Makefile or script should need to know > *How is this computer booted? > > *If detected as UEFI boot, what was the boot code? > loader.efi as EFI/freebsd/loader.efi? > loader.efi as EFI/boot/boot[arch].efi? > or boot1.efi instead? > > *If detected as UEFI-boot and RAID (raidz, graid, ...) configured, > also entitle all ESP on disks containing RAID member to be updated. > ESP on other disks should be untouched. > > *If not UEFI-booted, consider as legacy boot (cannot pass info as of > resource constraints, or third party loader like grub. > This case, if freebsd-boot type partition is detected on which disk > root directory is placed is entitled to be updated. > > To achieve this, at least loader.efi and boot1.efi should somehow pass > info about below. > *I am "boot1.efi" or "loader.efi" > *I've booted from which device path. > For this purpose, IIUC, only kenv can be used. Right? > > Then finally, update need-to-update boot codes. > 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? Warner > >>> > > >>>> 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. > > >>> > > > > > > > > > =3D=3D=3D > > > Mark Millard > > > marklmi at yahoo.com > > > -- > Tomoaki AOKI <junchoon@dec.sakura.ne.jp> > > --0000000000009e019b060d1f8e2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Fri, Dec 22, 2023 at 8:00=E2=80=AF= AM Tomoaki AOKI <<a href=3D"mailto:junchoon@dec.sakura.ne.jp">junchoon@d= ec.sakura.ne.jp</a>> wrote:<br></div><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad= ding-left:1ex">On Fri, 22 Dec 2023 12:02:54 +0200<br> Toomas Soome <<a href=3D"mailto:tsoome@me.com" target=3D"_blank">tsoome@= me.com</a>> wrote:<br> <br> > > On 22. Dec 2023, at 11:54, Mark Millard <<a href=3D"mailto:mar= klmi@yahoo.com" target=3D"_blank">marklmi@yahoo.com</a>> wrote:<br> > > <br> > > On Dec 22, 2023, at 01:36, Toomas Soome <<a href=3D"mailto:tso= ome@me.com" target=3D"_blank">tsoome@me.com</a>> wrote:<br> > >> <br> > >> <br> > >> <br> > >>> On 22. Dec 2023, at 11:09, Mark Millard <<a href=3D"ma= ilto:marklmi@yahoo.com" target=3D"_blank">marklmi@yahoo.com</a>> wrote:<= br> > >>> <br> > >>> Tomoaki AOKI <<a href=3D"http://junchoon_at_dec.sakura= .ne.jp" rel=3D"noreferrer" target=3D"_blank">junchoon_at_dec.sakura.ne.jp</= a>> wrote on<br> > >>> Date: Thu, 21 Dec 2023 23:21:00 UTC :<br> > >>> <br> > >>>> On Thu, 21 Dec 2023 14:22:14 +0100<br> > >>>> Dimitry Andric <dim@FreeBSD.org> wrote:<br> > >>>> <br> > >>>>> 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.<br> > >>>>> <br> > >>>>> 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 la= yout 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 s= till have some way of configuring the default location for loader installat= ion.<br> > >>>>> <br> > >>>>> Also, on default installations a fallback entry n= amed /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of lo= ader.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. i= f 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.<br> > >>>>> <br> > >>>>> -Dimitry<br> > >>>> <br> > >>>> Just an idea.<br> > >>>> <br> > >>>> It would be nice if loader.efi (hopefully, boot1.efi,= too) could pass<br> > >>>> "where am I placed?" info, maybe via kenv.<= br> > >>>> <br> > >>>> Would need boot1.efi to pass something (ideally, &quo= t;where am I booted<br> > >>>> from?", but "boot1_used=3D1" is suffic= ient).<br> > >>>> <br> > >>>> To do so, loader.efi can confirm whether it was loade= d via boot1.efi or<br> > >>>> directly from UEFI firmware. If nothing is passed to = it, it can probe<br> > >>>> "where it is?" using UEFI call and set it, = otherwise, it should<br> > >>>> be /boot/loader.efi, so nothing is needed to do.<br> > >>> <br> > >>> To my knowledge aarch64 and armv7 never use the copy in<b= r> > >>> /boot/loader.efi during a boot. It has to have been copie= d<br> > >>> into the appropriate msdosfs such that it has an<br> > >>> appropriate path and name there. That is what is found<br= > > >>> and used during the boot.<br> > >> <br> > >> <br> > >> All UEFI systems start from ESP (EFI System Partition). The o= nly 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 an= d execute /boot/loader.efi.<br> <br> Or if you need the functionality the patch at Bug 207940 [1] provides,<br> which is not yet implemented on loader.efi. ;-)<br> <br> [1] <a href=3D"https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207940" = rel=3D"noreferrer" target=3D"_blank">https://bugs.freebsd.org/bugzilla/show= _bug.cgi?id=3D207940</a><br> <br> <br> > > Yep. May be I misinterpreted what the text strongly tied to<br> > > "it should be /boot/loader.efi" and so ended up not poi= nting<br> > > out an actual distinction.<br> <br> Ah, sorry for mis-leading words.<br> <br> <br> > >> The problem about boot1.efi (or any other UEFI chainload) is = that loading file and executing it will not replace current program in memo= ry, but will add new one, this may be problem with systems with minimal mem= ory 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<br> > > <br> > > Not powerpc (32-bit), powerpc64, or powerpc64le: these are<br> > > not UEFI systems at all, if I understand right.<br> > <br> > <br> > Yes, building EFI application implies platform with UEFI support. <br> > <br> > rgds,<br> > toomas<br> > <br> > > <br> > > Of course, if only tier 1 is documented, such would not be<br> > > covered. But documentation that is limited to tier 1 should<br> > > say so explicitly --but various examples have historically<br> > > not done so.<br> > > <br> > >> and then it will load and start /boot/loader.efi.<br> > >> <br> > >> starting loader directly from ESP has few advantages =E2=80= =94 you wont waste memory for boot1.efi, you save a bit of boot time, you c= an 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).<br> > >> <br> > >> the boot1.efi could be a bit more appealing if it would be ab= le to load and start kernel directly, allowing to build very memory limited= setups, but then again, it does sound like very specific corner case.<br> > > <br> > > Thanks for the UEFi-context notes that go well beyond anything<br= > > > I referenced. Good stuff.<br> > > <br> > >> rgds,<br> > >> toomas<br> > >> <br> > >> <br> > >>> <br> > >>>> If no related kenv is set and freebsd-boot partition = exists, it should<br> > >>>> be booted with legacy (BIOS) boot.<br> > >>> <br> > >>> If there even is a "legacy (BIOS) boot" is a pl= atform<br> > >>> specific issue as far as I know.<br> <br> And most constraints in resource. Not sure about pxeboot and uboot<br> cases.<br> <br> But at the point of view from "automatically updating boot codes"= ,<br> pxeboot could be ommitted from concerns, as it should be done by<br> server-side admins.<br> <br> Putting these cases aside, to automatically update bootcodes,<br> appropreate Makefile or script should need to know<br> =C2=A0 *How is this computer booted?<br> <br> =C2=A0 *If detected as UEFI boot, what was the boot code?<br> =C2=A0 =C2=A0loader.efi as EFI/freebsd/loader.efi?<br> =C2=A0 =C2=A0loader.efi as EFI/boot/boot[arch].efi?<br> =C2=A0 =C2=A0or boot1.efi instead?<br> <br> =C2=A0 *If detected as UEFI-boot and RAID (raidz, graid, ...) configured,<b= r> =C2=A0 =C2=A0also entitle all ESP on disks containing RAID member to be upd= ated.<br> =C2=A0 =C2=A0ESP on other disks should be untouched.<br> <br> =C2=A0 *If not UEFI-booted, consider as legacy boot (cannot pass info as of= <br> =C2=A0 =C2=A0resource constraints, or third party loader like grub.<br> =C2=A0 =C2=A0This case, if freebsd-boot type partition is detected on which= disk<br> =C2=A0 =C2=A0root directory is placed is entitled to be updated.<br> <br> To achieve this, at least loader.efi and boot1.efi should somehow pass<br> info about below.<br> =C2=A0 *I am "boot1.efi" or "loader.efi"<br> =C2=A0 *I've booted from which device path.<br> For this purpose, IIUC, only kenv can be used. Right?<br> <br> Then finally, update need-to-update boot codes.<br></blockquote><div><br></= div><div>Yes. I'd prefer to make this more parameterized, maybe with sa= nity checks.</div><div><br></div><div>That is, there'd be a tool that w= ould 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 t= he tool by hand.</div><div><br></div><div>You can know what type of system = you are on: if arm, arm64 or riscv64, then it's UEFI. If i386 then it&#= 39;s BIOS (though you can confirm this by looking at=C2=A0machdep.bootmetho= d to see if it is BIOS, UEFI or something else), with amd64, it's the s= ame check as i386. If it's powerpc, then you someone with powerpc skill= s will have to fill in the blanks here.</div><div><br></div><div>If it is B= IOS, we can infer the boot disk from where / lives. This isn't always c= orrect, 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 o= r may not match up with anything on FreeBSD.</div><div><br></div><div>If it= 's UEFI, then we can use efibootmgr to find what was booted (or at leas= t locate the ESP). Once we have the ESP, we can look at other bits of the b= oot 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.</div><= div><br></div><div>I'd recommend against autodetecting=C2=A0boot1 vs lo= ader, except maybe as a safety measure that can be overriden. It's anot= her reason having boot1.efi around complicates things needlessly.</div><div= ><br></div><div>This is the sort of thing I was hoping to code up. I got bo= gged 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 thin= k we shouldn't do that until phase 2.</div><div><br></div><div>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 installb= oot' target that lives logically before installkernel.</div><div><br></= div><div>Comments?</div><div><br></div><div>Warner</div><div><br></div><blo= ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left= :1px solid rgb(204,204,204);padding-left:1ex">> >>> <br> > >>>> The easiest to be set by loader.efi and/or boot1.efi = would be raw UEFI<br> > >>>> device path. So would need analyzing where actually i= s on booted<br> > >>>> FreeBBSD environment.<br> > >>> <br> > >>> See the earlier point about aarch64 and armv7 not using<b= r> > >>> /boot/* files while loading the FreeBSD loader: the<br> > >>> FreeBSD loader variant used is the first stage able to<br= > > >>> look inside UFS or ZFS file systems. Loading and<br> > >>> starting the FreeBSD loader happens before that stage<br> > >>> in those types of contexts.<br> > >>> <br> > >>>> . . .<br> > >>> <br> > >>> Also, to my knowledge, powerpc (32-bit), powerpc64, and<b= r> > >>> powerpc64le do not involve any variant of loader.efi or<b= r> > >>> UEFI/ACPI or UEFI/DeviceTriee in their boot sequnces.<br> > >>> Again: more platform specific rather than generic.<br> > >>> <br> > > <br> > > <br> > > =3D=3D=3D<br> > > Mark Millard<br> > > marklmi at <a href=3D"http://yahoo.com" rel=3D"noreferrer" target= =3D"_blank">yahoo.com</a><br> <br> <br> -- <br> Tomoaki AOKI=C2=A0 =C2=A0 <<a href=3D"mailto:junchoon@dec.sakura.ne.jp" = target=3D"_blank">junchoon@dec.sakura.ne.jp</a>><br> <br> </blockquote></div></div> --0000000000009e019b060d1f8e2d--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrwq%2BLS6vXcewruZBFo6RMZi-2q2vWkdYFeN4en7hK0QQ>