From nobody Tue Jul 19 15:16:54 2022 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LnMrR3Rt2z4TL2n for ; Tue, 19 Jul 2022 15:17:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LnMrQ2bxFz3mnD for ; Tue, 19 Jul 2022 15:17:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1658243822; bh=I+1KU3G77K/tY8hB5fNdhOVD2zsZo7VbPQD3QSQRGKE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=TkDusHtt1lQDYNIn/PVRTXielA2ReTMZRTVfV6XI4wddrR7E81FCUKkvPVPINwfAdkPu2Rmc4Rvdh5dTj6JWSUqfwChdybw328ca5nxS0WiD+7MTTX/eim3r44oNfPmM//ZOGAdbSV+CR7PtPHRh76L6lo42oN6hXoN4J6fPP2hnpI+MB7T6QCoDClp38yG3QFL0zyarC3WpSi7AkivySc8lEPxlUwGK5zNz4fJtL7O5Evwpr+BUH+7veLd8ZNzjXK2AJT0/f6hgnXjIQR+8/JlzA7bKKboDsCg3w1aCuQejRSLWwHqDOSdfwS+HcOnSKvq5Z8XCh/gFLoiU+0HI5A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1658243822; bh=awtt5AU5AZKIM9j//CicGWWTk5NMcHc2pB2P4jl00+Y=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=O8fzhRLObdrHT2xr1+qAqiNpgPWNTH9L2EzUHrw7Asg1xPloCNwnbpyqjvmQ8En75ggXXSpCiYcYIzRSEueoMJ4O5mYZpwgMp/PwIBQdOjgo4ecbC17RjvA1+YJ7GYBvBE74MrYL95/6g6VCPHnje4HUGliHBRczVIV6SN6IzaL40VuKaY3TG3UfTb21z1r0z1BEZnhyUZqxsWx0CQWf9hk+bF/AHe7lth2lj6T76T6tp+qiWpvox/vBZZsOTJngLM5nMrqE2h9haZZS+S5nqpqSBH0hB5TTH9+WEudvSptQe6k1wyzZAtp76TNpDwzOWFQk6dcqyXHWWNJEj1Z2aw== X-YMail-OSG: lD_BlcgVM1lwFcYPGtYEUfJkfrQghuZsViB1q.YdXs1.V.bS9hANbGAs.P9PoN5 iJwfTN3sVrLj_VMdW1BNiX9xyiDFxJZbF7vRXLFiSEdQZ47MlU3RY1qtZksbz7QxrBoOt_KbHE1i sKbAn5e7Hg9rVTtzoPjiTBPpfuwFmHfntC_tB5a17NWG3MZd9zNYwCj4v.p872lyMNs9SixTlEtm uxQDJnwfH..Ak_161zsdURZ173o6.F8Qk6IAhh5Ck5_aeyXTBYaSqZNpcE2mds7WHOar7R9ZlnRv DfPbkla9ge5DK2RBTfJqBud4ZvCLE44P79W98OnTadHsn6JqeQsGfxjpcKOB7wGu0d882sbUqyzy 0xlMunahXO4N5l6A7b7IdhU9OOxBtQ6lxR9J.zL1XQmSeHd3RN4YsJEMnS8I5CieaPv6vLlkzv6L pfkj48QPqRjQnYupCmiAdGbVuMwxpOJG0NnLMb2xA.4tBXLCCnZAfwu5Z08kaa3HQ3qbYAwxDmVa RoEBfdupoGzCaygXMXV60alZV0WR64RnOlcItDSU8zd1fs1IlumHoe8AB4hMxPv_PbbA.EfYss.r zXbSapKL4VdTB7AaUobgDsaEpn3VFzMRdLF9OXGmieJwSnGt_V13tubVXO.Rpn1mjifPhqqCSNOJ sRgkEoGOBRgmTlTlSmx.8GIlPnWJ8d3HUtTNjs4dJ7ixDvDrquFyfbEqVqyGyJrqKfu1uq5adsjG 0GOsvI6Kejtk0cjlPahV18TomJdXhEzFThKcXtESij0n1EBxUaJGet1sPE_1iJnaspIurkcWu41m gwYGZNqBuEuftpqcn05Ybbx5nzOSkdLJPv48TbRFwsojAsJU9f7eBLvpzL03H9NG8alezPtTCLVP qT9M50Hi83s_i_WrEgSLRzeEmykNwqTQ.fXnEHGyc1JXoPIiYot3C36Chi2wn_j2eqPcGZv2bg8F UEdgh5ITtqKyF4HOdPbGFna9nqY0kPmZ6PS8I443v.QE9GjXcr4XUlyKrKKsG_2H_1BuBc785rE0 zMIZXqERXqXsQ3Lbt56aPiGSZH1I6uKi6vexT_JKscBfy2wZJG71_V4aoADn_qa8twqwNzXzOsRc AK5_L.vW9EwWCmM3Y6JpqpVn0As6OgxwPK_7gNGaiHnww4krkWxaePO7T_wmBQ_LKDoEOalSRuMc WkY19FPxfUXimJdIzn7RyJxmTge7xm8atbfWWqeqcvzgwJyOIssrTMPE2VcbdtoAHHk64eVHGFz9 ZzdoTi.RHR.QDfVa2ply1dzwL4BLnqozOLsG9pGAvIRSlrxVbQSYcG8z4PFLEVcL0I7kVEclJO.H BS1.UfskL3XKv9tBf70FqGlOIAGPNx1THG6u00Drhn4jyO_Uw5UnW8rRZQxTUPTCko4_y5IMnN.D pKWGb4E2Ik1JetmEgAaA9_MOu5E0waTGd9afleSFxUL5AxkKCcJ7qX0TyaMNbokTeInAQar8RnaK TMaNohU37xhiKMM94jskHufXaudXFwRyzjdag0spEMNDXf6ybW1qfV5tNm15vqw5qhGrdNoGBXOs tFKLaojw9lqyCBcuHQDEAflrOBwwl9FA14wjbPSJTzbz88prlDBItZQINhC4BwHdrwRojDFGn_z5 K9bnPbhuSOB0MdCwzw4n4SAb34aBtriRQ.dWy6_u9608mzF257OIqMklFI7iO8SNS_t7XXMKMuli gSXwCjJ7n1vw38eVjJGOjFXZNcf7gNli3X2si2TOHzfmNJ95X3AZ11Rni3ir9oCsnXTz0bSHMM0p T6qT0amCnrS7OB6.W5GjyWJxxfFmVSzmBSBO0MrgHDIle7MTPLoSgnw3tbWn9EYUfe.ggEiUNWxh 8nGF3Bty5W9k9OmvciQ.sBzjkJEYlilnD7ZZYhCv4_PI0hm7QzeelpAVYi9JEIZy_Upi6BP6YJ6D bWmFtdg6MEga0HMWSRil6h6a0ZaxrIDpDMWJD_Na7BM4XtqIZ7TRQc9_BuIVbmbxe3nXRb8NJQJr mXEhhw2u6mEB5WCnrke.WzB01iBSa6eGN_RmnPYb..jSkMFbofoIjUPLttmmbdWbCqJvFlAS0H1U Tkpz14N3NtVGuNSDLRnEPS82ojPqhYCV0UUl1mnuHRahlB9kRBpJ06l8021ExhU_q.qMUHwdTdhH IA6Q8SQktQtJh0jc.qa5K7wRjqJsW2N.l_8iSbdoO6bbIQe5ilgcov.45qTrOb_DFiwQDy53LBTW FGOpz5zNoI6DrZU9MOXggFr1DVuis4d.Yoy8VA1QknphwNToV3XMY8gCzHnd2RCx_kl6rp_1LSda CEpX0434MNUEiiB7VXBtP4BqBzReRbLuvqLqVwU3K10SIxQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Tue, 19 Jul 2022 15:17:02 +0000 Received: by hermes--production-bf1-58957fb66f-hgp8q (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bdfe1fbb823ba72881a8eb4478c257a9; Tue, 19 Jul 2022 15:16:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv From: Mark Millard In-Reply-To: <20220719150048.GA39258@FreeBSD.org> Date: Tue, 19 Jul 2022 08:16:54 -0700 Cc: dev-commits-src-main@freebsd.org, Warner Losh , Ed Maste Content-Transfer-Encoding: quoted-printable Message-Id: <514725E3-BAA8-4817-9E9B-CD8D1D5517B0@yahoo.com> References: <4D903E5A-58FB-4516-AC53-AEDFF48564A7@yahoo.com> <20220714152125.GB30607@FreeBSD.org> <3E2DCFBD-CC8F-4C13-B18C-B7DA26ED8E84@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> <20220719150048.GA39258@FreeBSD.org> To: Glen Barber X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LnMrQ2bxFz3mnD X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=TkDusHtt; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.35 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; NEURAL_HAM_MEDIUM(-0.86)[-0.859]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.30:from]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[dev-commits-src-main@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jul-19, at 08:00, Glen Barber 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.) >=20 > 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 wrote: >>>=20 >>>> On Mon, Jul 18, 2022 at 07:34:40AM -0700, Mark Millard wrote: >>>>> On 2022-Jul-18, at 07:08, Glen Barber 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 = 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 >>>=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? >=20 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=3D1 . How do we test for if the old problem is still around when kern.geom.part.mbr.enforce_chs=3D0 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=3D1 are correct/expected vs. not, given the mdconfig commands used. So I'm only guessing that using kern.geom.part.mbr.enforce_chs=3D0 is now appropriate. That would seem to be a separate issue from if the gpart behavior for kern.geom.part.mbr.enforce_chs=3D1 is correct/expected vs. not for the SBC images, given the mdconfig commands used. =3D=3D=3D Mark Millard marklmi at yahoo.com