Date: Mon, 18 Jul 2022 17:45:26 -0700 From: Mark Millard <marklmi@yahoo.com> To: Glen Barber <gjb@FreeBSD.org> Cc: dev-commits-src-main@freebsd.org, Warner Losh <imp@bsdimp.com> Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv Message-ID: <5450B332-66B8-4134-81E7-ECF654791C97@yahoo.com> In-Reply-To: <20220718145230.GB95937@FreeBSD.org> References: <7F4F9683-B4DE-4F65-BBD7-027039A0C270@yahoo.com> <20220713204227.GA30607@FreeBSD.org> <8A02A4A4-9F3A-47F2-9985-EA2151043BB7@yahoo.com> <4D903E5A-58FB-4516-AC53-AEDFF48564A7@yahoo.com> <20220714152125.GB30607@FreeBSD.org> <3E2DCFBD-CC8F-4C13-B18C-B7DA26ED8E84@yahoo.com> <AE47C47B-33F7-4236-8A23-688C40340EA7@yahoo.com> <DBED097F-00BD-467C-8CA3-49857DA35456@yahoo.com> <20220718140851.GA95937@FreeBSD.org> <037C78F9-CA37-4D1C-8F68-22A85183E8AF@yahoo.com> <20220718145230.GB95937@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>=20 >>> On Sat, Jul 16, 2022 at 11:24:47PM -0700, Mark Millard wrote: >>>>=20 >>>>=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 >>>=20 >>> 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. >>>=20 >>=20 >> 0 is the default that shows up on the systems >> that I have access to. >>=20 >> It has not been the default since 2014-08-12: >>=20 >=20 > 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. >=20 There is your: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227879 and its comment #5 and related material: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227879#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=3D226536 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:=20 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] =3D> 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=3D1 was a workaround. =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?5450B332-66B8-4134-81E7-ECF654791C97>