Date: Tue, 19 Jul 2022 15:00:48 +0000 From: Glen Barber <gjb@freebsd.org> To: Mark Millard <marklmi@yahoo.com> Cc: dev-commits-src-main@freebsd.org, Warner Losh <imp@bsdimp.com>, Ed Maste <emaste@freebsd.org> Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv Message-ID: <20220719150048.GA39258@FreeBSD.org> In-Reply-To: <20220719145841.GI30607@FreeBSD.org> References: <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> <5450B332-66B8-4134-81E7-ECF654791C97@yahoo.com> <20220719145841.GI30607@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > >=20 > > > 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 al= ignment. > > >>>> 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 proble= m, 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 > >=20 > > There is your: > >=20 > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227879 > >=20 > > and its comment #5 and related material: > >=20 > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227879#c5 > >=20 > > Appearently the issues noted are part of what lead to the > > SBC's use lodaer.efi as bootaa64.efi instead of using > > boot1.efi . > >=20 > >=20 > > There is also the older: > >=20 > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D226536 > >=20 > > where kern.geom.part.mbr.enforce_chs assignment on > > builders is referenced in a commit notice, comment #29: > >=20 > > QUOTE > > A commit references this bug: > >=20 > > Author: gjb > > Date: Wed Apr 18 16:22:23 UTC 2018 > > New revision: 332731 > > URL:=20 > > https://svnweb.freebsd.org/changeset/base/332731 > >=20 > >=20 > > Log: > > MFC r326278 (manu): > >=20 > > growfs: Commit the changes after expanding the partition > >=20 > > 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. > >=20 > > 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. > >=20 > > PR: 226536 > > Sponsored by: The FreeBSD Foundation > >=20 > > Changes: > > _U stable/10/ > > stable/10/etc/rc.d/growfs > > _U stable/11/ > > stable/11/etc/rc.d/growfs > > END QUOTE > >=20 > > 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.) > >=20 > >=20 > > The original description from back then shows a > > very different 961 and 1024: > >=20 > > QUOTE > > % gpart show > >=20 > > [snip] > >=20 > > =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 > >=20 > > 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. > >=20 >=20 > 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 --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmLWxx8ACgkQAxRYpUeP 4pNZpg/+PyZZHvHcr9fciW7LRxWtinnlrRfj8J6kT7yvVi+NAHaYkhGPhoeOhA8X FzDUQQNT90SeyyZmx0cyYqPvz1w+WaARfE3RnlpHB/WOHZ6YeCxm7RcxqM3A3cp1 hLMNpgh2pIrevt8tNuVtBWGYM7Y9Y9W+OUK0bnLzIiLb3LJMZL7jmAxVAew6EFXd kjtXuisBztp2r3yzDz2+RWQLcQjPw8W4zdrTHYk6y+ACzK6xrBsPE/3My1cGzadx forB1M97CmWYIRC8pEfVeUbmdPPAvaD9uoedV48oWXftJhO3l/lGMpio28XvN3+i IPqLaTSVVa9B7JAAi9rnNIBucngBbm+3ivOs1P1ShjPWASeEwygdi6lcwHqKa+OX Gop6S7XrbWyEu7/GgMCG3kkWF7Va1YsESGqYICK72RIiNAioIEkHJkPC6a6IQKx2 1WM/+Wm0wZ6qbZLAp/3h2/UtfRa85zGmtTaguIjdSsykr30u3a92k1s+efuz7QLI 6qCsXD21DIzY5wiUvNrWpOapYkHQhb5FmelaXYvVfAyZN+YYZBSO8FbQ4d9N306R iWtS9RtA5KxrGSuvztRIqlW0b0T8ebFYnltQi3r+71vP/pKwZtDbU2Sbj4LK6cvk H+FyDn2pHH1V5sZKg2VspbN7dDywYdaGymyuHGg5kwUKWqFLIl0= =FYpo -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220719150048.GA39258>