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

Reply: Mark Millard : "Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv"
In reply to: Glen Barber : "Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Mark Millard <marklmi_at_yahoo.com>
Date: Wed, 13 Jul 2022 20:52:45 UTC
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:
>> 
>>> 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.

My manual sequence, that you have confirmed:

=>     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):

=>     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=264032#c17

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

So reliable redaction would be needed. Understood.
Too bad.


===
Mark Millard
marklmi at yahoo.com