Date: Sun, 17 Jul 2022 11:46:08 -0700 From: Mark Millard <marklmi@yahoo.com> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> Cc: Glen Barber <gjb@FreeBSD.org>, Warner Losh <imp@bsdimp.com>, "dev-commits-src-main@freebsd.org" <dev-commits-src-main@FreeBSD.org>, "Dr. Rolf Jansen" <freebsd-rj@cyclaero.com>, freebsd-arm <freebsd-arm@FreeBSD.org> Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv [odd alignment for SBC images] Message-ID: <E7C1D0E7-6B6E-4C67-B6A1-000A22933A1E@yahoo.com> In-Reply-To: <202207171708.26HH81bA062303@gndrsh.dnsmgr.net> References: <202207171708.26HH81bA062303@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Jul-17, at 10:08, Rodney W. Grimes = <freebsd-rwg@gndrsh.dnsmgr.net> wrote: >> On 2022-Jul-16, at 23:24, Mark Millard <marklmi@yahoo.com> wrote: >>=20 >>> On 2022-Jul-15, at 17:41, Mark Millard <marklmi@yahoo.com> wrote: >>>=20 >>>> FYI for the new snapshot build of 13.1-STABLE: >>>>=20 >>>> # mdconfig -u0 -f = FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220715-831c6b8edda-251792.img=20 >>>> # gpart show md0 >>>> =3D> 63 10485697 md0 MBR (5.0G) >>>> 63 2016 - free - (1.0M) >>>> 2079 102312 1 fat32lba [active] (50M) >>>> 104391 10381329 2 freebsd (5.0G) >>>> 10485720 40 - free - (20K) >>>>=20 >>>> So: still has the 2016 and 2079 that do not seem to match >>>> what /usr/src/release/ materials would indicate --and the >>>> 2079 leads to poor alignment for a microsd cards, for >>>> example. >>>>=20 >>>> But, at least something was produced this time. There is >>>> now a 13.1-STABLE snapshot to test the handling related >>>> to the new UFS/FFS superblock validations. >>>=20 >>> In the live build environment that makes the images, >>> what is: >>>=20 >>> # sysctl kern.geom.part.mbr.enforce_chs >>> kern.geom.part.mbr.enforce_chs: 0 >>>=20 >>> I ask because of the description: >>>=20 >>> QUOTE >>> kern.geom.part.mbr.enforce_chs: 0 >>> Specify how the Master Boot Record (MBR) module does = alignment. >>> If this variable is set to a non-zero value, the module = will >>> automatically recalculate the user-specified offset and = size for >>> alignment with the CHS geometry. Otherwise the values = will be >>> left unchanged. >>> END QUOTE >>>=20 >>> In particular, the text about non-zero values leading to: >>>=20 >>> QUOTE >>> the module will >>> automatically recalculate the user-specified offset and = size for >>> alignment with the CHS geometry >>> END QUOTE >>>=20 >>> This sounds like a potential way to not end up with the >>> what the /usr/src/release handling requests for the >>> small board computer images. It might explain the >>> mismatched alignment that I've been reporting. >>=20 >> I tried it locally and it reproduced the problem alignment: >>=20 >> # sysctl kern.geom.part.mbr.enforce_chs=3D1 >> kern.geom.part.mbr.enforce_chs: 0 -> 1 >> # truncate -s3072m mmjnk.test >> # mdconfig -u0 -fmmjnk.test -x63 -y255 >> # gpart create -sMBR md0 >> md0 created >> # gpart show md0 >> =3D> 63 6291393 md0 MBR (3.0G) >> 63 6291393 - free - (3.0G) >>=20 >> ... # gpart add -t'!12' -a512k -s50m -b1m md0 >> md0s1 added >> ... # gpart show md0 [I normally strip out long shell prompts but missed the 2 that had been above.] >> =3D> 63 6291393 md0 MBR (3.0G) >> 63 2016 - free - (1.0M) >> 2079 102312 1 fat32lba (50M) >> 104391 6187065 - free - (3.0G) >>=20 >> Note the 2016 and 2079 (instead of 1985 and 2048). I'll note that I've no clue if the 2016 and 2079 results for kern.geom.part.mbr.enforce_chs=3D1 are correct/appropriate vs. not for the context. "-x63 -y255" was listed in the mdconfig command. I'm just reporting what results and that it matches the odd SBC image alignments in snapshot and release images. There could be more to it. >> Reminder of the old result, reported before, that >> implicitly had: >>=20 >> # sysctl kern.geom.part.mbr.enforce_chs >> kern.geom.part.mbr.enforce_chs: 0 >>=20 >> as its context: >>=20 >> QUOTE >> # truncate -s3072m mmjnk.test >> # mdconfig -u0 -fmmjnk.test -x63 -y255 >> # gpart create -sMBR md0 >> md0 created >> # gpart show md0 >> =3D> 63 6291393 md0 MBR (3.0G) >> 63 6291393 - free - (3.0G) >> # gpart add -t'!12' -a512k -s50m -b1m md0 >> md0s1 added >> # gpart show md0 >> =3D> 63 6291393 md0 MBR (3.0G) >> 63 1985 - free - (993K) >> 2048 102400 1 fat32lba (50M) >> 104448 6187008 - free - (3.0G) >> END QUOTE >>=20 >> Looks to me like the environment that uses >> /usr/src/release to produce Small Board Computer >> images has: >>=20 >> # sysctl kern.geom.part.mbr.enforce_chs >> kern.geom.part.mbr.enforce_chs: 1 >>=20 >> and this is leading to the misalignments for the MBR images. >=20 > Very nice digging Mark, > Perhaps an assert for kern.geom.part.mbr.enforce_chs not > being zero in /usr/src/release scripts is in order so that > the builds blow up rather than produce BAD images. Just > becuase this gets fixed on the projects systems does not > mean some user running release builds can not stumble into > it. Please Please Please!!!! >=20 > Again, thanks for digging down to atleast this one > potential cause! >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E7C1D0E7-6B6E-4C67-B6A1-000A22933A1E>