Re: When will the FreeBSD (u)EFI work?

On Sat, Mar 28, 2020 at 12:14 PM Toomas Soome <tsoome_at_me.com> wrote:
>
>
>
> > On 28. Mar 2020, at 05:28, Chris <bsd-lists_at_BSDforge.com> wrote:
> >
> > On Fri, 27 Mar 2020 18:31:50 -0700 bsd-lists_at_BSDforge.com <mailto:bsd-lists_at_BSDforge.com> said
> >
> >> On Fri, 27 Mar 2020 17:27:27 -0600 Warner Losh imp_at_bsdimp.com said
> >> > On Fri, Mar 27, 2020 at 4:54 PM Chris <bsd-lists_at_bsdforge.com> wrote:
> >> > > > On Sat, 28 Mar 2020 01:10:37 +0300 Andrey Fesenko f0andrey_at_gmail.com said
> >> > >
> >> > > > On Sat, Mar 28, 2020 at 12:53 AM Chris <bsd-lists_at_bsdforge.com> wrote:
> >> > > > >
> >> > > > > On an experiment of the FreeBSD EFI implementation. I installed
> >> > > > > a copy of releng/12 from install media. Which left me with:
> >> > > > > # gpart show ada0
> >> > > > > =>       40  312581728  ada0  GPT  (149G)
> >> > > > >          40     409600     1  efi  (200M)
> >> > > > >      409640   31047680     2  freebsd-ufs  (15G)
> >> > > > >    31457320    7680000     3  freebsd-swap  (3.7G)
> >> > > > >    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. So far, so good.
> >> > > > > I needed a copy of releng/13 to also work with. Installed a copy
> >> > > > > from install media. Which left me with:
> >> > > > > # gpart show ada0
> >> > > > > =>       40  312581728  ada0  GPT  (149G)
> >> > > > >          40     409600     1  efi  (200M)
> >> > > > >      409640   31047680     2  freebsd-ufs  (15G)
> >> > > > >    31457320    7680000     3  freebsd-swap  (3.7G)
> >> > > > >    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, and I
> >> > > > > would boot straight into it. But no. I am still on the previous
> >> > > > > install, and worse, I can't get into the new install -- even if
> >> > > > > picking it via stabbing the F12 key. I *still* end up in the previous
> >> > > > > install. So looking at what might be causing it. I found the
> >> > following:
> >> > > > > # releng/12
> >> > > > > # mount -t msdosfs /dev/ada0p1 /mnt/
> >> > > > >
> >> > > > > # ls /mnt/efi/boot/
> >> > > > > BOOTx64.efi
> >> > > > > startup.nsh
> >> > > > >
> >> > > > > # cat /mnt/efi/boot/startup.nsh
> >> > > > > BOOTx64.efi
> >> > > > >
> >> > > > > # umount /mnt/
> >> > > > >
> >> > > > > releng/13
> >> > > > > # mount -t msdosfs /dev/ada0p4 /mnt/
> >> > > > >
> >> > > > > # ls /mnt/EFI/freebsd/
> >> > > > > loader.efi
> >> > > > >
> >> > > > > 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.freebsd.org/threads/two-freebsd-installations-and-efi.73968/
> >> > > Thanks for they reply, and link, Andrey!
> >> > > Well that confirms it. FreeBSD, unlike other OS implementations, will not
> >> > > permit booting your chosen "version" via EFI.
> >> > > Firstly, *huge* thanks for your informative reply, Warner!
> >> > It does today. If you use efibootmgr, you can boot exactly what you want. I
> >> > do it all the time...  Though your BIOS may overwrite the EFI vars if you
> >> > set too many (I'm looking at you supermicro). When you use the efi BootXXXX
> >> > variables, it's possible to boot one of many different things on the
> >> > system...  Though I've not done 11, just 12 and current.
> >> Well. That's the thing. I *am* on 12 && 13. Well *trying* to get into 13.
> >> When I started this whole thing, I had some 15 entries returned by
> >> efibootmgr(8) -v.
> >> 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...
> >> Boot0011* UEFI: WDC WD1600JS-98MHB0
> >> PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0xffff,0x0)/HD(1,GPT,260d2df2-6a10...
> >> another entry created when I installed releng/13:
> >> Boot0014  FreeBSD (ada0p4)
> >> HD(4,GPT,6688c5af-6f93-11ea-adbb-4c72b9f5e07f,0x2553028,0x82000)/File(\EFI\free...
> >> and a Windows reference (currently not installed).
> >> I activated *both* Boot0015 and Boot0011:
> >> efibootmgr -a 0015 0011. Output confirmed success. Bounced box, choose
> >> Boot0015. Which booted
> >> initial releng/12 install. Fail. OK Try something different;
> >> efibootmgr -a 0014 -L FreeBSD-13. Output confirms the -L switch is broken,
> >> but 00114 is active.
> >> Bounce box && choose 0014. Boots to initial releng/12 install.
> >> Conclusion; FreeBSD EFI/ESP is not ready for prime time. :(
> >> Thanks again for the reply, Warner! :)
> >> --Chris
>
>
> How loader is working is that it does search for *first* “usable” freebsd partition and will use it. Usable is defined as having /boot/loader.efi.
>
> Therefore, you may have 2 or more freebsd instances on the disk, it really does not matter, only first is used. If you have multiple disks, you can have different order on second disk.
>
> Why it is so? We do build loader.efi and we do copy it to the ESP, and currently there is no way to tell where is the root file system.
>
> How could we tell where from to load the OS? Well, there are few options to think about:
>
> 1. record the hint into the loader.efi binary - this would need special installer and would break signing.
> 2. record EFI variable - it should reflect OS instance version and that version should be bound with specific loader binary. Coordination is pain there.
> 3. record partition to loader.env file
>
> The current loader code is reading "/efi/freebsd/loader.env” from ESP. IMO this sounds most promising, but would need support from installer or manual setup. Would work as is with multiple ESP instances. Would need versioned /efi/freebsdXX directories for single shared ESP and installer update.
>
> 4. We still do have BE menu in loader, populated automatically from zfs snapshots. It can be complemented with entries from file based index (I wrote about that idea already). This would allow to create simple switch to different instance or initiate chain load of third party boot loader.
>


With ZFS may work set bootfs on zpool