Re: 13.3R's installworld killed system--please help!

Mark Millard <marklmi@yahoo.com> wrote:

     Thanks much for this reply.  It looks quite interesting.

> Scott Bennett <bennett_at_sdf.org> wrote on
> Date: Mon, 09 Sep 2024 02:13:19 UTC :
>
> > ax61@disroot.org wrote:
> > 
> > Thank you for replying!
> > . . .
> > >
> > > Looks like did not update the boot loader.
> > 
> > Looks like what did not update it?
> > My understanding was that rewriting the boot code was a step incorporated
> > into installworld at least a couple of major releases ago.
>
> Nope.
>
> It looks like the 13.* UDPATING text never got the additional
> wording that was added to help avoid confusions, including
> 13.4-RC3 not having it.
>
> So, quoting from 14.1's UPDATING . . .
> [See the "2)" and "3) . . . New bootblocks . . ." wording and
> the later "The EFI boot loader . . . For ZFS booting  . . ."
> wording. They indicate, for a ZFS boot "drive"/partition/. . .,
> explicitly upgrading bootblocks (if any) and/or boot loaders
> before doing a zpool upgrade.]
>
> QUOTE
> ZFS notes
> ---------
> When upgrading the boot ZFS pool to a new version (via zpool upgrade),
> always follow these three steps:
>
> 1) recompile and reinstall the ZFS boot loader and boot block
> (this is part of "make buildworld" and "make installworld")

     So does 13.3-RELEASE include the above in its buildworld and
installworld make(1) targets?  In my tower's case, no pools have been
"zpool upgrade"d past 12.4-RELEASE-p2.  Also, as noted in my previous
posting, I've run "gpart bootcode" to install the 13.3-RELEASE version
of the boot loader and boot block onto both of the boot drives, but
nothing changed in what happens when (trying to) boot the system.
>
> 2) update the ZFS boot block on your boot drive (only required when
> doing a zpool upgrade):
>
> When booting on x86 via BIOS, use the following to update the ZFS boot
> block on the freebsd-boot partition of a GPT partitioned drive ada0:
> gpart bootcode -p /boot/gptzfsboot -i $N ada0
> The value $N will typically be 1. For EFI booting, see EFI notes.

     So done.
>
> 3) zpool upgrade the root pool. New bootblocks will work with old
> pools, but not vice versa, so they need to be updated before any
> zpool upgrade.

     As pointed out above, no pools on the tower have been upgraded since
the installworld that killed the system.
>
> Non-boot pools do not need these updates.

     Okay and good to know.
>
> EFI notes
> ---------
>
> There are two locations the boot loader can be installed into. The
> current location (and the default) is \efi\freebsd\loader.efi and using
> efibootmgr(8) to configure it. The old location, that must be used on
> deficient systems that don't honor efibootmgr(8) protocols, is the
> fallback location of \EFI\BOOT\BOOTxxx.EFI. Generally, you will copy
> /boot/loader.efi to this location, but on systems installed a long time
> ago the ESP may be too small and /boot/boot1.efi may be needed unless
> the ESP has been expanded in the meantime.
>
> Recent systems will have the ESP mounted on /boot/efi, but older ones
> may not have it mounted at all, or mounted in a different
> location. Older arm SD images with MBR used /boot/msdos as the
> mountpoint. The ESP is a MSDOS filesystem.
>
> The EFI boot loader rarely needs to be updated. For ZFS booting,
> however, you must update loader.efi before you do 'zpool upgrade' the
> root zpool, otherwise the old loader.efi may reject the upgraded zpool
> since it does not automatically understand some new features.
>
> See loader.efi(8) and uefi(8) for more details.
> END QUOTE

     The EFI information is also good to know in case I ever get a system
that is new enough to support EFI.
     Back to the problem at hand ... is it possible that the new boot program
and boot block(s) actually have a problem with a boot pool that has *not* been
"zpool upgrade"d?  IOW, would a "zpool upgrade system" conceivably fix the
problem, enabling the new boot block(s) and boot program to work?

					Scott