Date: Wed, 13 Jul 2022 20:42:27 +0000 From: Glen Barber <gjb@freebsd.org> To: Mark Millard <marklmi@yahoo.com> Cc: dev-commits-src-main@freebsd.org Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv Message-ID: <20220713204227.GA30607@FreeBSD.org> In-Reply-To: <7F4F9683-B4DE-4F65-BBD7-027039A0C270@yahoo.com> References: <84410D65-6F86-44E5-8B14-8A523C9919C7.ref@yahoo.com> <84410D65-6F86-44E5-8B14-8A523C9919C7@yahoo.com> <20220713201327.GY30607@FreeBSD.org> <7F4F9683-B4DE-4F65-BBD7-027039A0C270@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--T/fV2W0kJN0MA/Wg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 13, 2022 at 01:35:22PM -0700, Mark Millard wrote: > On 2022-Jul-13, at 13:13, Glen Barber <gjb@freebsd.org> wrote: >=20 > > On Wed, Jul 13, 2022 at 12:06:55PM -0700, Mark Millard wrote: > >> Glen Barber <gjb_at_FreeBSD.org> wrote on > >> Date: Wed, 13 Jul 2022 18:37:34 UTC : > >>=20 > >>> The branch main has been updated by gjb: > >>>=20 > >>> URL: https://cgit.FreeBSD.org/src/commit/?id=3D1dfcff294e44d4b4581328= 8ef4095c36abb22f0e > >>>=20 > >>> commit 1dfcff294e44d4b45813288ef4095c36abb22f0e > >>> Author: Glen Barber <gjb@FreeBSD.org> > >>> AuthorDate: 2022-07-13 18:36:22 +0000 > >>> Commit: Glen Barber <gjb@FreeBSD.org> > >>> CommitDate: 2022-07-13 18:36:22 +0000 > >>>=20 > >>> release: increase IMAGE_SIZE for arm, arm64, riscv > >>>=20 > >>> Related to: PR 264032 > >>> MFC after: 5 minutes > >>> Sponsored by: Rubicon Communications, LLC ("Netgate") > >>=20 > >> I may have some evidence that, for example, > >>=20 > >> http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-= 14.0-CURRENT-arm64-aarch64-RPI-20220708-a0b956f5ac5-256605.img.xz > >>=20 > >> and: > >>=20 > >> http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.1/FreeBSD-1= 3.1-RELEASE-arm-armv6-RPI-B.img.xz > >>=20 > >> were not built fully via the /usr/src/release procedures > >> using modern builds of mdconfig and such. The below is > >> taken from a different list exchange. > >>=20 > >> QUOTE > >> I tried what it looks to me the /usr/src/release/ > >> code would do initially for arm64/RPI.conf (but with > >> my file naming and an explicit -u0 style of use): > >>=20 > >> # truncate -s3072m mmjnk.test > >> # mdconfig -u0 -fmmjnk.test -x63 -y255 > >> # gpart create -sMBR md0 > >> md0 created > >> # gpart show md0 > >> =3D> 63 6291393 md0 MBR (3.0G) > >> 63 6291393 - free - (3.0G) > >> # gpart add -t'!12' -a512k -s50m -b1m md0 > >> md0s1 added > >> # gpart show md0 > >> =3D> 63 6291393 md0 MBR (3.0G) > >> 63 1985 - free - (993K) > >> 2048 102400 1 fat32lba (50M) > >> 104448 6187008 - free - (3.0G) > >>=20 > >> I tried the same sequence in a chroot into a 13.0-RELEASE-p11 > >> tree on an aarch64 main [so: 14] machine. I got the same result. > >>=20 > >> But such is not what the 13.1-RELEASE build produced, for > >> example: > >>=20 > >> # mdconfig -u0 -fFreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img -x63 -y255 > >> # gpart show md0 > >> =3D> 63 6291393 md0 MBR (3.0G) > >> 63 2016 - free - (1.0M) > >> 2079 102312 1 fat32lba [active] (50M) > >> 104391 6187041 2 freebsd (3.0G) > >> 6291432 24 - free - (12K) > >>=20 > >> (There are no 13.1-STABLE snapshots available to download > >> and look at.) > >>=20 > >> Looking at the recent 14.0-CURRENT snapshot: > >>=20 > >> # mdconfig -u0 -fFreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220708-a0b95= 6f5ac5-256605.img -x63 -y255 > >> # gpart show md0 > >> =3D> 63 6291393 md0 MBR (3.0G) > >> 63 2016 - free - (1.0M) > >> 2079 102312 1 fat32lba [active] (50M) > >> 104391 6187041 2 freebsd (3.0G) > >> 6291432 24 - free - (12K) > >>=20 > >> So, also not matching. > >> END QUOTE > >>=20 > >=20 > > There are no local configurations on the builders that would produce > > differing output. Why, though, are you specifying '-x' and '-y' to > > mdconfig? >=20 > The first time I listed -x and -y: >=20 > QUOTE > # truncate -s3072m mmjnk.test > # mdconfig -u0 -fmmjnk.test -x63 -y255 > END QUOTE >=20 > is because the /usr/src/release/ activity does so. >=20 > The other times (-fFreeBSD*.img examples) I tried both > without and then with and got no differences in the > result and just showed the last variant that I tried. > Sorry for that making it confusing. >=20 Got it. Thank you for pointing this out. (It has been years since this code was written, and I forgot...) :) > > I think that may be obfuscating something when attaching the > > image as an md(4) device. >=20 > Just to be explicit, without -x -y use: >=20 > # mdconfig -u0 -fFreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img > CA72_16Gp_ZFS aarch64 1400063 1400063 # gpart show md0 > =3D> 63 6291393 md0 MBR (3.0G) > 63 2016 - free - (1.0M) > 2079 102312 1 fat32lba [active] (50M) > 104391 6187041 2 freebsd (3.0G) > 6291432 24 - free - (12K) >=20 > # mdconfig -d -u0 >=20 > # mdconfig -u0 -fFreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220708-a0b956f5= ac5-256605.img > # gpart show md0 > =3D> 63 6291393 md0 MBR (3.0G) > 63 2016 - free - (1.0M) > 2079 102312 1 fat32lba [active] (50M) > 104391 6187041 2 freebsd (3.0G) > 6291432 24 - free - (12K) >=20 > # mdconfig -d -u0 >=20 > Still not a match. >=20 I'm confused now. Where do you see a mismatch? Both outputs look the same to me, unless I am missing something. > Does my sequence trying to match the use of the likes of > arm64/RPI.conf look right to you? >=20 Yes, it does, now that you had refreshed my memory. > QUOTE > # truncate -s3072m mmjnk.test > # mdconfig -u0 -fmmjnk.test -x63 -y255 > # gpart create -sMBR md0 > md0 created > # gpart show md0 > =3D> 63 6291393 md0 MBR (3.0G) > 63 6291393 - free - (3.0G) > # gpart add -t'!12' -a512k -s50m -b1m md0 > md0s1 added > # gpart show md0 > =3D> 63 6291393 md0 MBR (3.0G) > 63 1985 - free - (993K) > 2048 102400 1 fat32lba (50M) > 104448 6187008 - free - (3.0G) > END QUOTE >=20 > Unless a difference can be identified vs. what > I should have done but did not do, the differing > results need an explanation before reliable > results can be expected. >=20 > If I had access to the snapshot or release build > log(s) involved for either/both of the FreeBSD*.img > files, I'd compare for my self (if the log has the > involved commands shown). But, so far as I know, > the logs are not accessible for comparison/contrast > investigation activities. >=20 > (A similar point potentially goes for looking at > log(s) for the failed stable/13 builds.) >=20 The log files are not retained automatically, unfortunately, however I will be sure to share the logs from this week's snapshot builds (should they fail again). I have to be very careful about making log access "easy", due to information contained within, such as API keys/tokens/etc., which is embedded for debugging purposes, but not at all intended to be public. Glen --T/fV2W0kJN0MA/Wg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmLPLjMACgkQAxRYpUeP 4pPO5Q//b6oY8+jlVPBzYQoT5s6MkwqrTg6DE6AvwvBrGjzfP0nr3XZ/PxOtQbMj C2TI7BIBnQgwa9bm3d49/7xKUdHY0YHp19a5ouA+YnOItOYISXBos999Lo9jH4LK mpGFwPdQHds/OATLvABrewyGhCyfME8ljhixQbOLlYYcyui9no5BlgdWvXpoYG9W B/81KVVBWUoTM29/Zmmltnt+PjKM5ulEemua+dcfWqnV3n5XMNjIJipB367C9C1u EmApe5SWXHCzZRMgYQGVqsc5KdlxPGPBgge5afy822tB6z/hBsx9l8tOKDWnC9XI wOj5Eov+RLPzOHocZIyWRcYdMUYWJvZ/jN7uHpB7pxF0fpMUTOb0yjW5lwTCfjZe X/dpAcaQfjQm2is309Cx3eKYZjdROkvhDbd6CmKDHCmQgjHA4aLk9ikpZtef0f6K BID7Iue3f8/9z6zkWAfoJ2CtfR35qFczSB9DMcM3XDA5Ct7UMmQfnxSBB6VQm5Tt VPgN86EEYvIbJS8Px+jQC0r4LpcEH2rUP30aDgLJX/qUIew9xPeCoEnMVbL9jrZt zwx3C6mEGL8GejzEmcTtW3FJJLOk4iI3CmjMBb6k2p26oxXTToq5MO+ZdYz81thq PqRF5hIPcXQP/ugF0wqarYJ/0pRfWCWTgHcpuVOTImlvg1vCKGE= =sudH -----END PGP SIGNATURE----- --T/fV2W0kJN0MA/Wg--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220713204227.GA30607>