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

[Lev Serebryakov]

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?

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

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

-- 
// Lev Serebryakov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20190121/4b093d96/attachment.sig>