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

On Sat, 28 Mar 2020 12:57:21 -0700
Chris <bsd-lists_at_BSDforge.com> wrote:

> On Sat, 28 Mar 2020 11:07:38 +0200 Toomas Soome tsoome_at_me.com said
> 

(snip)

> 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. :)

Some explanation about the boot order by boot1.efi.

 1. Try the drive where running boot1.efi is read from.
 2. If failed, try drives as recognized by UEFI firmware.

On each drive, ZFS pool is tried first, and if all fail, or
nonexistent, UFS partitions are tried in partition No.order.


> > 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.

IIUC, UEFI firmware recognizes ESP only on first partition on the disk.
Some implementation could recongnize first non-top ESP, or even
multiple ESPs, but it's NOT promissing for ALL FIRMWARES IN THE WILD.
At worst, some firmwares could hesitate to boot from disk having
non-top ESP or multiple ESPs.


> > 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.

3. based solution looks good to me.

IMHO, assuming /efi/bootx[64|32].efi is boot1.efi or loader.efi
or EFI environment pointing to either one is properly used,

 *Use single ESP on the top of drive.

 *loader.env in unversioned /efi/freebsd contains common settings,
  including partition / pool list for loader menu.

 *loader.env in versioned /efi/freebsd** contains version-specific
  settings only and should not contain partition / pool list.
  This is because settings there could be missed on upgrading base.

 *Whichever boot1.efi or loader.efi reads loader.env in
  unversioned /efi/freebsd and show boot partition selection menu.

would be fine. As Warner noted, lua code could be used for loader.efi
case.


> 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

(snip)

> > >> > > 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?

Current patch has 10 seconds timeout and defaults to in-tree boot1.efi
behavior, if not user specified one.
IIRC, last version applicable to stable/11 has it, too.


> > >> > > 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 mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> 


-- 
Tomoaki AOKI    <junchoon_at_dec.sakura.ne.jp>