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

Mark Millard <marklmi@yahoo.com> wrote:

> 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.
>
     And so I still have no clue what destroyed my system's ability to boot
except that it appears to have happened as part of "make installworld".  I
also still have no idea how to fix it. :-(

> > 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.)
>
     Almost.  It copies the boot block from /boot/pmbr, and it copies the next
stage of the loader from /boot/gptzfsboot in my case into the tiny partition
of type freebsd-boot.  The initial boot block is too small to understand ZFS,
but can load the next stage from that boot partition, and that stage can
understand enough of ZFS to load files from /boot.

> >> 
> >> 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.
> >> 
> >> [remainder deleted --SB]

     All this is fair warning for the future, but still leaves me at square 1
with no solution in sight.  If anybody has any other ideas that might help
resurrect the system on my tower, please offer them.

					Scott