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

> Am 07.08.2022 um 19:51 schrieb Dr. Rolf Jansen <freebsd-rj@cyclaero.com>:
> 
>> Am 07.08.2022 um 19:16 schrieb Mark Millard <marklmi@yahoo.com>:
>> 
>>> On 2022-Aug-7, at 14:51, Dr. Rolf Jansen <freebsd-rj@cyclaero.com> wrote:
>>> 
>>>> Am 07.08.2022 um 16:50 schrieb Mark Millard <marklmi@yahoo.com>:
>>>> 
>>>> On 2022-Aug-7, at 12:32, Glen Barber <gjb@freebsd.org> wrote:
>>>> 
>>>>> 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.
>>>> 
>>>> My guess is that if the release/tools/arm.subr line:
>>>> 
>>>>           chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k ${mddev}s2
>>>> 
>>>> was instead (note the added -b use):
>>>> 
>>>>           chroot ${CHROOTDIR} gpart add -t freebsd-ufs -b 64k -a 64k ${mddev}s2
>>>> 
>>>> then the line:
>>>> 
>>>>           chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
>>>> 
>>>> would work as expected and things would still be aligned:
>>>> no aliasing of BSD vs. freebsd-ufs. (In part this is by
>>>> prior steps already having achieved alignment of BSD.)
>>> 
>>> From a strict mathematical stand point of view, -a is not necessary when using -b with an aligned value.
>> 
>> "-a" controls more than the start offset: also the size.
>> 
>> QUOTE
>>              -a alignment  If specified, then the gpart utility tries to
>>                            align start offset and partition size to be
>>                            multiple of alignment value.
>> END QUOTE
>> 
>> I expect your statement would at most apply to the start offset, not to
>> everything "-a" does.
>> 
>>> Personally I don’t use the -a option of gpart anymore since it started to do funny magics in front of face. If I remember correct, gpart of the FreeBSD 9.x-RELEASES was still OK (or was it 8?). Nowadays, I align all my storage media by employing -b with a reasonable value.
>>> 
>> 
>> I've no clue of the specifics that you are referencing and so can not check.
> 
> It started at unexpected offsets and then left unexpected space at the end - sorry, I don’t use -a anymore for years, and I don’t remember the very details. 
> 
> That said, why then would we use -b in addition to -a, if -a would show the expected behaviour on its own. That is because either -a adds some "funny magic" to the logic, that is stated in the man file, or there is a bug in gpart.
> 
> Anyway, using -a and -b together bears the danger of the equation being overestimated, namely in the case base is not a multiple (incl. 1) of alignment. Although, that is not the case with your suggestion. -b 64k -a 64k is OK.
> 
> Finally, I still wonder what might be the technical reason for aligning the size.

PS:

Now I am in nit picking mode - "... the gpart utility tries to ..."   

Don’t try it, do it! Otherwise, hasta la vista, baby!

Hlv,b is meant to the -a option, and not personally.