From nobody Fri Dec 22 09:54:47 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 4SxN2H1bKGz552gk for ; Fri, 22 Dec 2023 09:55:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SxN2G4VMsz4PZB for ; Fri, 22 Dec 2023 09:55:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703238899; bh=herQ+XvE7DaqLnRKjLSGx4NhECMJTrT3OrG5e/ymbQk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=X217e19X2HTWS8wxppMyPpilp3VraroicZJU6scaEt8nYZRFs7AcUcAs9X/dG8SzKpU7a1zA6d0C5XFyaI9xSU0WriFUGNpfTXamkmwpE9WYSO2BvlmdNvbDf1G7GEoblAVxwT52SFb5JYgJZmY8ZSxI/ZMyDj2L3pl2XrsbB7X+Fn7ulkvKRe38nMKLAongHcUh2RYv4QeO/fC2VoDfv34JGuEu8wTcfDxZGrt0yQDA18D6uW+y+OkGffx7oBq3H3zWNijdxY8c0G4gHx4Dg3XKMwfX7UVO7KYfpXOXBGhprO02slvquUmJH4QOEKnyNZQf+l5lalRPnTLOKb7lHg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703238899; bh=kA+fa+35i3cy2IY1vP5+eogTxZrsiP8aCFEqUefRd7b=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=CJfdqbUKfRhFV2DvTt7rno0AhM4tRPhC782Vgx389rFVUY2wSADjULkCxAUAsFNpQEYb5L+4Ylfqsf0l1/WImTxUTPvB1e38YIlVCdZ4cX135XyzuZEGUguc3VJeBxNo3UH/O3FUOtWLoBisnKKpMqcgh03qS7OrA4ahq1tq1bZ1nJhz+IU4kke72OemD+O8VwDkQ2CL+E99GV3FO32fVoft6fuyTw6m7EDtvsKce/MmU/Uqhv9IIcgDPEtawXP6ipnVT7V5eM3JF02hIwzGTklMFmgoJWXgJua7b57FEFaThiV/1gXEqAe/SSivQIYTh3BmsrXmMdAmvYBnpfev6w== X-YMail-OSG: F3WkGsQVM1nt3cyx09tNQlg3AODHkerGS_5cp.gGhVAk_BiMGdMRny577B6e5GI h_mj4XjJysS_qJ2_jSNlbHLaiQz9.j2GTB7GZRPU4a.RlxeZ3teBDfXSSjxjrvkk.Ou9iJxa0a2x SR61IKB2PgR60gZiMERxmoI1eDTigDzRGnCj34axWjWCPqJPEoKRkx1B4fGbCYwbcFxmayJugwGa 5BMwIBl2h1d_P8ey355hy_oj9b4L6_cObIp8JciNPiLZzCRJp.gUcztGUoBaMEOO7D7iywQKpqy8 1aODre2wZIas8NbLBynl3yCe46MKqYTUWhEFYBhUqgy9CRiVe87UW3hivv8LYk9xg7go6Tk1hUa4 XABc5kVX5lAapWDc_oARC38cDMzF6n.uciDL6mL0ZrbZ.0KMgsOXupcar6XJQmYr7iKOaZShpEkK D4ELlCBe3Y2vGn2DN3P4lOUbMJoz5nMRNnMz69di5EK53y1aItOlSvpqNDiS1RLBzl_qqNfS.lM9 g_vIm2Do6i3XHPSCHqQ.eXPBrahMdYIBV6R8UdWLlorEyRhh2edVHfx7JLkDSXluEgyS_I14SBud vJXF9Du.Je18GiC_nCMmFRPRPfYspbYKoeedgpSbkpZBUeGseziruvchVCf0U_RcN9XbyvUYr5HG 3p6QbduJPcgFj0II6McAhHEtasvBTNbrMYR1dNuafXGrNvNtv4VgLZ5svoTfdCriC22.mSsrZy0L yZElM_wvdWJRh20UlBV8JBrVtEuUoIA4xO1jQ35GgePurUlASqlFHAGgxeRQwrK3lRoYNDNTZh49 EVn6E8tGtgNKdC1bTamBMgwsi3z_RM5zmgHrnPG38vbkWNRx6ePXBBomxRexRtR_04Rc1pnzOAtr TpITXugssnCGCUbAZDtzw9TI4wmZ7ssSYi4CqLEFNVQ85lgYK6PXZh4rAPWbftum_o9knPaAKNXr fwSHADepi6p0A2o_EpniKFy32qkefttJq0F.09gELNWWmnQ57JOxeKWQC6VNjwcsI_nKG4THxbyu PrkBedRSS_Y_Hz4WWhU.wmxeKaYg8X4exq7ZBDckX2flOfCIOB4bcI.9DpzmXKWtMIiYa2u3Om5h Tk218dOB0Gdh15XUW2Pz6_P6.Pg71Gae__gvrqb37nZSXUKlqVMXUyo6fSs29BzhGxANKHdVzB6j MDnsKWX0xN_HGmJGwpN7bYsRiOaX4Lmm7uoi7XEFqDcPLPpkuma38IQCUmUt1l6uj6jWuuan6X6V 1siujArO0mEdVjxOf00THCm6goDjIwTMLolXk.h1.a0PN8XapXXdJh27r.pzlP7wmsxc0zyy8jIH FZLbz2riYEh4qqrYC3mbcxZxAWfuSixpuinYP4zZvBxFl5Ja6w_zc_3HSVxINrv4zzkuDPAoJN7c qz0JoYBOeqnSb2tp2Zmet3TaAch_3gAE0qGJCqdLPRj1_tW5kZjl1v0qH_KolrPs3eSuKKr2khp5 SoSkYktpAFTf6FCANj7_TolWSD_kQw7bzj9cEJMdp.YPESR_LscnVk7tnLC6e0_9FWZsCIL24WsM xCaAZM3cMnM9BzcTYjHB.ZJ76TcrFd61POpachk_czmTDy0CZUX2i06EN2IUZMJgcRQVTT1OfbuS lgRNXceisbaUWnMCi6Zerjqrfbo3dk24RWVfNVZogkLuZ3QIzJIhg9mMb..DxzZLrP5jYgVbT3HN PO1pSc61d.BSg8zdT6Igrs2YyA6ay8B0UYqi3Bc1iancxC2EGNK_P4GJPeD_TaCvwk8NWTosHYSg 9elnLBHfFGn3V3VyqEq.V48BkMZae.EiiqNEsAcX.EUVkH3qHfz86Rk9KXAAePUiwXD9F8v0If_y yw.menW1nFbZMYCQRVbprI4Nk_9.OWeB98sAsoE3Gq2X2paSv4FYvjzvnMIveqy3NTphv5fZHwJI 0PIkNrCVq8VwXXGIrbYEBVw_yD0J8yXyeTkofkuolcnmJpCxGnvk9YWhZrWpAshsaAPG8cgdwjwe 1M86SKoXrwfcDqsLJdiGj.XcOrCN43KG2FQOU2Z9fFDGy.mWIXigambsC452MXNHcXCUpyKxKGNa qHBXLaShA32mJN4y5UUmWpAeLL7Gyuqf3skGyEA1yCAbsqQzyJoyn.7vhH1I0B10QrL5Kc9rJB8_ OJpE8zHU6b4JdpmyEL.vF5BCWHk8yJmWbi2UnytFzJrvKtbK07HPhPlKRoAVmbIp81QL08.2yIkj JlWmiTbSYtJXQHCjNXWILQubUNeBGRLahTcA66LiMBMhdDqlycuXIzmFZ9H29AX20zB7npJMnhj2 D.g-- X-Sonic-MF: X-Sonic-ID: 4eff05b3-e9e2-4559-b234-cf0722c0a584 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Fri, 22 Dec 2023 09:54:59 +0000 Received: by hermes--production-gq1-6949d6d8f9-47mhb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 42a26158befc0d86a25cc63eba2c6c5b; Fri, 22 Dec 2023 09:54:58 +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: Mark Millard In-Reply-To: <94C108FE-3D2F-4116-B071-810F64DECEC4@me.com> Date: Fri, 22 Dec 2023 01:54:47 -0800 Cc: Tomoaki AOKI , Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: <5879A778-0522-4E0F-A569-731E5EC85C18@yahoo.com> References: <94C108FE-3D2F-4116-B071-810F64DECEC4@me.com> To: Toomas Soome X-Mailer: Apple Mail (2.3774.300.61.1.2) 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:36647, ipnet:98.137.64.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SxN2G4VMsz4PZB 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. 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. > 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 Not powerpc (32-bit), powerpc64, or powerpc64le: these are not UEFI systems at all, if I understand right. 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. >=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. Thanks for the UEFi-context notes that go well beyond anything I referenced. Good stuff. > 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 =3D=3D=3D Mark Millard marklmi at yahoo.com