Re: unable to boot latest 14-stable

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:
> 
>> 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.
> 
> 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.
> 
> I've checked in https://cgit.freebsd.org/src/log/?h=stable%2F14&qt=grep&q=bootaa64.efi
> 
> returns one entry from 2018.
> 
> With the non-working efi:
> stat -f "%Sm %N" -t %Y%m%d%H%M%S bootaa64.efi
> 20220512075622 bootaa64.efi
> 
> The working one:
> 20231006092102 bootaa64.efi
> 
> 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 .

===
Mark Millard
marklmi at yahoo.com