FreeBSD 13/stable and zpool upgrade

[Warner Losh]

On Fri, Feb 19, 2021 at 1:41 PM David Marec <david.marec at lapinbilly.eu>
wrote:

> Hi,
>
> On 19/02/2021 19:24, Kurt Jaeger wrote:
>
>  > I suspect that your 'zpool upgrade' enabled things that weren't enabled
>  > before. This caused the old boot blocks to no longer work.
>
> Correct. That' s definitely the source of the booting issue.
>
>  > We should be better about upgrading boot blocks, but EFI is kinda new
> and
>  > kinda different
>
> EFI is able to boot any FreeBSD box for a while.
>
> The main issue is that the legacy way to upgrade these /bootcode and
> partcode/ not only does not work, but do bad things.
>
> # gpart bootcode -p /boot/gptzfsboot -i 1  ada0s1
>
> will install an old and inappropriate /partcode/.
>

Yes. it was a mistake to try to make EFI fit into that paradigm originally.
All the efifat stuff should be gone, but you misunderstand what gptzfsboot
is or can do.

When booting with EFI, the above command will have no effect because those
boot blocks will be ignored.

IMO,
> 'gptzfsboot' should be sweep off  along with 'boot1.efifat' ( by calling
> 'make delete-old') or be built with the right 'BOOTx64.EFI', which
> actually is`/boot/loader.efi` .
>

We can't do that. gptzfsboot is for something else that we can't get rid
of: BIOS/CMS booting. It's never been used for EFI booting at all. There's
no way to for EFI to use it, nor is there anyway for us to build it to just
work. You have to copy BOOTx64.efi to your ESP. What we could do, but don't
currently, is automate this process. That's been bogged down in
implementation details. It's easy if there's only one, but if you have a
USB stick installed, you don't want that to accidentally be upgraded, for
example... and I have test boxes with a dozen ESPs to test different boot
scenarios... And multiboot systems also can be screwed up by automatically
copying things into the ESP...

Warner