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

On Thu, Jul 21, 2022 at 8:55 AM Kyle Evans <[email protected]> wrote:

> On Wed, Jul 20, 2022 at 10:08 AM Mark Millard <[email protected]> wrote:
> >
> > On 2022-Jul-19, at 15:45, Warner Losh <[email protected]> wrote:
> >
> > > On Tue, Jul 19, 2022, 2:42 PM Glen Barber <[email protected]> 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.)
> >
>
> https://svnweb.freebsd.org/base?view=revision&revision=332731 says:
>
> 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.
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226536
> ("glabel/partition mixup on sdcard images")
>

Having read through all that, I think it's safe to disable it again. We
changed the build process
to avoid the original bug, so no longer need the rounding to prevent the
situation from happening.
There are no old branches or legacy reasons to keep it enabled unless
there's another side effect
of it that I'm not seeing...

Warner