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

From: Mark Millard <marklmi_at_yahoo.com>
Date: Thu, 11 Aug 2022 03:22:43 UTC
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.

> 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.

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.

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.

> 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.

I did get an off-list E-mail asking about the issue and why
I had my hypothesis. My hope is that the person ends up
being someone else looking into the problem(s). They likely
would have significant relevant background knowledge.

===
Mark Millard
marklmi at yahoo.com