On Wed, Jul 20, 2022 at 10:08:20AM -0700, Mark Millard wrote: > On 2022-Jul-19, at 15:45, Warner Losh <i...@bsdimp.com> wrote: > > > On Tue, Jul 19, 2022, 2:42 PM Glen Barber <g...@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
signature.asc
Description: PGP signature
