Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use
- Reply: Mark Millard : "Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use"
- In reply to: Mark Millard : "Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 07 Aug 2022 21:51:02 UTC
> 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. 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. Best regards Rolf