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

Will do.  I’ll commit the suggested change to main tomorrow.

Thank you for your vigilant investigation.

Glen
Sent from my phone.
Please excuse my brevity and/or typos.

> On Aug 7, 2022, at 3:50 PM, Mark Millard <marklmi@yahoo.com> wrote:
> 
> 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.)
> 
> But I do not know how to classify doing so: Work around?
> Known required-procedure for -L rootfs to correctly
> identify the the freebsd-ufs /dev/${mddev}s2a ?
> 
> Absent better information from folks that know more, I'd
> suggest trying such an adjusted release/tools/arm.subr
> next week, leaving kern.geom.part.mbr.enforce_chs=0 in
> place, if such an experiment can be reasonable.
> 
>> Glen
>> Sent from my phone.
>> Please excuse my brevity and/or typos.