Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv
- In reply to: Glen Barber : "Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 19 Jul 2022 15:16:54 UTC
On 2022-Jul-19, at 08:00, Glen Barber <gjb@freebsd.org> wrote: > 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? > In the "Partition layout of ARM SD card images" exchanges Warner wrote (to limit the quoting): QUOTE Yes, we should be aligning at a 1M or 2M boundary on the root device, not within the partition. The offsets are supposed to do that, and if there's a problem we should fix it. . . . 63 sector for 'fake' C/H/S has been a thing since at least FreeBSD 6 and maybe a little longer. There's no cutover based on image size of the device. The older ATA code, pre-cam but post SOS rewrite, would try very hard to return the values from the underlying device that it reported. And that would lead to mismatches because it was different than the lies that md told by default. But that only mattered for really old BIOSes that couldn't handle LBA/packet mode in booting (which is the primary reason the old fdisk program could set the ending CHS of partitions since the FreeBSD code used that to guess the CHS of the drive itself in the absence of other information). I don't think the kernel has changed in this area in a very long time. At worse, we're seeing a mkimage bug. END QUOTE I take this as Warner saying what happens now is not appropriate for the SBC images. But he did not write about the label placement problem that lead to use of kern.geom.part.mbr.enforce_chs=1 . How do we test for if the old problem is still around when kern.geom.part.mbr.enforce_chs=0 is in use? As for me, I do not even know if the gpart results that are happening for kern.geom.part.mbr.enforce_chs=1 are correct/expected vs. not, given the mdconfig commands used. So I'm only guessing that using kern.geom.part.mbr.enforce_chs=0 is now appropriate. That would seem to be a separate issue from if the gpart behavior for kern.geom.part.mbr.enforce_chs=1 is correct/expected vs. not for the SBC images, given the mdconfig commands used. === Mark Millard marklmi at yahoo.com