Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use

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 <[email protected]>:
> 
> 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 <[email protected]> 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
>> 
> 
>