Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)

On Mon, Jan 21, 2019 at 6:13 AM Lev Serebryakov <lev_at_freebsd.org> wrote:

> On 21.01.2019 15:59, Toomas Soome wrote:
>
> >>>>> Is too complicated? Boot1.efi doesn't allow that, but loader.efi
> does.
> >>>> loader.efi lives on ESP partition, do I understand it right? So, it
> >>>> could not be damaged with "bad" upgrade?
> >>>
> >>> It could, unless the backup is created.
> >> Does it live on code (root) FS or ESP? I understand, that when you
> >> upgrade ESP partition, you could ruin it, but typically root FS is
> >> upgraded much more often than ESP/boot0/boot1 parts.
> >
> > If you are using boot1.efi, the loader.efi is in OS /boot/loader.efi
> annd boot1.efi is stored to ESP and will execute loader.efi as bios boot2
> programs do.
>  So, Warner's advice to use
>
> set currdev=diskXpY:
> boot
>
>  with loader.efi is not direct replacement to choosing boot partition
> via boot0 now (as "boot1.eif doesn't allow that" and /boot/loader.efi
> could be broken with unsuccessful upgrade), am I right?
>

Yes. And after my latest fixes, you can add 'set currdev=diskXpY' to ESP's
/efi/freebsd/loader.env as well. boot1.efi is really super limited and
tries too much DWIM to be useful, so it's being retired in favor of
loader.efi.


> > we will drop boot1.efi (it is already dropped in illumos btw), and will
> only use loader.efi - and in this case, the loader.efi is installed to ESP
> and will only start the kernel.
>   Ok, I need to wait for it.
>

I think all the features are there. You can install loader.efi as you used
to install boot1.efi and have it work as well or better than boot1.efi.


> > But then again, if you are using stock (generic) OS on embedded system,
> you are already doing it wrong and will get into the trouble sooner or
> later:)
>   I can not say, is NanoBSD "stock" or not :-)
>

One of the big reasons I did the latest changes was to make it possible for
NanoBSD to work better.

Warner