Date: Sun, 17 Jul 2022 10:08:01 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: Mark Millard <marklmi@yahoo.com> Cc: Glen Barber <gjb@FreeBSD.org>, Warner Losh <imp@bsdimp.com>, dev-commits-src-main@FreeBSD.org, "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, "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: <202207171708.26HH81bA062303@gndrsh.dnsmgr.net> In-Reply-To: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 2022-Jul-16, at 23:24, Mark Millard <marklmi@yahoo.com> wrote: > > > On 2022-Jul-15, at 17:41, Mark Millard <marklmi@yahoo.com> wrote: > > > >> FYI for the new snapshot build of 13.1-STABLE: > >> > >> # mdconfig -u0 -f FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220715-831c6b8edda-251792.img > >> # gpart show md0 > >> => 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) > >> > >> 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. > >> > >> 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. > > > > In the live build environment that makes the images, > > what is: > > > > # sysctl kern.geom.part.mbr.enforce_chs > > kern.geom.part.mbr.enforce_chs: 0 > > > > I ask because of the description: > > > > 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 > > > > In particular, the text about non-zero values leading to: > > > > QUOTE > > the module will > > automatically recalculate the user-specified offset and size for > > alignment with the CHS geometry > > END QUOTE > > > > 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. > > I tried it locally and it reproduced the problem alignment: > > # sysctl kern.geom.part.mbr.enforce_chs=1 > 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 > => 63 6291393 md0 MBR (3.0G) > 63 6291393 - free - (3.0G) > > CA72_16Gp_ZFS aarch64 1400063 1400063 # gpart add -t'!12' -a512k -s50m -b1m md0 > md0s1 added > CA72_16Gp_ZFS aarch64 1400063 1400063 # gpart show md0 > => 63 6291393 md0 MBR (3.0G) > 63 2016 - free - (1.0M) > 2079 102312 1 fat32lba (50M) > 104391 6187065 - free - (3.0G) > > Note the 2016 and 2079 (instead of 1985 and 2048). > > Reminder of the old result, reported before, that > implicitly had: > > # sysctl kern.geom.part.mbr.enforce_chs > kern.geom.part.mbr.enforce_chs: 0 > > as its context: > > QUOTE > # truncate -s3072m mmjnk.test > # mdconfig -u0 -fmmjnk.test -x63 -y255 > # gpart create -sMBR md0 > md0 created > # gpart show md0 > => 63 6291393 md0 MBR (3.0G) > 63 6291393 - free - (3.0G) > # gpart add -t'!12' -a512k -s50m -b1m md0 > md0s1 added > # gpart show md0 > => 63 6291393 md0 MBR (3.0G) > 63 1985 - free - (993K) > 2048 102400 1 fat32lba (50M) > 104448 6187008 - free - (3.0G) > END QUOTE > > Looks to me like the environment that uses > /usr/src/release to produce Small Board Computer > images has: > > # sysctl kern.geom.part.mbr.enforce_chs > kern.geom.part.mbr.enforce_chs: 1 > > and this is leading to the misalignments for the MBR images. 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!!!! Again, thanks for digging down to atleast this one potential cause! > > > === > Mark Millard > marklmi at yahoo.com > > > > -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202207171708.26HH81bA062303>