From nobody Fri Dec 22 19:17:15 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SxcWD72Pyz54MDM for ; Fri, 22 Dec 2023 19:17:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SxcWD59Sxz4Fh5 for ; Fri, 22 Dec 2023 19:17:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-50e593c756dso2571762e87.2 for ; Fri, 22 Dec 2023 11:17:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1703272647; x=1703877447; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GYYBiui7bena3o4tfbqmHOSRwEY7sWxa7A6wwc401No=; b=L9LA1dgH9AFiZRf57A1+uQ+Vq/R2xcDhqEcSi+riOk3Z6iFpxLgkmS9HPua65bPAme tle8LWZoqEoratOCvyKGAw645F772kGeCTEIZF8wpWGJ2ha6DQWYxZmdlEo6hC2nDlbS NL7ckfemSDkRgBzd8rp9ElGmudaqXuWU93JdAsoubkfnsICGpRCI9luIm0EiNs6yqZK6 6AuVNrDYZKpL9x3bCVI5vGg+XSEVj09mBwK1eKMVrconBjDzauS8DYq4axF7rRFUinBg ac0h5FDKNE8kOpNZ/v9OCGB260nBpuKsXKu14C5av4v+qZV5KY/BLNSTB4sEvDMHnwQz j3kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703272647; x=1703877447; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GYYBiui7bena3o4tfbqmHOSRwEY7sWxa7A6wwc401No=; b=BmzRGFVjg6bsLIDHI2Iq2cE5+FgWj+rYR381AAXCjUOlWGmGFNRqJ2LgrTibFp4FyD Dzio3DqsSKtB15dR2BB8wbnc7bfV9X5CaaPGI9WeRX4/ZXpwZlAV7jx96vu9Fdlb0rOf 8XdS1/wGe539NNnBFcxzo2e0OSmao4Uckj+Hs5IzOUoBti6zJHW3O8LcPKj9r5p/T3X4 p5Amjgk/9vgaPQILOjoDe2zsERr4x/wjnLAvi0WrMjpOy552+k1bhkEq1HiY/TENaNgK vKD0PyEC4QC4TgXZOuFo1raBdvx47XwCtj5iQ29zyu/nK1pjlsQWGEtXL5QNhtpyqAcA r7FA== X-Gm-Message-State: AOJu0Yw6j+nM/FCWL9GACIrus33WzUEZ6Qn3jAO4a71dIPQRfKY9drzb FmE7R56veM75Ce8TbV4IzifUb5zF2Zh+rG7Nkjs1/dCyztHV3KOp7It6rxw8XXg= X-Google-Smtp-Source: AGHT+IHPawSpWVfTZbtrSNT7DeN+BpYqefraDE0MEHwPxE49sOrlD1kbF21Mh4hzvHSbOuCa26XIok/Vt6b6gn8qOpQ= X-Received: by 2002:ac2:4907:0:b0:50c:4ea:64f4 with SMTP id n7-20020ac24907000000b0050c04ea64f4mr826006lfi.70.1703272646771; Fri, 22 Dec 2023 11:17:26 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <94C108FE-3D2F-4116-B071-810F64DECEC4@me.com> In-Reply-To: <94C108FE-3D2F-4116-B071-810F64DECEC4@me.com> From: Warner Losh Date: Fri, 22 Dec 2023 12:17:15 -0700 Message-ID: Subject: Re: symlink to /boot/loader.efi To: Toomas Soome Cc: Mark Millard , Tomoaki AOKI , Current FreeBSD Content-Type: multipart/alternative; boundary="000000000000111da1060d1e11e6" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SxcWD59Sxz4Fh5 --000000000000111da1060d1e11e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 22, 2023 at 2:36=E2=80=AFAM Toomas Soome wrote: > > > > On 22. Dec 2023, at 11:09, Mark Millard wrote: > > > > Tomoaki AOKI wrote on > > Date: Thu, 21 Dec 2023 23:21:00 UTC : > > > >> On Thu, 21 Dec 2023 14:22:14 +0100 > >> Dimitry Andric 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 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=3D1" is sufficient). > >> > >> To do so, loader.efi can confirm whether it was loaded via boot1.efi o= r > >> 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 nee= d > to save that space - and in that case the boot1.esp will search and execu= te > /boot/loader.efi. > Yes. I consider this a legacy need only. Part of the problem with 'fixing' boot1.efi to include all the newest filesystems, crypto, etc means that it grows too large for this use case. > 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 wil= l > add new one, this may be problem with systems with minimal memory > 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 and then it will load and start /boot/loader.efi. > > starting loader directly from ESP has few advantages =E2=80=94 you wont w= aste > 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. > Yes. boot1.efi is a bit of a special case. It originally was done as a quick port of boot1 from powerpc and was quite small. However, as we expanded the supported boot paths, it grew. And growth isn't the only problem. boot1.efi uses its own drivers and filesystems that do leverage the base libsa stuff, but do it in slightly different ways that loader.efi does. It also largely duplicates loader.efi functionality, just to read loader.efi. And with all the ZFS, crypto, compression, it's too much. I get the appeal for having a boot1.efi that's super simple, but our system is a poor fit to that, especially with ZFS's high velocity. It's a big reason I've not merged things in. Warner > 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. > > > > =3D=3D=3D > > Mark Millard > > marklmi at yahoo.com > > > > > > > --000000000000111da1060d1e11e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Dec 22, 2023 at 2:36=E2=80=AF= AM 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> wrot= e 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/ef= i/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/load= er.efi. I don't see a technical reason why this could not be just anoth= er 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 us= ers may use completely different mount points. So you should still have som= e way of configuring the default location for loader installation.
>>>
>>> Also, on default installations a fallback entry named /boot/ef= i/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 lea= st) 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 s= ome 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 = booted
>> from?", but "boot1_used=3D1" is sufficient).
>>
>> To do so, loader.efi can confirm whether it was loaded via boot1.e= fi or
>> directly from UEFI firmware. If nothing is passed to it, it can pr= obe
>> "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 reaso= n to install boot1.efi there is when you have very small ESP and need to sa= ve that space - and in that case the boot1.esp will search and execute /boo= t/loader.efi.

Yes. I consider this a le= gacy need only. Part of the problem with 'fixing' boot1.efi to incl= ude all the newest filesystems, crypto, etc means that it grows too large f= or this use case.
=C2=A0
The problem about boot1.efi (or any other UEFI chainload) is that loading f= ile and executing it will not replace current program in memory, but will a= dd new one, this may be problem with systems with minimal memory configurat= ions. And yes, boot1.efi is not really platform specific - it is just anoth= er 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 =E2=80=94 you wont was= te 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 t= hen again, it does sound like very specific corner case.

Yes. boot1.efi is a bit of a special case. It originally = was done as a quick port of boot1 from powerpc and was quite small. However= , as we expanded the supported boot paths, it grew.

And growth isn't the only problem. boot1.efi uses its own drivers and= filesystems that do leverage the base libsa stuff, but do it in slightly d= ifferent ways that loader.efi does. It also largely duplicates loader.efi f= unctionality, just to read loader.efi. And with all the ZFS, crypto, compre= ssion, it's too much.

I get the appeal for hav= ing a boot1.efi that's super simple, but our system is a poor fit to th= at, especially with ZFS's=C2=A0high=C2=A0velocity. It's a big reaso= n I've not merged things in.

Warner
= =C2=A0
rgds,
toomas


>
>> If no related kenv is set and freebsd-boot partition exists, it sh= ould
>> 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.
>
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
>
>


--000000000000111da1060d1e11e6--