Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv
Date: Tue, 19 Jul 2022 15:00:48 UTC
Added emaste@ to CC, as he seemed to have been involved in this. (I meant to CC him on this reply in the first place, but did not.) On Tue, Jul 19, 2022 at 02:58:41PM +0000, Glen Barber wrote: > On Mon, Jul 18, 2022 at 05:45:26PM -0700, Mark Millard wrote: > > On 2022-Jul-18, at 07:52, Glen Barber <gjb@FreeBSD.org> wrote: > > > > > On Mon, Jul 18, 2022 at 07:34:40AM -0700, Mark Millard wrote: > > >> On 2022-Jul-18, at 07:08, Glen Barber <gjb@freebsd.org> wrote: > > >> > > >>> On Sat, Jul 16, 2022 at 11:24:47PM -0700, Mark Millard 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. > > >>>> > > >>> > > >>> It is set to '1' on all three systems. If this is causing a problem, it > > >>> is weird we have a problematic setting as the default. > > >>> > > >> > > >> 0 is the default that shows up on the systems > > >> that I have access to. > > >> > > >> It has not been the default since 2014-08-12: > > >> > > > > > > Oh, the builders have it set in /etc/sysctl.conf, and if I recall > > > correctly, it was in order to address another problem. I'm digging > > > through my email archives to find out what the other problem was > > > exactly, but my memory is a bit fuzzy on the details. > > > > > > > There is your: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227879 > > > > and its comment #5 and related material: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227879#c5 > > > > Appearently the issues noted are part of what lead to the > > SBC's use lodaer.efi as bootaa64.efi instead of using > > boot1.efi . > > > > > > There is also the older: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226536 > > > > where kern.geom.part.mbr.enforce_chs assignment on > > builders is referenced in a commit notice, comment #29: > > > > QUOTE > > A commit references this bug: > > > > Author: gjb > > Date: Wed Apr 18 16:22:23 UTC 2018 > > New revision: 332731 > > URL: > > https://svnweb.freebsd.org/changeset/base/332731 > > > > > > Log: > > MFC r326278 (manu): > > > > growfs: Commit the changes after expanding the partition > > > > This fix the problem in arm snapshot present since at least 6 months > > where growfs was failing at firstboot and dropped you in a single > > user shell. > > > > Note: In addition to this merge, kern.geom.part.mbr.enforce_chs has > > been enabled on the build machine to mitigate against the issue in > > the PR referenced. > > > > PR: 226536 > > Sponsored by: The FreeBSD Foundation > > > > Changes: > > _U stable/10/ > > stable/10/etc/rc.d/growfs > > _U stable/11/ > > stable/11/etc/rc.d/growfs > > END QUOTE > > > > But Ed Maste's comment #31 indicated a direction of switching to > > use of -b to configure partition layout. (Modern /usr/src/release > > materials for SBC image production did so as I remember.) > > > > > > The original description from back then shows a > > very different 961 and 1024: > > > > QUOTE > > % gpart show > > > > [snip] > > > > => 63 6291393 md0 MBR (3.0G) > > 63 961 - free - (481K) > > 1024 34816 1 !12 [active] (17M) > > 35840 6255616 2 freebsd (3.0G) > > END QUOTE > > > > But somehow label placement was identifying mmcsd0s2 instead > > of mmnsd0s2a that that was the "the issue in the PR referenced" > > for which kern.geom.part.mbr.enforce_chs=1 was a workaround. > > > > Thank you very much for drilling down into this. So.... straw-man > question: do we indeed have a problem here, or did we fix a bug with > another bug? Glen