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

> On 21 Jan 2019, at 14:45, Lev Serebryakov <lev_at_FreeBSD.org> wrote:
> 
> On 21.01.2019 15:39, 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.
> 
> -- 
> // Lev Serebryakov
> 

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.

As UEFI does not *replace* the program which did call StartImage() but both do stay in memory (so you have both boot1.efi and loader.efi in memory), and boot1.efi does not add any significant features, 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.

This also does mean that in ideal world, the update should create backup of boot program in ESP (this actually also does apply to boot1.efi), but the default ESP created by FreeBSD used to be too small for that.

With normal systems it should not be an issue because you can always boot from usb stick/cd (image), but with embedded systems it may be significant issue. 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:)

rgds,
toomas