Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use
Date: Wed, 10 Aug 2022 23:02:57 UTC
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: => 63 62410689 mmcsd0 MBR (30G) 63 25 - free - (13K) 88 102312 1 fat32lba [active] (50M) 102400 62308352 2 freebsd (30G) => 0 62308352 mmcsd0s2 BSD (30G) 0 56623104 1 freebsd-ufs (27G) 56623104 5685248 2 freebsd-swap (2.7G) => 63 7471041 mmcsd1 MBR (3.6G) 63 961 - free - (481K) 1024 15360 1 fat32lba [active] (7.5M) 16384 7454720 2 freebsd (3.6G) => 0 7454720 mmcsd1s2 BSD (3.6G) 0 7454720 1 freebsd-ufs (3.6G) => 0 7454720 ufsid/5c9c24b911822409 BSD (3.6G) 0 7454720 1 freebsd-ufs (3.6G) => 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’t 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>: > > 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 >> > >