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

Reply: Glen Barber : "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: Tue, 19 Jul 2022 00:45:26 UTC
On 2022-Jul-18, at 07:52, Glen Barber <gjb@FreeBSD.org> wrote:

> On Mon, Jul 18, 2022 at 07:34:40AM -0700, Mark Millard wrote:
>> On 2022-Jul-18, at 07:08, Glen Barber <gjb@freebsd.org> wrote:
>> 
>>> On Sat, Jul 16, 2022 at 11:24:47PM -0700, Mark Millard wrote:
>>>> 
>>>> 
>>>> On 2022-Jul-15, at 17:41, Mark Millard <marklmi@yahoo.com> wrote:
>>>> 
>>>>> FYI for the new snapshot build of 13.1-STABLE:
>>>>> 
>>>>> # mdconfig -u0 -f FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220715-831c6b8edda-251792.img 
>>>>> # gpart show md0
>>>>> =>      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)
>>>>> 
>>>>> 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.
>>>>> 
>>>>> 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.
>>>> 
>>>> In the live build environment that makes the images,
>>>> what is:
>>>> 
>>>> # sysctl kern.geom.part.mbr.enforce_chs
>>>> kern.geom.part.mbr.enforce_chs: 0
>>>> 
>>>> I ask because of the description:
>>>> 
>>>> 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
>>>> 
>>>> In particular, the text about non-zero values leading to:
>>>> 
>>>> QUOTE
>>>> the module will
>>>>            automatically recalculate the user-specified offset and size for
>>>>            alignment with the CHS geometry
>>>> END QUOTE
>>>> 
>>>> 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.
>>>> 
>>> 
>>> 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.
>>> 
>> 
>> 0 is the default that shows up on the systems
>> that I have access to.
>> 
>> It has not been the default since 2014-08-12:
>> 
> 
> 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.
> 

There is your:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227879

and its comment #5 and related material:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227879#c5

Appearently the issues noted are part of what lead to the
SBC's use lodaer.efi as bootaa64.efi instead of using
boot1.efi .


There is also the older:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226536

where kern.geom.part.mbr.enforce_chs assignment on
builders is referenced in a commit notice, comment #29:

QUOTE
A commit references this bug:

Author: gjb
Date: Wed Apr 18 16:22:23 UTC 2018
New revision: 332731
URL: 
https://svnweb.freebsd.org/changeset/base/332731


Log:
  MFC r326278 (manu):

   growfs: Commit the changes after expanding the partition

   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.

  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.

  PR:		226536
  Sponsored by:	The FreeBSD Foundation

Changes:
_U  stable/10/
  stable/10/etc/rc.d/growfs
_U  stable/11/
  stable/11/etc/rc.d/growfs
END QUOTE

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


The original description from back then shows a
very different 961 and 1024:

QUOTE
% gpart show

[snip]

=>     63  6291393  md0  MBR  (3.0G)
       63      961       - free -  (481K)
     1024    34816    1  !12  [active]  (17M)
    35840  6255616    2  freebsd  (3.0G)
END QUOTE

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=1 was a workaround.

===
Mark Millard
marklmi at yahoo.com