From nobody Mon Sep 09 21:19:07 2024 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4X2fps5GVLz5V4rj for ; Mon, 09 Sep 2024 21:19:17 +0000 (UTC) (envelope-from bennett@sdf.org) Received: from mx.sdf.org (mx.sdf.org [205.166.94.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mx.sdf.org", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2fps2CDQz4rTt for ; Mon, 9 Sep 2024 21:19:17 +0000 (UTC) (envelope-from bennett@sdf.org) Authentication-Results: mx1.freebsd.org; none Received: from sdf.org (IDENT:bennett@rie.sdf.org [205.166.94.4]) by mx.sdf.org (8.18.1/8.14.3) with ESMTPS id 489LJAmo018852 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 9 Sep 2024 21:19:11 GMT DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sdf.org; s=sdf.org; t=1725916751; bh=vARnI8DhrTrdT6lS9P+7OHJdBmOJDbHh8ehvm9+s7Fk=; h=From:Date:To:Subject:Cc:References:In-Reply-To; b=Yc04dUVj9/gexCwHXYYWmXeJtlmkuW3lLDt4XZNYSdV4KeXcSkolcQzleIEyzlKZQ 77l123pIpymt2cYX3HrAMPUoqwbqLq8eImZjMbwj+WOA5twC3UPIfIP689Lx3Ndwym km8/p5WpDu+UBxNUc/237oHUnvzxgLJ7Wu6hF0u4= Received: (from bennett@localhost) by sdf.org (8.18.1/8.12.8/Submit) id 489LJ7Op009237; Mon, 9 Sep 2024 16:19:07 -0500 (CDT) From: Scott Bennett Message-Id: <202409092119.489LJ7Op009237@sdf.org> Date: Mon, 09 Sep 2024 16:19:07 -0500 To: marklmi@yahoo.com Subject: Re: 13.3R's installworld killed system--please help! Cc: ax61@disroot.org, freebsd-stable@freebsd.org References: <6C9B265B-E315-4E88-B090-3B89C91C08A4.ref@yahoo.com> <6C9B265B-E315-4E88-B090-3B89C91C08A4@yahoo.com> <202409090714.4897EDwZ001861@sdf.org> In-Reply-To: User-Agent: Heirloom mailx 12.5 6/20/10 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:14361, ipnet:205.166.94.0/24, country:US] X-Rspamd-Queue-Id: 4X2fps2CDQz4rTt Mark Millard wrote: > On Sep 9, 2024, at 00:14, Scott Bennett wrote: > > > Mark Millard wrote: > > > > Thanks much for this reply. It looks quite interesting. > > > >> Scott Bennett 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