From owner-freebsd-current@freebsd.org Sat Mar 28 19:56:50 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9362B264333 for ; Sat, 28 Mar 2020 19:56:50 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48qTy56QH7z4SqD for ; Sat, 28 Mar 2020 19:56:45 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 02SJvFZY008567 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 28 Mar 2020 12:57:21 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: In-Reply-To: <318FDBAF-448F-4C55-A9A8-69D71A73E43B@me.com> From: Chris Reply-To: bsd-lists@BSDforge.com To: Toomas Soome Subject: Re: When will the FreeBSD (u)EFI work? Date: Sat, 28 Mar 2020 12:57:21 -0700 Message-Id: <344e85545cfc47c9835fc5918e5b1dc1@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 48qTy56QH7z4SqD X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.02 / 15.00]; NEURAL_HAM_MEDIUM(-0.63)[-0.631,0]; NEURAL_HAM_LONG(-0.39)[-0.390,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 19:56:50 -0000 On Sat, 28 Mar 2020 11:07:38 +0200 Toomas Soome tsoome@me=2Ecom said > > On 28=2E Mar 2020, at 05:28, Chris wrote: > >=20 > > On Fri, 27 Mar 2020 18:31:50 -0700 bsd-lists@BSDforge=2Ecom > > said > >=20 > >> On Fri, 27 Mar 2020 17:27:27 -0600 Warner Losh imp@bsdimp=2Ecom said > >> > On Fri, Mar 27, 2020 at 4:54 PM Chris wrote= : > >> > > > On Sat, 28 Mar 2020 01:10:37 +0300 Andrey Fesenko f0andrey@gmail= =2Ecom > > said > >> > > > >> > > > On Sat, Mar 28, 2020 at 12:53 AM Chris > > wrote: > >> > > > > > >> > > > > On an experiment of the FreeBSD EFI implementation=2E I installe= d > >> > > > > a copy of releng/12 from install media=2E Which left me with: > >> > > > > # gpart show ada0 > >> > > > > =3D> 40 312581728 ada0 GPT (149G) > >> > > > > 40 409600 1 efi (200M) > >> > > > > 409640 31047680 2 freebsd-ufs (15G) > >> > > > > 31457320 7680000 3 freebsd-swap (3=2E7G) > >> > > > > 74788904 237792864 - free - (141G) > >> > > > > > >> > > > > On this Intel based system, I can stab the F12 key to pick > >> > > > > my UEFI bootable OS, or let it boot according to the order > >> > > > > I setup in the BIOS=2E So far, so good=2E > >> > > > > I needed a copy of releng/13 to also work with=2E Installed a co= py > >> > > > > from install media=2E Which left me with: > >> > > > > # gpart show ada0 > >> > > > > =3D> 40 312581728 ada0 GPT (149G) > >> > > > > 40 409600 1 efi (200M) > >> > > > > 409640 31047680 2 freebsd-ufs (15G) > >> > > > > 31457320 7680000 3 freebsd-swap (3=2E7G) > >> > > > > 39137320 532480 4 efi (260M) > >> > > > > 39669800 35119104 5 freebsd-ufs (17G) > >> > > > > 74788904 237792864 - free - (113G) > >> > > > > I *assumed* that the install would activate the new install, a= nd I > >> > > > > would boot straight into it=2E But no=2E I am still on the previou= s > >> > > > > install, and worse, I can't get into the new install -- even i= f > >> > > > > picking it via stabbing the F12 key=2E I *still* end up in the > > previous > >> > > > > install=2E So looking at what might be causing it=2E I found the > >> > following: > >> > > > > # releng/12 > >> > > > > # mount -t msdosfs /dev/ada0p1 /mnt/ > >> > > > > > >> > > > > # ls /mnt/efi/boot/ > >> > > > > BOOTx64=2Eefi > >> > > > > startup=2Ensh > >> > > > > > >> > > > > # cat /mnt/efi/boot/startup=2Ensh > >> > > > > BOOTx64=2Eefi > >> > > > > > >> > > > > # umount /mnt/ > >> > > > > > >> > > > > releng/13 > >> > > > > # mount -t msdosfs /dev/ada0p4 /mnt/ > >> > > > > > >> > > > > # ls /mnt/EFI/freebsd/ > >> > > > > loader=2Eefi > >> > > > > > >> > > > > Why the difference? When will FreeBSD (u)EFI work as expected? > >> > > > > > >> > > > > Thanks in advance for any insights! > >> > > > > > >> > > > > >> > > > Require only single efi part > >> > > > > >> > > > See > >> > > > > >> > > > >> > > > https://forums=2Efreebsd=2Eorg/threads/two-freebsd-installations-and-efi=2E73= 968/ > >> > > Thanks for they reply, and link, Andrey! > >> > > Well that confirms it=2E FreeBSD, unlike other OS implementations, w= ill > > not > >> > > permit booting your chosen "version" via EFI=2E > >> > > Firstly, *huge* thanks for your informative reply, Warner! > >> > It does today=2E If you use efibootmgr, you can boot exactly what you = want=2E > > I > >> > do it all the time=2E=2E=2E Though your BIOS may overwrite the EFI vars i= f you > >> > set too many (I'm looking at you supermicro)=2E When you use the efi > > BootXXXX > >> > variables, it's possible to boot one of many different things on the > >> > system=2E=2E=2E Though I've not done 11, just 12 and current=2E > >> Well=2E That's the thing=2E I *am* on 12 && 13=2E Well *trying* to get into = 13=2E > >> When I started this whole thing, I had some 15 entries returned by > >> efibootmgr(8) -v=2E > >> So I trimmed the list down to the 2 my BIOS presents as UEFI: > >> Boot0015 UEFI: WDC WD1600JS-98MHB0 > >> PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0xffff,0x0)/HD(4,GPT,6688c5af-6f93= =2E=2E=2E > >> Boot0011* UEFI: WDC WD1600JS-98MHB0 > >> PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0xffff,0x0)/HD(1,GPT,260d2df2-6a10= =2E=2E=2E > >> another entry created when I installed releng/13: > >> Boot0014 FreeBSD (ada0p4) > >> > > HD(4,GPT,6688c5af-6f93-11ea-adbb-4c72b9f5e07f,0x2553028,0x82000)/File(\= EFI\free=2E=2E=2E > >> and a Windows reference (currently not installed)=2E > >> I activated *both* Boot0015 and Boot0011: > >> efibootmgr -a 0015 0011=2E Output confirmed success=2E Bounced box, choose > >> Boot0015=2E Which booted > >> initial releng/12 install=2E Fail=2E OK Try something different; > >> efibootmgr -a 0014 -L FreeBSD-13=2E Output confirms the -L switch is bro= ken, > >> but 00114 is active=2E > >> Bounce box && choose 0014=2E Boots to initial releng/12 install=2E > >> Conclusion; FreeBSD EFI/ESP is not ready for prime time=2E :( > >> Thanks again for the reply, Warner! :) > >> --Chris >=20 >=20 Thank you very much for your reply, Toomas=2E > How loader is working is that it does search for *first* =E2=80=9Cusable= =E2=80=9D freebsd > partition and will use it=2E Usable is defined as having /boot/loader=2Eefi=2E Yes, I understand how this is currently implemented=2E :) >=20 > Therefore, you may have 2 or more freebsd instances on the disk, it reall= y > does not matter, only first is used=2E If you have multiple disks, you can = have > different order on second disk=2E Just a thought along these lines=2E=2E=2E If, for every install, an additional ef= i ESP were created (how it's done now)=2E If the search were for the *first* usable freebsd slice/partition were done incrementally, that is, counting from the ESPs current location on disk=2E It would more often than not, find the install that created ESP it's working from=2E Just one possibility that could be done at near zero cost=2E >=20 > Why it is so? We do build loader=2Eefi and we do copy it to the ESP, and > currently there is no way to tell where is the root file system=2E See above=2E >=20 > How could we tell where from to load the OS? Well, there are few options = to > think about: >=20 > 1=2E record the hint into the loader=2Eefi binary - this would need special > installer and would break signing=2E > 2=2E record EFI variable - it should reflect OS instance version and that > version should be bound with specific loader binary=2E Coordination is pain > there=2E > 3=2E record partition to loader=2Eenv file=20 >=20 > The current loader code is reading "/efi/freebsd/loader=2Eenv=E2=80=9D from= ESP=2E IMO > this sounds most promising, but would need support from installer or manu= al > setup=2E Would work as is with multiple ESP instances=2E Would need versioned > /efi/freebsdXX directories for single shared ESP and installer update=2E >=20 > 4=2E We still do have BE menu in loader, populated automatically from zfs > snapshots=2E It can be complemented with entries from file based index (I w= rote > about that idea already)=2E This would allow to create simple switch to > different instance or initiate chain load of third party boot loader=2E Only drawback is that it is limited to zfs(8)=2E Other thoughts that come to mind: - embedding the GUID hash into the loader that points to the new install=2E - menu, similar to the BE menu you indicated above=2E - adding an additional jump in the UEFI entry already created for the insta= ll that points to the install associated with the newly added loader=2E Lastly=2E It appears that much of what we're currently using was simply hijacked from Linux=2E Why? We're not a Linux=2E The UEFI spec is fairly broad, and gives much leeway for implementing something quite exotic, if we were so inclined=2E Thanks again, for all the time you put into your reply, Toomas! :) --Chris >=20 > just few bits, > toomas >=20 > >> > > > > That is; not without dropping > >> > > to the loader prompt, or changing the status of slices, or boot en= tries > >> > > prior to > >> > > reboot=2E :( > >> > > > >> > > Not needed=2E > >> > > > > Looks like I'll need to install a third party OS, or bootmanag= er to > > use > >> > > FreeBSD=2E > >> > > Sigh=2E=2E=2E > >> > > > >> > > Again, not needed=2E Though there may be a few things that need to b= e > > MFC'd > >> > if you want 11 on that list=2E=2E=2E > >> > > > > There *may* be hope in the future ( > >> > > https://bugs=2Efreebsd=2Eorg/bugzilla/show_bug=2Ecgi?id=3D207940) > >> > > > >> > > This would require you to stop to select on the way up=2E=2E=2E Or am I = not > >> > understanding what you want? > >> > > We should add that functionality to loader=2Eefi, since boot1=2Eefi is= in > > the > >> > process of being deprecated=2E=2E=2E It should be a simple LUA script ther= e=2E=2E=2E > > Isn't everything confined to stand/ ? > > I'd like to try and write all this so that FreeBSD performs EFI/ESP boo= ting > > in a more intuitive way=2E It seems odd to me, that I can install Windows= , and > > it'll add FreeBSD to the (efi) boot menu, but not vis-a-vis=2E > >=20 > > --Chris > >> > > > > Thanks again, Andrey=2E Greatly appreciated! :) > >> > >