From nobody Fri Dec 22 10:02:54 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 4SxNCg0qzNz5537T for ; Fri, 22 Dec 2023 10:03:11 +0000 (UTC) (envelope-from tsoome@me.com) Received: from mr85p00im-zteg06021601.me.com (mr85p00im-zteg06021601.me.com [17.58.23.187]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SxNCf5RR3z4RHd for ; Fri, 22 Dec 2023 10:03:10 +0000 (UTC) (envelope-from tsoome@me.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1703239388; bh=9qJJ1Ca06mpqvwsIHFJ3D5ZMN2J6VHIZxmgp4Im5YiU=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=KAQ5XRFhf8yue+uZrdlo3xPUIP7tABp2KmqcGDy6iy8xARe6BZYWNIFagGYycMYYo RXeV+1sxuLolyJWlUnNbzLzZ/yFe7a21VQNxWRIOlOM6C0eJ3+UfxE3cjXBL+4JRxf Cb46+RZhU8a9kqG52ZBdbjIZ2h2YU3yLNDfhhtjMFdxeL7EG0qwSzqizjXtjqf5r+J 9CrF1Vtsz3DcUeKA/jgXPs3Go6ad+D7mw5E3Tuf2EoHbJ+fd5eUZbTg4eyhv+gJlOO gahQgp+I8Ma8NXMl2bU4yDqgf5/UHmqFiR8MPBA6bW+qH9ytDMcl6Go2bpPwFkfO5+ OD+9rU/dTnMLw== Received: from smtpclient.apple (mr38p00im-dlb-asmtp-mailmevip.me.com [17.57.152.18]) by mr85p00im-zteg06021601.me.com (Postfix) with ESMTPSA id 355913058416; Fri, 22 Dec 2023 10:03:07 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: symlink to /boot/loader.efi From: Toomas Soome In-Reply-To: <5879A778-0522-4E0F-A569-731E5EC85C18@yahoo.com> Date: Fri, 22 Dec 2023 12:02:54 +0200 Cc: Tomoaki AOKI , Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: <8711C4A5-6329-4FB2-9D7A-4C7215595110@me.com> References: <94C108FE-3D2F-4116-B071-810F64DECEC4@me.com> <5879A778-0522-4E0F-A569-731E5EC85C18@yahoo.com> To: Mark Millard X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Proofpoint-ORIG-GUID: qBLBzdLKdjBtZsMJaHV_gJLvOEdBIWyv X-Proofpoint-GUID: qBLBzdLKdjBtZsMJaHV_gJLvOEdBIWyv X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-12-22_05,2023-12-21_02,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 malwarescore=0 spamscore=0 phishscore=0 clxscore=1015 mlxlogscore=999 adultscore=0 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2312220072 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:714, ipnet:17.58.16.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SxNCf5RR3z4RHd > On 22. Dec 2023, at 11:54, Mark Millard wrote: >=20 > On Dec 22, 2023, at 01:36, Toomas Soome wrote: >>=20 >>=20 >>=20 >>> On 22. Dec 2023, at 11:09, Mark Millard wrote: >>>=20 >>> Tomoaki AOKI wrote on >>> Date: Thu, 21 Dec 2023 23:21:00 UTC : >>>=20 >>>> On Thu, 21 Dec 2023 14:22:14 +0100 >>>> Dimitry Andric wrote: >>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> -Dimitry >>>>=20 >>>> Just an idea. >>>>=20 >>>> It would be nice if loader.efi (hopefully, boot1.efi,too) could = pass >>>> "where am I placed?" info, maybe via kenv. >>>>=20 >>>> Would need boot1.efi to pass something (ideally, "where am I booted >>>> from?", but "boot1_used=3D1" is sufficient). >>>>=20 >>>> 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. >>>=20 >>> 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. >>=20 >>=20 >> 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. >=20 > 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. >=20 >> 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 >=20 > 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.=20 rgds, toomas >=20 > 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. >=20 >> and then it will load and start /boot/loader.efi. >>=20 >> 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 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). >>=20 >> 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. >=20 > Thanks for the UEFi-context notes that go well beyond anything > I referenced. Good stuff. >=20 >> rgds, >> toomas >>=20 >>=20 >>>=20 >>>> If no related kenv is set and freebsd-boot partition exists, it = should >>>> be booted with legacy (BIOS) boot. >>>=20 >>> If there even is a "legacy (BIOS) boot" is a platform >>> specific issue as far as I know. >>>=20 >>>> 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. >>>=20 >>> 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. >>>=20 >>>> . . . >>>=20 >>> 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. >>>=20 >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com >=20