Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv [odd alignment for SBC images]

On 2022-Jul-16, at 23:24, Mark Millard <[email protected]> wrote:

> On 2022-Jul-15, at 17:41, Mark Millard <[email protected]> wrote:
> 
>> FYI for the new snapshot build of 13.1-STABLE:
>> 
>> # mdconfig -u0 -f FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220715-831c6b8edda-251792.img 
>> # gpart show md0
>> =>      63  10485697  md0  MBR  (5.0G)
>>       63      2016       - free -  (1.0M)
>>     2079    102312    1  fat32lba  [active]  (50M)
>>   104391  10381329    2  freebsd  (5.0G)
>> 10485720        40       - free -  (20K)
>> 
>> So: still has the 2016 and 2079 that do not seem to match
>> what /usr/src/release/ materials would indicate --and the
>> 2079 leads to poor alignment for a microsd cards, for
>> example.
>> 
>> But, at least something was produced this time. There is
>> now a 13.1-STABLE snapshot to test the handling related
>> to the new UFS/FFS superblock validations.
> 
> In the live build environment that makes the images,
> what is:
> 
> # sysctl kern.geom.part.mbr.enforce_chs
> kern.geom.part.mbr.enforce_chs: 0
> 
> I ask because of the description:
> 
> QUOTE
>     kern.geom.part.mbr.enforce_chs: 0
>             Specify how the Master Boot Record (MBR) module does alignment.
>             If this variable is set to a non-zero value, the module will
>             automatically recalculate the user-specified offset and size for
>             alignment with the CHS geometry.  Otherwise the values will be
>             left unchanged.
> END QUOTE
> 
> In particular, the text about non-zero values leading to:
> 
> QUOTE
> the module will
>             automatically recalculate the user-specified offset and size for
>             alignment with the CHS geometry
> END QUOTE
> 
> This sounds like a potential way to not end up with the
> what the /usr/src/release handling requests for the
> small board computer images. It might explain the
> mismatched alignment that I've been reporting.

I tried it locally and it reproduced the problem alignment:

# sysctl kern.geom.part.mbr.enforce_chs=1
kern.geom.part.mbr.enforce_chs: 0 -> 1
# truncate -s3072m mmjnk.test
# mdconfig -u0 -fmmjnk.test -x63 -y255
# gpart create -sMBR md0
md0 created
# gpart show md0
=>     63  6291393  md0  MBR  (3.0G)
       63  6291393       - free -  (3.0G)

CA72_16Gp_ZFS aarch64  1400063 1400063 # gpart add -t'!12' -a512k -s50m -b1m md0
md0s1 added
CA72_16Gp_ZFS aarch64  1400063 1400063 # gpart show md0
=>     63  6291393  md0  MBR  (3.0G)
       63     2016       - free -  (1.0M)
     2079   102312    1  fat32lba  (50M)
   104391  6187065       - free -  (3.0G)

Note the 2016 and 2079 (instead of 1985 and 2048).

Reminder of the old result, reported before, that
implicitly had:

# sysctl kern.geom.part.mbr.enforce_chs
kern.geom.part.mbr.enforce_chs: 0

as its context:

QUOTE
# truncate -s3072m mmjnk.test
# mdconfig -u0 -fmmjnk.test -x63 -y255
# gpart create -sMBR md0
md0 created
# gpart show md0
=>     63  6291393  md0  MBR  (3.0G)
     63  6291393       - free -  (3.0G)
# gpart add -t'!12' -a512k -s50m -b1m md0
md0s1 added
# gpart show md0
=>     63  6291393  md0  MBR  (3.0G)
     63     1985       - free -  (993K)
   2048   102400    1  fat32lba  (50M)
 104448  6187008       - free -  (3.0G)
END QUOTE

Looks to me like the environment that uses
/usr/src/release to produce Small Board Computer
images has:

# sysctl kern.geom.part.mbr.enforce_chs
kern.geom.part.mbr.enforce_chs: 1

and this is leading to the misalignments for the MBR images.


===
Mark Millard
marklmi at yahoo.com