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

On Sep 9, 2024, at 00:14, Scott Bennett <bennett@sdf.org> wrote:

> 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.

So no updating would be required until you are preparing for later
doing a "zpool upgrade" of some sort.

> 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.

"gpart bootcode" only copies over the boot block as I understand. For
this old-sty;e BIOS context, as I understand, that boot block finds
and uses the boot loader that is in the ZFS based /boot/ . (But I do
not deal with old style BIOS contexts, as it happens.)

>> 
>> 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?

Such should not be an issue.

> IOW, would a "zpool upgrade system" conceivably fix the
> problem, enabling the new boot block(s) and boot program to work?

New zpool features are supposed to be optional, including for
booting. So: no.


===
Mark Millard
marklmi at yahoo.com