> 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. just few bits, toomas >> > > > > That is; not without dropping >> > > to the loader prompt, or changing the status of slices, or boot entries >> > > prior to >> > > reboot. :( >> > > >> > > Not needed. >> > > > > Looks like I'll need to install a third party OS, or bootmanager to use >> > > FreeBSD. >> > > Sigh... >> > > >> > > Again, not needed. Though there may be a few things that need to be MFC'd >> > if you want 11 on that list... >> > > > > There *may* be hope in the future ( >> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940) >> > > >> > > This would require you to stop to select on the way up... Or am I not >> > understanding what you want? >> > > We should add that functionality to loader.efi, since boot1.efi is in the >> > process of being deprecated... It should be a simple LUA script there... > Isn't everything confined to stand/ ? > I'd like to try and write all this so that FreeBSD performs EFI/ESP booting > in a more intuitive way. 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. > > --Chris >> > > > > Thanks again, Andrey. Greatly appreciated! :) >> > > >> _______________________________________________ >> freebsd-current_at_freebsd.org <mailto:freebsd-current_at_freebsd.org> mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current <https://lists.freebsd.org/mailman/listinfo/freebsd-current> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org <mailto:freebsd-current-unsubscribe_at_freebsd.org>" > > > _______________________________________________ > freebsd-current_at_freebsd.org <mailto:freebsd-current_at_freebsd.org> mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current <https://lists.freebsd.org/mailman/listinfo/freebsd-current> > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org <mailto:freebsd-current-unsubscribe_at_freebsd.org>"Received on Sat Mar 28 2020 - 08:08:03 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:23 UTC