Date: Wed, 13 Jul 2022 13:52:45 -0700 From: Mark Millard <marklmi@yahoo.com> To: Glen Barber <gjb@freebsd.org> Cc: dev-commits-src-main@freebsd.org Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv Message-ID: <8A02A4A4-9F3A-47F2-9985-EA2151043BB7@yahoo.com> In-Reply-To: <20220713204227.GA30607@FreeBSD.org> 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> <20220713204227.GA30607@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Jul-13, at 13:42, Glen Barber <gjb@freebsd.org> wrote: > 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=3D1dfcff294e44d4b45813288ef4095c36= abb22f0e >>>>>=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-13.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-a0b956f5ac5-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 >=20 > Got it. Thank you for pointing this out. (It has been years since = this > code was written, and I forgot...) :) >=20 >>> 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-a0b956f5ac5-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 >=20 > I'm confused now. Where do you see a mismatch? Both outputs look the > same to me, unless I am missing something. My manual sequence, that you have confirmed: =3D> 63 6291393 md0 MBR (3.0G) 63 1985 - free - (993K) 2048 102400 1 fat32lba (50M) The above 2 /img files, note 1985 (above) vs. 2016 (below) and 2048 (above) vs. 2079 (below): =3D> 63 6291393 md0 MBR (3.0G) 63 2016 - free - (1.0M) 2079 102312 1 fat32lba [active] (50M) Note: The differences are independent of the UFS content. So the following link and the PR involve were irrelevant to my point here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264032#c17 >> Does my sequence trying to match the use of the likes of >> arm64/RPI.conf look right to you? >>=20 >=20 > Yes, it does, now that you had refreshed my memory. >=20 >> 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 >=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). >=20 > 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. So reliable redaction would be needed. Understood. Too bad. =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?8A02A4A4-9F3A-47F2-9985-EA2151043BB7>