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

From: Lev Serebryakov <lev_at_FreeBSD.org>
Date: Mon, 21 Jan 2019 16:13:46 +0300
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


Received on Mon Jan 21 2019 - 12:13:52 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:20 UTC