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

On 2022-Aug-9, at 11:55, Mark Millard <marklmi@yahoo.com> wrote:

> On 2022-Aug-9, at 11:15, Glen Barber <gjb@FreeBSD.org> wrote:
> 
>> On Tue, Aug 09, 2022 at 02:06:14PM -0400, Ed Maste wrote:
>>> On Sun, 7 Aug 2022 at 18:43, Glen Barber <gjb@freebsd.org> wrote:
>>>> 
>>>> Will do.  I’ll commit the suggested change to main tomorrow.
>>>> 
>>>> Thank you for your vigilant investigation.
>>> 
>>> Shall I commit the enforce_chs check now?
>>> ---
>>> commit 6ee7d69e6b526f35789b23ba570025f1c3b39c1a
>>> Author: Ed Maste <emaste@FreeBSD.org>
>>> Date:   Tue Jul 19 16:47:49 2022 -0400
>>> 
>>>   release: ensure enforce_chs sysctl is 0
>>> 
>>>   We do not want CHS-based alignment for VM or SD card release images.
>>> 
>>>   Sponsored by:   The FreeBSD Foundation
>>> 
>>> diff --git a/release/tools/arm.subr b/release/tools/arm.subr
>>> index 6e4ae731a0b9..01c5303cd4e1 100644
>>> --- a/release/tools/arm.subr
>>> +++ b/release/tools/arm.subr
>>> @@ -62,6 +62,10 @@ umount_loop() {
>>> }
>>> 
>>> arm_create_disk() {
>>> +       if [ $(sysctl -n kern.geom.part.mbr.enforce_chs) != 0 ]; then
>>> +               return 1
>>> +       fi
>>> +
>>>       # Create the target raw file and temporary work directory.
>>>       chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev}
>>>       if [ "${PART_SCHEME}" = "GPT" ]; then
>>> 
>> 
>> Good question.  Do we still want to ensure it is set to '0'?  I'm a bit
>> confused from the back-and-forth on the original thread.
>> 
>> If we do want to ensure it is set to '0', yes, please go ahead.
>> 
> 
> Hopefully this week's experiment with explicitly avoiding BSD
> and freebsd-ufs having the same offset inside BSD (avoiding
> both offsets being zero) will allow the UFS labeling to work
> right: freebsd-ufs being tied to a unique offset inside BSD.
> 
> 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.
> 

The experiment with this week's snapshot is working just fine.
It is based on the update:

QUOTE
The branch main has been updated by gjb:

URL: https://cgit.FreeBSD.org/src/commit/?id=45add40717c24ef0b5418664fae1718b15a0422b

commit 45add40717c24ef0b5418664fae1718b15a0422b
Author:     Glen Barber <gjb@FreeBSD.org>
AuthorDate: 2022-08-08 14:59:29 +0000
Commit:     Glen Barber <gjb@FreeBSD.org>
CommitDate: 2022-08-08 14:59:29 +0000

    release: fix alignment for arm SoCs
    
    MFC after:      3 days
    Submitted by:   Mark Millard
    Sponsored by:   Rubicon Communications, LLC ("Netgate")
---
 release/tools/arm.subr | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/release/tools/arm.subr b/release/tools/arm.subr
index 3dea17339958..25d4640cc26b 100644
--- a/release/tools/arm.subr
+++ b/release/tools/arm.subr
@@ -77,7 +77,7 @@ arm_create_disk() {
 		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} gpart add -t freebsd-ufs -a 64k -b 64k ${mddev}s2
 		chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
 	fi
END QUOTE

This is unlike when the "-b 64k" was not present. This
includes rebooting after the initial boot, unlike before.
This is for dd'ing to USB3 NVMe SSD media and testing,
for both of:

FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220812-6a70a0c8bfa-257314.img
FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220812-eb2a9b78586-252107.img

(The -b use implicitly also changed the size of the freebsd-ufs
slice, making it smaller.) For the media growfs is involved in
the initial boot.

glabel list now shows ufs/rootfs bound to da0s2a and does not
show a ufs/rootfsa at all. There is no binding to da0s2 (BSD)
shown.

# glabel list
Geom name: da0s1
Providers:
1. Name: msdosfs/MSDOSBOOT
   Mediasize: 52428800 (50M)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 1048576
   Mode: r1w1e1
   secoffset: 0
   offset: 0
   seclength: 102400
   length: 52428800
   index: 0
Consumers:
1. Name: da0s1
   Mediasize: 52428800 (50M)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 1048576
   Mode: r1w1e2

Geom name: da0s2a
Providers:
1. Name: ufs/rootfs
   Mediasize: 240003866624 (224G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 53542912
   Mode: r1w1e1
   secoffset: 0
   offset: 0
   seclength: 468757552
   length: 240003866624
   index: 0
Consumers:
1. Name: da0s2a
   Mediasize: 240003866624 (224G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 53542912
   Mode: r1w1e2

# gpart show -p
=>       63  468862065    da0  MBR  (224G)
         63       1985         - free -  (993K)
       2048     102400  da0s1  fat32lba  [active]  (50M)
     104448  468757680  da0s2  freebsd  (224G)

=>        0  468757680   da0s2  BSD  (224G)
          0        128          - free -  (64K)
        128  468757552  da0s2a  freebsd-ufs  (224G)

A difference in behavior is that "gpart show" does not
report the ufs/rootfs labeling. For all I know, this
could be expected. glabel does show ufs/rootfs .

I do not know what would happen if only the size had
been made smaller but the starting offset had been left
at 0.

But the evidence from the "without -b" and "with -b"
testing is that having starting offset 0 in BSD
and the same size as BSD can be a problem for the
freebsd-ufs slice as processed by the initial boot,
at least when ufs labeling is in use (here ufs/rootfs).

So far, this week's snapshots look good to me for the
issue having been avoided but ending up better aligned
overall than when kern.geom.part.mbr.enforce_chs=1 was
in use.

If a larger alignment is needed at some point for
freebsd-ufs, adjusting the pair of gpart add arguments
"-a 64k -b 64k" should deal with it.


Notes:

The USB3 NNVMe SSD based testing was with a 8GiByte
RPi4B and so does have the addition of:

#
# Local addition that avoids USB3 SSD boot failures that look like: 
#   uhub_reattach_port: port ? reset failed, error=USB_ERR_TIMEOUT 
#   uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port ? 
initial_turbo=60 

in the config.txt file that the RPi* firmware uses.
(It is for a separate issue --and FreeBSD does not
have such in place by default at this time.)

===
Mark Millard
marklmi at yahoo.com