Re: unable to boot latest 14-stable

From: Mark Millard <marklmi_at_yahoo.com>
Date: Wed, 11 Oct 2023 13:01:05 UTC
On Oct 11, 2023, at 03:23, void <void@f-m.fm> wrote:

> On Wed, Oct 11, 2023 at 10:19:48AM +0100, void wrote:
>> Do you think the following might allow the system to boot:
>> 
>> 1. get 14-stable beta5 and on another freebsd box, mount its msdos partition
>> with mdconfig -f
>> 
>> 2. unplug the usb3 disk from the rpi, plug it into the freebsd box, do the same as [1]
>> 
>> 3. copy the contents of [1] into [2]
>> 
>> I'm worried the process might clobber something GELI needs though, rendering the zpool/disk permanently inaccessible.
> 
> Following this process allowed it to boot. GELI wasn't clobbered.
> 
> The daemon menu defaults to "5. Cons: Video" so this must be changed to make the serial console fully work again.
> 
> The issue, seemingly, wasn't one with the zpool itself, or unknown features.

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.

During development there is can be a time when a new zpool
feature that needs to be checked explicitly by the loader
does not yet have a loader that yes does so: they are
commonly not done in one overall step.

I'll note that 15 has for a time already gotten a zpool
feature that is not part of openzfs-2.2 . (14 is targetting
2.2 .)

> After getting it to boot:
> 
> # zpool status -v
>  pool: zroot
>   state: ONLINE
>     scan: scrub repaired 0B in 01:20:01 with 0 errors on Sun Oct  1 22:09:40 2023
>     config:
> 
>     NAME         STATE     READ WRITE CKSUM
>     zroot        ONLINE       0     0     0
>         da0p3.eli  ONLINE       0     0     0
> 
>         errors: No known data errors

Not a surprise. The loader and FreeBSD kernel/world are separate
issues for handling new zpool updates and checking known-supported
status.

> I've saved onto another machine the problematic msdos partition contents so I can try and work out what's going on.


===
Mark Millard
marklmi at yahoo.com