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

Correct, it was set to “0” for these builds.

I honestly do not have any idea where the problems you are seeing are creeping in.

Should it be set back to “1”?  I’m not sure how to proceed otherwise.

Glen
Sent from my phone.
Please excuse my brevity and/or typos.

> On Aug 7, 2022, at 12:10 AM, Mark Millard <marklmi@yahoo.com> wrote:
> 
> 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
>