Date: Wed, 10 Aug 2022 20:02:57 -0300 From: "Dr. Rolf Jansen" <freebsd-rj@cyclaero.com> To: 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: <F210FBD2-52E1-4260-9398-C158B4E92F45@cyclaero.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
I just a BeagleBone Black which was in my drawer for more than a year or =
so. I partitioned the internal flash (here mmcsd1) manually some years =
ago. The u-boot stuff was still quite tiny at that time. Now look what I =
found:
=3D> 63 62410689 mmcsd0 MBR (30G)
63 25 - free - (13K)
88 102312 1 fat32lba [active] (50M)
102400 62308352 2 freebsd (30G)
=3D> 0 62308352 mmcsd0s2 BSD (30G)
0 56623104 1 freebsd-ufs (27G)
56623104 5685248 2 freebsd-swap (2.7G)
=3D> 63 7471041 mmcsd1 MBR (3.6G)
63 961 - free - (481K)
1024 15360 1 fat32lba [active] (7.5M)
16384 7454720 2 freebsd (3.6G)
=3D> 0 7454720 mmcsd1s2 BSD (3.6G)
0 7454720 1 freebsd-ufs (3.6G)
=3D> 0 7454720 ufsid/5c9c24b911822409 BSD (3.6G)
0 7454720 1 freebsd-ufs (3.6G)
=3D> 0 7454720 ufs/system BSD (3.6G)
0 7454720 1 freebsd-ufs (3.6G)
ls -l /dev/ufs
crw-r----- 1 root operator 0x6a Aug 10 17:52 system
crw-r----- 1 root operator 0x56 Aug 10 17:52 SYSTEM
crw-r----- 1 root operator 0x6d Aug 10 17:52 systema
The BBB has been booted from a new SD card with FreeBSD 13.1-RELEASE on =
/dev/ufs/SYSTEM, and /dev/ufs/SYSTEMa does not exist here. While I see =
/dev/ufs/system and /dev/ufs/systema for the some years old freebsd-ufs =
slice on the internal flash.
The BBB starts without problems from the internal flash once I remove =
the SD card.
I just partitioned another SD card without the swap partition, and after =
applying newfs -njU -L rootfs dev/da0s2a, I see /dev/ufs/rootfs and =
/dev/ufs/rootfsa. Both can be mounted and work without problems.
I tend to believe now, that we don=E2=80=99t see a bug when rootfsa =
besides rootfs appears, but a mostly unknown feature. If this disturbs =
somehow, growfs could perhaps be enhanced to either leave some space at =
the end of slice 2 or optionally add a swap-partition of size X. Both =
measures would effectively prevent the additional label rootfsa.
> Am 07.08.2022 um 16:32 schrieb Glen Barber <gjb@freebsd.org>:
>=20
> 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.
>=20
> 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
>>=20
>=20
>=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F210FBD2-52E1-4260-9398-C158B4E92F45>