Date: Sun, 7 Aug 2022 15:32:35 -0400 From: Glen Barber <gjb@freebsd.org> To: Mark Millard <marklmi@yahoo.com> Cc: Warner Losh <imp@bsdimp.com>, "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, Ed Maste <emaste@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use Message-ID: <EA1CDEC5-A29E-43C5-9437-050CDBEC2233@freebsd.org> In-Reply-To: <A1AA705B-531D-45A2-9A1F-89F759550D3A@yahoo.com> References: <A1AA705B-531D-45A2-9A1F-89F759550D3A@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Correct, it was set to =E2=80=9C0=E2=80=9D for these builds.
I honestly do not have any idea where the problems you are seeing are creepi=
ng in.
Should it be set back to =E2=80=9C1=E2=80=9D? I=E2=80=99m not sure how to p=
roceed 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:
>=20
> =EF=BB=BFThe oddities look like indicated below.
>=20
> # mdconfig -u md1 -f FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220805-e24c5=
c60d72-257129.img
> # gpart show
> . . .
>=20
> =3D> 63 10485697 md1 MBR (5.0G)
> 63 1985 - free - (993K)
> 2048 102400 1 fat32lba [active] (50M)
> 104448 10381312 2 freebsd (5.0G)
>=20
> =3D> 0 10381312 md1s2 BSD (5.0G)
> 0 10381312 1 freebsd-ufs (5.0G)
>=20
> =3D> 0 10381312 ufsid/62ed01f3345560d8 BSD (5.0G)
> 0 10381312 1 freebsd-ufs (5.0G)
>=20
> =3D> 0 10381312 ufs/rootfs BSD (5.0G)
> 0 10381312 1 freebsd-ufs (5.0G)
>=20
> So: ufs/rootfs apparently identifies the BSD instead of the
> freebsd-ufs . Same for the ufsid/* . This leads to:
>=20
> # gpart show -p=20
> . . .
>=20
> =3D> 63 10485697 md1 MBR (5.0G)
> 63 1985 - free - (993K)
> 2048 102400 md1s1 fat32lba [active] (50M)
> 104448 10381312 md1s2 freebsd (5.0G)
>=20
> =3D> 0 10381312 md1s2 BSD (5.0G)
> 0 10381312 md1s2a freebsd-ufs (5.0G)
>=20
> =3D> 0 10381312 ufsid/62ed01f3345560d8 BSD (5.0G)
> 0 10381312 ufsid/62ed01f3345560d8a freebsd-ufs (5.0G)
>=20
> =3D> 0 10381312 ufs/rootfs BSD (5.0G)
> 0 10381312 ufs/rootfsa freebsd-ufs (5.0G)
>=20
> freebsd-ufs has the unexpected label: ufs/rootfsa
>=20
> # 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
>=20
> 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 ):
>=20
> if [ "${PART_SCHEME}" =3D "MBR" ]; then
> chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s ${FAT_SIZ=
E} ${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
>=20
> Note that the newfs command references /dev/${mddev}s2a instead
> of /dev/${mddev}s2 but the rootfs label ends up referencing
> /dev/${mddev}s2 .
>=20
> 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?
>=20
> Or is this a different kind of bug?
>=20
> I'll not repeat the kinds of explorations that I reported last
> week unless someone wants to request something.
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
>=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EA1CDEC5-A29E-43C5-9437-050CDBEC2233>