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

From: Rodney W. Grimes <freebsd-rwg_at_gndrsh.dnsmgr.net>
Date: Thu, 21 Jul 2022 16:43:14 UTC
> On Thu, Jul 21, 2022 at 8:55 AM Kyle Evans <kevans@freebsd.org> wrote:
> 
> > On Wed, Jul 20, 2022 at 10:08 AM Mark Millard <marklmi@yahoo.com> 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.)
> > >
> >
> > 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...

I have come to this same conclusion after reading as well.

> Warner

-- 
Rod Grimes                                                 rgrimes@freebsd.org