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

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:


author	Andrey V. Elsukov <ae@FreeBSD.org>	2014-08-12 10:31:31 +0000
committer	Andrey V. Elsukov <ae@FreeBSD.org>	2014-08-12 10:31:31 +0000
commit	36b16d1f7d1bb7fba28a92aaf802bf4cfbfbb41f (patch)
tree	cc947686f44a14cc26f61bf64cdb06d7dab35fb3 /sys/geom/part/g_part_mbr.c
parent	a327e0b08aa16a3fbce30b21be7f59363db035a6 (diff)
download	src-36b16d1f7d1bb7fba28a92aaf802bf4cfbfbb41f.tar.gz
src-36b16d1f7d1bb7fba28a92aaf802bf4cfbfbb41f.zip
Turn off kern.geom.part.mbr.enforce_chs by default.
Notes

Notes:
    svn path=/head/; revision=269857

Diffstat (limited to 'sys/geom/part/g_part_mbr.c')
-rw-r--r--	sys/geom/part/g_part_mbr.c	4	
1 files changed, 2 insertions, 2 deletions
diff --git a/sys/geom/part/g_part_mbr.c b/sys/geom/part/g_part_mbr.c
index 8b32778d23df..5073398c954c 100644
--- a/sys/geom/part/g_part_mbr.c
+++ b/sys/geom/part/g_part_mbr.c
@@ -53,9 +53,9 @@ SYSCTL_DECL(_kern_geom_part);
 static SYSCTL_NODE(_kern_geom_part, OID_AUTO, mbr, CTLFLAG_RW, 0,
     "GEOM_PART_MBR Master Boot Record");
 
-static u_int enforce_chs = 1;
+static u_int enforce_chs = 0;
 SYSCTL_UINT(_kern_geom_part_mbr, OID_AUTO, enforce_chs,
-    CTLFLAG_RWTUN, &enforce_chs, 1, "Enforce alignment to CHS addressing");
+    CTLFLAG_RWTUN, &enforce_chs, 0, "Enforce alignment to CHS addressing");
 
 #define	MBRSIZE		512



===
Mark Millard
marklmi at yahoo.com