Date: Sat, 6 Aug 2022 21:10:23 -0700 From: Mark Millard <marklmi@yahoo.com> To: Glen Barber <gjb@FreeBSD.org>, Warner Losh <imp@bsdimp.com>, "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> Cc: Ed Maste <emaste@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use Message-ID: <A1AA705B-531D-45A2-9A1F-89F759550D3A@yahoo.com> References: <A1AA705B-531D-45A2-9A1F-89F759550D3A.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
The oddities look like indicated below.
# mdconfig -u md1 -f =
FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220805-e24c5c60d72-257129.img
# gpart show
. . .
=3D> 63 10485697 md1 MBR (5.0G)
63 1985 - free - (993K)
2048 102400 1 fat32lba [active] (50M)
104448 10381312 2 freebsd (5.0G)
=3D> 0 10381312 md1s2 BSD (5.0G)
0 10381312 1 freebsd-ufs (5.0G)
=3D> 0 10381312 ufsid/62ed01f3345560d8 BSD (5.0G)
0 10381312 1 freebsd-ufs (5.0G)
=3D> 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=20
. . .
=3D> 63 10485697 md1 MBR (5.0G)
63 1985 - free - (993K)
2048 102400 md1s1 fat32lba [active] (50M)
104448 10381312 md1s2 freebsd (5.0G)
=3D> 0 10381312 md1s2 BSD (5.0G)
0 10381312 md1s2a freebsd-ufs (5.0G)
=3D> 0 10381312 ufsid/62ed01f3345560d8 BSD (5.0G)
0 10381312 ufsid/62ed01f3345560d8a freebsd-ufs (5.0G)
=3D> 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}" =3D "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.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A1AA705B-531D-45A2-9A1F-89F759550D3A>