Date: Sun, 7 Aug 2022 12:50:21 -0700 From: Mark Millard <marklmi@yahoo.com> To: Glen Barber <gjb@freebsd.org> 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: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com> In-Reply-To: <EA1CDEC5-A29E-43C5-9437-050CDBEC2233@freebsd.org> References: <A1AA705B-531D-45A2-9A1F-89F759550D3A@yahoo.com> <EA1CDEC5-A29E-43C5-9437-050CDBEC2233@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Aug-7, at 12:32, Glen Barber <gjb@freebsd.org> wrote:
> Correct, it was set to =E2=80=9C0=E2=80=9D for these builds.
>=20
> I honestly do not have any idea where the problems you are seeing are =
creeping in.
>=20
> Should it be set back to =E2=80=9C1=E2=80=9D? I=E2=80=99m not sure =
how to proceed otherwise.
My guess is that if the release/tools/arm.subr line:
chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k =
${mddev}s2
was instead (note the added -b use):
chroot ${CHROOTDIR} gpart add -t freebsd-ufs -b 64k -a 64k =
${mddev}s2
then the line:
chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
would work as expected and things would still be aligned:
no aliasing of BSD vs. freebsd-ufs. (In part this is by
prior steps already having achieved alignment of BSD.)
But I do not know how to classify doing so: Work around?
Known required-procedure for -L rootfs to correctly
identify the the freebsd-ufs /dev/${mddev}s2a ?
Absent better information from folks that know more, I'd
suggest trying such an adjusted release/tools/arm.subr
next week, leaving kern.geom.part.mbr.enforce_chs=3D0 in
place, if such an experiment can be reasonable.
> Glen
> Sent from my phone.
> Please excuse my brevity and/or typos.
>=20
>> 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-e24c5c60d72-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_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
>>=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6AF28022-A8E7-46B3-B64E-99D217E9B6AC>