On Sat, 28 Mar 2020 11:07:38 +0200 Toomas Soome tsoome_at_me.com said > > 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 > > Thank you very much for your reply, Toomas. > 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. Yes, I understand how this is currently implemented. :) > > 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. Just a thought along these lines... If, for every install, an additional efi ESP were created (how it's done now). If the search were for the *first* usable freebsd slice/partition were done incrementally, that is, counting from the ESPs current location on disk. It would more often than not, find the install that created ESP it's working from. Just one possibility that could be done at near zero cost. > > 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. See above. > > 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. Only drawback is that it is limited to zfs(8). Other thoughts that come to mind: - embedding the GUID hash into the loader that points to the new install. - menu, similar to the BE menu you indicated above. - adding an additional jump in the UEFI entry already created for the install that points to the install associated with the newly added loader. Lastly. It appears that much of what we're currently using was simply hijacked from Linux. Why? We're not a Linux. The UEFI spec is fairly broad, and gives much leeway for implementing something quite exotic, if we were so inclined. Thanks again, for all the time you put into your reply, Toomas! :) --Chris > > 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! :) > >> > >Received on Sat Mar 28 2020 - 18:56:50 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:23 UTC