14.0-APLHA1 snapshot use of kyua: An odd backtrace that appeared on the aarch64 console (and logs)

I ran the block of zfs tests on a snapshot 14.0-APLHA1 install
used to boot and operate a Windows Dev Ket 2023. I just noticed
a non-panic/non-crash backtrace had been output to the console
(and related logs):

. . .
GEOM: md0: the primary GPT table is corrupt or invalid.
GEOM: md0: using the secondary instead -- recovery strongly advised.
GEOM: md1: the primary GPT table is corrupt or invalid.
GEOM: md1: using the secondary instead -- recovery strongly advised.
GEOM: md2: the primary GPT table is corrupt or invalid.
GEOM: md2: using the secondary instead -- recovery strongly advised.
GEOM: md3: the primary GPT table is corrupt or invalid.
GEOM: md3: using the secondary instead -- recovery strongly advised.
got error -2 on name 1 on op 3
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
zfs_lookup_internal() at zfs_lookup_internal+0xb8
zfs_rename() at zfs_rename+0x128
zfs_replay_rename() at zfs_replay_rename+0xa4
zil_replay_log_record() at zil_replay_log_record+0x1b0
zil_parse() at zil_parse+0x360
zil_replay() at zil_replay+0xdc
zfsvfs_setup() at zfsvfs_setup+0x1fc
$x.0() at $x.0+0x6b0
vfs_domount_first() at vfs_domount_first+0x24c
vfs_domount() at vfs_domount+0x2cc
vfs_donmount() at vfs_donmount+0x844
sys_nmount() at sys_nmount+0x60
do_el0_sync() at do_el0_sync+0x520
handle_el0_sync() at handle_el0_sync+0x44
--- exception, esr 0x56000000
GEOM_NOP: Device md0.nop created.
GEOM_NOP: Device md1.nop created.
GEOM_NOP: Device md2.nop created.
GEOM_NOP: Device md3.nop created.
GEOM_NOP: Device md4.nop created.
GEOM_NOP: Device md5.nop created.
GEOM_NOP: Device md0.nop removed.
GEOM_NOP: Device md1.nop removed.
GEOM_NOP: Device md2.nop removed.
GEOM_NOP: Device md3.nop removed.
GEOM_NOP: Device md4.nop removed.
GEOM_NOP: Device md5.nop removed.
. . .

For reference . . .

I had set up md0 .. md5, each 1g swap backed, and, in
/etc/kyua/kyua.conf , had used:

test_suites.FreeBSD.disks = '/dev/md0 /dev/md1 /dev/md2 /dev/md3 /dev/md4 /dev/md5'

(I the future I'll use file backed that are larger.)


Note: After dropping a copy of the extra files from the rpi-arm64
snapshots's msdosfs into the rock64 installation's msdosfs, the
rock64 snapshot install on the USB media then can boot and operate
every aarch64 system I have access to. (It is something I've done
for a long time.) The rock64 having an unusually large area for
u-boot related dd'ing could serve well for dd'ing various
alternatives and testing them: overlapping the other file systems
is unlikely. Such can be handy for having a uniform testing
environment.


===
Mark Millard
marklmi at yahoo.com