Date: Tue, 19 Jul 2022 14:58:41 +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> Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv Message-ID: <20220719145841.GI30607@FreeBSD.org> In-Reply-To: <5450B332-66B8-4134-81E7-ECF654791C97@yahoo.com> References: <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> <5450B332-66B8-4134-81E7-ECF654791C97@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--GIiV3jS+H8OpfTjs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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-83= 1c6b8edda-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 alig= nment. > >>>> If this variable is set to a non-zero value, the module w= ill > >>>> automatically recalculate the user-specified offset and s= ize for > >>>> alignment with the CHS geometry. Otherwise the values wi= ll 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 s= ize 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 >=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 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 --GIiV3jS+H8OpfTjs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmLWxqEACgkQAxRYpUeP 4pMLTg//bI+X9ZgzYtHaD5/6eyleIuErRN5uzPKU80aZ5oucrKZ46VUzte1Iq2Lz HJXycfyOL8OP5JvdjpfoPChPoZ6/4qDgtthQwId0StU7JUtroaASDkd3BMS8tZPW GkEAnzTFIeFh71aviYkp5lyIP41AeGA7UNei9EWzr3uQ+3rWp+fEK3qWL4dIL0WG 4W9BqkVveFfXQU20/fkz6QcJkr1na5ETaV5OU1kwH4za+Lq+UGLwl1x56GJRBh9z Ef2mqnV52NmnbDwqKte2yv63FnDeUdyocaB78732EH+xYVmC332w1i8Fy9PdV9FM jz0rMLvenrXvTLzc7mAKO6/fzwyw5nDUN7RtRyT+chm8CQ6Z7clNSyxkc+1/wpkz +Zw6YL2/z1MmufJ/v3yAF5ZaCcup5GZEgj1QBmfvniqg5rnz4mOYmbM2hT8YqA0w WEozu8Hh4STFevpSFdiDq0m9NAWWclSMONhm9SWhFAc396AWMD9uGbwGMF8FXH3U QvQilwbJneaEM7Pp6j/09PIfen0jNZc80HMuURSiRzOUlAs52CYN9ZKON6ziSpGh n3QrgSrvdUO9bwOeR6sd3gQI28S1m9frdJMdAdkZDACYGOvxwjH7B2MyGDlQrc+E NFxwvsGhlB8AoI7CBa9lM3CbPat+JbF9idMKmrEYeqckTXYkXVM= =lgb6 -----END PGP SIGNATURE----- --GIiV3jS+H8OpfTjs--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220719145841.GI30607>