Date: Wed, 11 Oct 2023 09:57:35 -0700 From: Mark Millard <marklmi@yahoo.com> To: void <void@f-m.fm> Cc: freebsd-arm@freebsd.org Subject: Re: unable to boot latest 14-stable Message-ID: <005C6B77-2ED1-4FA9-9A6D-B97FB9E8ADD8@yahoo.com> In-Reply-To: <ZSasPYs3jCZ7Si6U@int21h> References: <ZSXPnTXAdSJYrBDX@int21h> <841CA663-55E0-4EAD-B700-66DC884B50FA@yahoo.com> <ZSZotIDLHZE1SzwL@int21h> <ZSZ3vATEEGO3N8-T@int21h> <55C64D6A-2712-408A-B7A7-BA8081CA99FC@yahoo.com> <ZSasPYs3jCZ7Si6U@int21h>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 11, 2023, at 07:07, void <void@f-m.fm> wrote: > On Wed, Oct 11, 2023 at 06:01:05AM -0700, Mark Millard wrote: >=20 >> You replaced the older EFI/boot/bootaa64.efi on the msdosfs >> with a newer one. The newer one knows about and classifies >> the zpool feature as known-to-be supported by itself. Or so >> I expect: I've not tracked down the source code changes >> between the specific versions in question. >=20 > I can handle changes if I know about them, if there's somewhere > to check where breaking changes like this and their consequence are = always noted, in order to accomodate the change in any upgrade process. >=20 > I've checked in = https://cgit.freebsd.org/src/log/?h=3Dstable%2F14&qt=3Dgrep&q=3Dbootaa64.e= fi >=20 > returns one entry from 2018. >=20 > With the non-working efi: > stat -f "%Sm %N" -t %Y%m%d%H%M%S bootaa64.efi > 20220512075622 bootaa64.efi >=20 > The working one: > 20231006092102 bootaa64.efi >=20 > How can I track breaking changes like this in future? The standard instructions for doing FreeBSD upgrades do not treat zpool upgrades as part of the procedure (separate notes): no such zpool upgrade is required for FreeBSD to be updated. zpool upgrades can be done later or not done at all. zpool upgrades are never automatic in updates. I'll stick with my explicit openzfs-2.1-freebsd feature enable status until after there is an official release of 14.0 that supports openzfs-2.2 . This is true even though I use main [so: 15]. I may not update to enable openzfs-2.2 features immediately after 14.0 is officially released: no rush for my context. I will upgrade to openzfs-2.2 , not to everything 15 supports. (This is just an example of a valid handling.) (I do have a separate boot partition on one machine sometimes used to help with testing when openzfs imports lead to problems.) I think the "or not done at all" allowed status contributes to why openzfs imports do not get UPDATING notes about the import adding support for a new pool feature, even if read-only status is not necessarily sufficient to be able to completely ignore the feature in the loader. As things are, it seems best to just think of having a separate zpool upgrade activity --that does not start by doing the actual zpool upgrade. Instead it starts by making the environment (e.g., the loader) ready to handle the upgrade. Such applies no matter when the activity is to be done, such as between FreeBSD updates. Still, I'd like it if UPDATING noted when openzfs imports add support of new zpool features . =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?005C6B77-2ED1-4FA9-9A6D-B97FB9E8ADD8>