> On 21 Jan 2019, at 14:45, Lev Serebryakov <l...@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
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
