Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv

From: Glen Barber <gjb_at_freebsd.org>
Date: Wed, 13 Jul 2022 20:42:27 UTC
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:
> 
> > 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 :
> >> 
> >>> The branch main has been updated by gjb:
> >>> 
> >>> URL: https://cgit.FreeBSD.org/src/commit/?id=1dfcff294e44d4b45813288ef4095c36abb22f0e
> >>> 
> >>> 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
> >>> 
> >>>    release: increase IMAGE_SIZE for arm, arm64, riscv
> >>> 
> >>>    Related to:     PR 264032
> >>>    MFC after:      5 minutes
> >>>    Sponsored by:   Rubicon Communications, LLC ("Netgate")
> >> 
> >> I may have some evidence that, for example,
> >> 
> >> http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220708-a0b956f5ac5-256605.img.xz
> >> 
> >> and:
> >> 
> >> http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.1/FreeBSD-13.1-RELEASE-arm-armv6-RPI-B.img.xz
> >> 
> >> 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.
> >> 
> >> 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):
> >> 
> >> # truncate -s3072m mmjnk.test
> >> # mdconfig -u0 -fmmjnk.test -x63 -y255
> >> # gpart create -sMBR md0
> >> md0 created
> >> # gpart show md0
> >> =>     63  6291393  md0  MBR  (3.0G)
> >>      63  6291393       - free -  (3.0G)
> >> # gpart add -t'!12' -a512k -s50m -b1m md0
> >> md0s1 added
> >> # gpart show md0
> >> =>     63  6291393  md0  MBR  (3.0G)
> >>      63     1985       - free -  (993K)
> >>    2048   102400    1  fat32lba  (50M)
> >>  104448  6187008       - free -  (3.0G)
> >> 
> >> 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.
> >> 
> >> But such is not what the 13.1-RELEASE build produced, for
> >> example:
> >> 
> >> # mdconfig -u0 -fFreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img -x63 -y255
> >> # gpart show md0
> >> =>     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)
> >> 
> >> (There are no 13.1-STABLE snapshots available to download
> >> and look at.)
> >> 
> >> Looking at the recent 14.0-CURRENT snapshot:
> >> 
> >> # mdconfig -u0 -fFreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220708-a0b956f5ac5-256605.img -x63 -y255
> >> # gpart show md0
> >> =>     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)
> >> 
> >> So, also not matching.
> >> END QUOTE
> >> 
> > 
> > There are no local configurations on the builders that would produce
> > differing output.  Why, though, are you specifying '-x' and '-y' to
> > mdconfig?
> 
> The first time I listed -x and -y:
> 
> QUOTE
> # truncate -s3072m mmjnk.test
> # mdconfig -u0 -fmmjnk.test -x63 -y255
> END QUOTE
> 
> is because the /usr/src/release/ activity does so.
> 
> 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.
> 

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.
> 
> Just to be explicit, without -x -y use:
> 
> # mdconfig -u0 -fFreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
> CA72_16Gp_ZFS aarch64  1400063 1400063 # gpart show md0
> =>     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)
> 
> # mdconfig -d -u0
> 
> # mdconfig -u0 -fFreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220708-a0b956f5ac5-256605.img
> # gpart show md0
> =>     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)
> 
> # mdconfig -d -u0
> 
> Still not a match.
> 

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?
> 

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
> =>     63  6291393  md0  MBR  (3.0G)
>      63  6291393       - free -  (3.0G)
> # gpart add -t'!12' -a512k -s50m -b1m md0
> md0s1 added
> # gpart show md0
> =>     63  6291393  md0  MBR  (3.0G)
>      63     1985       - free -  (993K)
>    2048   102400    1  fat32lba  (50M)
>  104448  6187008       - free -  (3.0G)
> END QUOTE
> 
> 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.
> 
> 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.
> 
> (A similar point potentially goes for looking at
> log(s) for the failed stable/13 builds.)
> 

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