Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use
Mark Millard <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.hackers,gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
> On 2022-Aug-7, at 14:51, Dr. Rolf Jansen <[email protected]> wrote: > >> Am 07.08.2022 um 16:50 schrieb Mark Millard <[email protected]>: >> >> On 2022-Aug-7, at 12:32, Glen Barber <[email protected]> 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. === Mark Millard marklmi at yahoo.com