Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use

The oddities look like indicated below.

# mdconfig -u md1 -f FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220805-e24c5c60d72-257129.img
# gpart show
. . .

=>      63  10485697  md1  MBR  (5.0G)
        63      1985       - free -  (993K)
      2048    102400    1  fat32lba  [active]  (50M)
    104448  10381312    2  freebsd  (5.0G)

=>       0  10381312  md1s2  BSD  (5.0G)
         0  10381312      1  freebsd-ufs  (5.0G)

=>       0  10381312  ufsid/62ed01f3345560d8  BSD  (5.0G)
         0  10381312                       1  freebsd-ufs  (5.0G)

=>       0  10381312  ufs/rootfs  BSD  (5.0G)
         0  10381312           1  freebsd-ufs  (5.0G)

So: ufs/rootfs apparently identifies the BSD instead of the
freebsd-ufs . Same for the ufsid/* . This leads to:

# gpart show -p 
. . .

=>      63  10485697    md1  MBR  (5.0G)
        63      1985         - free -  (993K)
      2048    102400  md1s1  fat32lba  [active]  (50M)
    104448  10381312  md1s2  freebsd  (5.0G)

=>       0  10381312   md1s2  BSD  (5.0G)
         0  10381312  md1s2a  freebsd-ufs  (5.0G)

=>       0  10381312   ufsid/62ed01f3345560d8  BSD  (5.0G)
         0  10381312  ufsid/62ed01f3345560d8a  freebsd-ufs  (5.0G)

=>       0  10381312   ufs/rootfs  BSD  (5.0G)
         0  10381312  ufs/rootfsa  freebsd-ufs  (5.0G)

freebsd-ufs has the unexpected label: ufs/rootfsa

# ls -Tld /dev/ufs/*
crw-r-----  1 root  operator  0x6c Aug  6 20:19:58 2022 /dev/ufs/rootfs
crw-r-----  1 root  operator  0x6e Aug  6 20:19:58 2022 /dev/ufs/rootfsa

Things were actually set up for ufs/rootfs naming as the
identification of the freebsd-ufs content, per the
release/tools/arm.subr commands ( from last month's
main-n256584-5bc926af9fd1 ):

        if [ "${PART_SCHEME}" = "MBR" ]; then
                chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s ${FAT_SIZE} ${mddev}
                chroot ${CHROOTDIR} gpart set -a active -i 1 ${mddev}
                chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F ${FAT_TYPE} /dev/${mddev}s1
                chroot ${CHROOTDIR} gpart add -t freebsd ${mddev}
                chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2
                chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k ${mddev}s2
                chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
        fi

Note that the newfs command references /dev/${mddev}s2a instead
of /dev/${mddev}s2 but the rootfs label ends up referencing
/dev/${mddev}s2 .

Is having "0 10381312" for the md*s2 and for the md*s2a a
fundamental problem? Does freebsd-ufs ( a.k.a. md*s2a ) need
to be moved to a different (non-zero) offset inside BSD?

Or is this a different kind of bug?

I'll not repeat the kinds of explorations that I reported last
week unless someone wants to request something.

===
Mark Millard
marklmi at yahoo.com