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-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.
> 
>> On Aug 7, 2022, at 12:10 AM, Mark Millard <marklmi@yahoo.com> wrote:
>> 
>> The oddities look like indicated below.
>> 
>> # mdconfig -u md1 -f FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220805-e24c5c60d72-257129.img
>> # gpart show
>> . . .
>> 
>> =>      63  10485697  md1  MBR  (5.0G)
>>       63      1985       - free -  (993K)
>>     2048    102400    1  fat32lba  [active]  (50M)
>>   104448  10381312    2  freebsd  (5.0G)
>> 
>> =>       0  10381312  md1s2  BSD  (5.0G)
>>        0  10381312      1  freebsd-ufs  (5.0G)
>> 
>> =>       0  10381312  ufsid/62ed01f3345560d8  BSD  (5.0G)
>>        0  10381312                       1  freebsd-ufs  (5.0G)
>> 
>> =>       0  10381312  ufs/rootfs  BSD  (5.0G)
>>        0  10381312           1  freebsd-ufs  (5.0G)
>> 
>> So: ufs/rootfs apparently identifies the BSD instead of the
>> freebsd-ufs . Same for the ufsid/* . This leads to:
>> 
>> # gpart show -p 
>> . . .
>> 
>> =>      63  10485697    md1  MBR  (5.0G)
>>       63      1985         - free -  (993K)
>>     2048    102400  md1s1  fat32lba  [active]  (50M)
>>   104448  10381312  md1s2  freebsd  (5.0G)
>> 
>> =>       0  10381312   md1s2  BSD  (5.0G)
>>        0  10381312  md1s2a  freebsd-ufs  (5.0G)
>> 
>> =>       0  10381312   ufsid/62ed01f3345560d8  BSD  (5.0G)
>>        0  10381312  ufsid/62ed01f3345560d8a  freebsd-ufs  (5.0G)
>> 
>> =>       0  10381312   ufs/rootfs  BSD  (5.0G)
>>        0  10381312  ufs/rootfsa  freebsd-ufs  (5.0G)
>> 
>> freebsd-ufs has the unexpected label: ufs/rootfsa
>> 
>> # ls -Tld /dev/ufs/*
>> crw-r-----  1 root  operator  0x6c Aug  6 20:19:58 2022 /dev/ufs/rootfs
>> crw-r-----  1 root  operator  0x6e Aug  6 20:19:58 2022 /dev/ufs/rootfsa
>> 
>> Things were actually set up for ufs/rootfs naming as the
>> identification of the freebsd-ufs content, per the
>> release/tools/arm.subr commands ( from last month's
>> main-n256584-5bc926af9fd1 ):
>> 
>>       if [ "${PART_SCHEME}" = "MBR" ]; then
>>               chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s ${FAT_SIZE} ${mddev}
>>               chroot ${CHROOTDIR} gpart set -a active -i 1 ${mddev}
>>               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} newfs -U -L rootfs /dev/${mddev}s2a
>>       fi
>> 
>> Note that the newfs command references /dev/${mddev}s2a instead
>> of /dev/${mddev}s2 but the rootfs label ends up referencing
>> /dev/${mddev}s2 .
>> 
>> Is having "0 10381312" for the md*s2 and for the md*s2a a
>> fundamental problem? Does freebsd-ufs ( a.k.a. md*s2a ) need
>> to be moved to a different (non-zero) offset inside BSD?
>> 
>> Or is this a different kind of bug?
>> 
>> I'll not repeat the kinds of explorations that I reported last
>> week unless someone wants to request something.
> 


===
Mark Millard
marklmi at yahoo.com