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

> Am 11.08.2022 um 00:22 schrieb Mark Millard <marklmi@yahoo.com>:
> 
> On 2022-Aug-10, at 16:01, Dr. Rolf Jansen <rj@cyclaero.com> wrote:
> 
>> 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,
> 
> If I gather right, this is some sort of personal setup of
> FreeBSD 13.1-RELEASE . For example, release/tools/arm.subr
> uses:
> 
> chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
> 
> No attempt to create a ufs/SYSTEM label that I see.
> 
> (The gpart output above does not show ufs/SYSTEM at all.)
> 
> As stands, I can not compare/contrast the command sequences
> used vs. the results across the examples.

I don’t use system scripts for partitioning, formatting, labelling installation

1. Partitioning using gpart, here a SD card via an external USB reader on da0:

gpart destroy -F da0
gpart create -s MBR da0
gpart add -b 88 -s 102312 -t fat32lba da0
gpart add -t freebsd da0
gpart create -s BSD da0s2
gpart add -s 56623104 -t freebsd-ufs da0s2
gpart add -t freebsd-swap da0s2

Note, the size of the FAT32 boot partition has been chosen to match exactly what’s on the distribution images. Then the base of 88 is mandatory so the BSD payload partition may start on a perfectly aligned boundary of 102400·512kByte = 102400·512 = 52428800 byte. Perfectly, because this base is 4k-, 8k-, 16k-, 32k-, 64k-, 128k-, 256k-, 512k-, 1M-, 2M-aligned. It only stops being perfect, in case somebody needs 4M-alignment.

2. Formatting and labelling

newfs -njU -L SYSTEM /dev/da0s2a
glabel label -v SWAP /dev/da0s2b

3. Installation - here from the ARMv7 SD card image, but it does work almost the same for any of the other ARM images as well:
mdconfig -a -u 0 -t vnode -f FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220805-e24c5c60d72-257129.img

a) for the FAT32 boot partition, dd does the installation and labeling in one breath:
dd if=/dev/md0s1 of=/dev/da0s1 bs=512k

b) File system cloning from the SD card image to the freebsd-ufs volume using my tool sysutils/clone (s. also https://github.com/cyclaero/clone:

mount -o noatime /dev/md0s2a /media
mount -o noatime /dev/da0s2a /mnt
clone -x .sujournal /media /mnt

c) edit /mnt/etc/fstab:

/dev/ufs/SYSTEM		/		ufs	rw,noatime		0	1
/dev/label/SWAP		none		swap	sw			0	0
/dev/msdosfs/MSDOSBOOT	/boot/msdos	msdosfs	rw,noatime		0	0
tmpfs			/tmp		tmpfs	rw,mode=1777,size=50m	0	0

d) disable growfs in /etc/rc.conf

This looks a little bit more involved than just calling a script. After all it takes a few minutes more than by a script, and in case something goes wrong, then I know whom to blame, namely me :-)

The benefit is, that I end up with a journaled FS and a swap partition.

>> 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 internal flash is too tiny for adding a swap volume, so the whole BSD slice was used for the UFS volume. And actually this difference gave rise to - hmm..., wait a moment.

>> 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.
> 
> Interesting that the swap partition vs. not makes such a difference
> in what labels show up, referencing where. Being strictly after the
> freebsd-ufs area (if  your example gpart output above applies), that
> complicates interpreting things. Just start-offset-in-BSD aliasing
> is not going to be an explanation for that, for sure.

Exactly, and in a previous message you stated already:

>> Am 09.08.2022 um 15:55 schrieb Mark Millard <marklmi@yahoo.com>:
>> 
>> I really doubt that using kern.geom.part.mbr.enforce_chs=1 to
>> cause the offsets to be different is reasonable, despite that
>> it happens to make them distinct: the freebsd-ufs offset is
>> better controlled explicitly elsewhere.


My finding support your view. Only it seems now, that we may choose on how to make the volume distinct from the slice, namely both or either of offset and size.  

> FYI:
> I booted the original test snapshot. But after its initial activity,
> the following reboot attempts could not complete. I sent a messy
> series of list messages from exploring/learning for this, including
> a sequence of adjustments that eventually got things to back to
> booting.
> 
>> I tend to believe now, that we don’t see a bug when rootfsa besides rootfs appears, but a mostly unknown feature.
> 
> My test case got boot failures --after the initial boot appeared
> to work and basically operate. No later boot attempt completed
> until I'd made adjustments. Testing of my "move the freebsd-ufs
> offset to be distinct" hypothesis is expected to be set up in
> this week's snapshot builds. But it may well end up not be any
> sort of final test fixing all the issues --or even identifying
> them all. Time will tell.

Well, I can only tell that my systems boot fine, either with or without the second ufs/<label>a. For example I can mount the UFS volume on the internal flash of the BBB by either label:

mount -o noatime /dev/ufs/system /mnt
unmount /mnt
mount -o noatime /dev/ufs/systema /mnt

Both commands result in mounting the very UFS system volume on mount point /mnt. No visible differences. Up to now, I never paid attention to this, and in /etc/fstab on the internal flash, only /dev/ufs/system is referenced, I never imagined that there could be the label „systema".

>> 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.
> 
> There is the possibility that the week's snapshot test will
> end up having ufs/rootfs referencing *s2a like it should
> but that there are still problems observed. That is one of
> the reasons for doing the test: trying to isolate separate
> problems if things still are not working well overall after
> the change.