Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv [odd alignment for SBC images]

On Wed, Jul 20, 2022 at 10:08:20AM -0700, Mark Millard wrote:
> On 2022-Jul-19, at 15:45, Warner Losh <imp@bsdimp.com> wrote:
> 
> > On Tue, Jul 19, 2022, 2:42 PM Glen Barber <gjb@freebsd.org> wrote:
> >>> . . .
> >> 
> >> My concern with this is kern.geom.part.mbr.enforce_chs is always '1' on
> >> the builders, which effectively means all arm builds will fail every
> >> time.  I think we need to get to the actual root of the problem here,
> >> versus applying band-aids to a shark bite.
> > 
> > I think this is the actual problem. While such pedantry can be useful for ancient picky BIOSes, these days only the LBA fields of the MBR are used. And the fake BIOS geometry is crazy weird. We can likely tweak it to be more friendly. 
> > 
> > Why is it == 1 on the builder? If people want things aligned gpart has an option for years iirc to do that. And we want that off for the builds.
> 
> Would it seem appropriate to use a week (this week?) to do all
> the snapshot builds with the builders all set to have
> kern.geom.part.mbr.enforce_chs=0 and see what breaks, if anything?
> (Sort of a snapshot exp run.)
> 

Sorry, it is too late for this week's snapshots, but I will set it to
'0' for next week's (I was out the past two days, so did not see this
email until now).

> More than just the SBC images might be involved for
> kern.geom.part.mbr.enforce_ch consequences, for all I know.
> 

This vaguely rings a bell.  I am still trying to find the original
problem being reported that caused me to set enforce_csh=1, but I have
not had much luck.

I do recall it being a strange case that enforce_csh=1 had apparently
fixed (or masked something else going on).

Glen