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

On Mon, Jul 18, 2022 at 05:45:26PM -0700, Mark Millard wrote:
> 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.
> 

Thank you very much for drilling down into this.  So....  straw-man
question:  do we indeed have a problem here, or did we fix a bug with
another bug?

Glen