Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Jul 2022 17:45:26 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        Glen Barber <gjb@FreeBSD.org>
Cc:        dev-commits-src-main@freebsd.org, Warner Losh <imp@bsdimp.com>
Subject:   Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv
Message-ID:  <5450B332-66B8-4134-81E7-ECF654791C97@yahoo.com>
In-Reply-To: <20220718145230.GB95937@FreeBSD.org>
References:  <7F4F9683-B4DE-4F65-BBD7-027039A0C270@yahoo.com> <20220713204227.GA30607@FreeBSD.org> <8A02A4A4-9F3A-47F2-9985-EA2151043BB7@yahoo.com> <4D903E5A-58FB-4516-AC53-AEDFF48564A7@yahoo.com> <20220714152125.GB30607@FreeBSD.org> <3E2DCFBD-CC8F-4C13-B18C-B7DA26ED8E84@yahoo.com> <AE47C47B-33F7-4236-8A23-688C40340EA7@yahoo.com> <DBED097F-00BD-467C-8CA3-49857DA35456@yahoo.com> <20220718140851.GA95937@FreeBSD.org> <037C78F9-CA37-4D1C-8F68-22A85183E8AF@yahoo.com> <20220718145230.GB95937@FreeBSD.org>

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

There is your:

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

and its comment #5 and related material:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227879#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=3D226536

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:=20
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]

=3D>     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=3D1 was a workaround.

=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?5450B332-66B8-4134-81E7-ECF654791C97>