Date: Tue, 19 Jul 2022 16:45:13 -0600 From: Warner Losh <imp@bsdimp.com> To: Glen Barber <gjb@freebsd.org> Cc: Ed Maste <emaste@freebsd.org>, "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, Mark Millard <marklmi@yahoo.com>, dev-commits-src-main@freebsd.org, "Dr. Rolf Jansen" <freebsd-rj@cyclaero.com>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv [odd alignment for SBC images] Message-ID: <CANCZdfoABLggPQgDeCZ5FzYCf8243kvr-p8Bj5_JGNnEszGHBw@mail.gmail.com> In-Reply-To: <20220719204245.GL30607@FreeBSD.org> References: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com> <202207171708.26HH81bA062303@gndrsh.dnsmgr.net> <CAPyFy2D1aBe8h4kq=RqCR2tkEiEXh_pHNEqaAnW7tk9-HxCmBQ@mail.gmail.com> <20220719204245.GL30607@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000008a131c05e4303d7f
Content-Type: text/plain; charset="UTF-8"
On Tue, Jul 19, 2022, 2:42 PM Glen Barber <gjb@freebsd.org> wrote:
> On Tue, Jul 19, 2022 at 04:35:36PM -0400, Ed Maste wrote:
> > On Sun, 17 Jul 2022 at 13:08, Rodney W. Grimes
> > <freebsd-rwg@gndrsh.dnsmgr.net> wrote:
> >
> > > Perhaps an assert for kern.geom.part.mbr.enforce_chs not
> > > being zero in /usr/src/release scripts is in order so that
> > > the builds blow up rather than produce BAD images.
> >
> > This is a good interim step (before switching to mkimg).
> >
> > Perhaps:
> >
> > diff --git a/release/tools/arm.subr b/release/tools/arm.subr
> > index 77b708bca4a2..94e0ee89deaf 100644
> > --- a/release/tools/arm.subr
> > +++ b/release/tools/arm.subr
> > @@ -62,6 +62,10 @@ umount_loop() {
> > }
> >
> > arm_create_disk() {
> > + if [ $(sysctl -n kern.geom.part.mbr.enforce_chs) != 0 ]; then
> > + return 1
> > + fi
> > +
> > # Create the target raw file and temporary work directory.
> > chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev}
> > if [ "${PART_SCHEME}" = "GPT" ]; then
> >
>
> 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.
Warner
P.s. the last BIOS that I had to deal with where this mattered was a 133MHz
pentium PC104 board in 2002 or 2003.
>
--0000000000008a131c05e4303d7f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Tue, Jul 19, 2022, 2:42 PM Glen Barber <<a href=
=3D"mailto:gjb@freebsd.org">gjb@freebsd.org</a>> wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">On Tue, Jul 19, 2022 at 04:35:36PM -0400, Ed Maste =
wrote:<br>
> On Sun, 17 Jul 2022 at 13:08, Rodney W. Grimes<br>
> <<a href=3D"mailto:freebsd-rwg@gndrsh.dnsmgr.net" target=3D"_blank"=
rel=3D"noreferrer">freebsd-rwg@gndrsh.dnsmgr.net</a>> wrote:<br>
> <br>
> > Perhaps an assert for kern.geom.part.mbr.enforce_chs not<br>
> > being zero in /usr/src/release scripts is in order so that<br>
> > the builds blow up rather than produce BAD images.<br>
> <br>
> This is a good interim step (before switching to mkimg).<br>
> <br>
> Perhaps:<br>
> <br>
> diff --git a/release/tools/arm.subr b/release/tools/arm.subr<br>
> index 77b708bca4a2..94e0ee89deaf 100644<br>
> --- a/release/tools/arm.subr<br>
> +++ b/release/tools/arm.subr<br>
> @@ -62,6 +62,10 @@ umount_loop() {<br>
>=C2=A0 }<br>
> <br>
>=C2=A0 arm_create_disk() {<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0if [ $(sysctl -n kern.geom.part.mbr.enforc=
e_chs) !=3D 0 ]; then<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return 1<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0fi<br>
> +<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# Create the target raw file and temp=
orary work directory.<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0chroot ${CHROOTDIR} gpart create -s $=
{PART_SCHEME} ${mddev}<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if [ "${PART_SCHEME}" =3D &=
quot;GPT" ]; then<br>
> <br>
<br>
My concern with this is kern.geom.part.mbr.enforce_chs is always '1'=
; on<br>
the builders, which effectively means all arm builds will fail every<br>
time.=C2=A0 I think we need to get to the actual root of the problem here,<=
br>
versus applying band-aids to a shark bite.<br></blockquote></div></div><div=
dir=3D"auto"><br></div><div dir=3D"auto">I think this is the actual proble=
m. While such pedantry can be useful for ancient picky BIOSes, these days o=
nly 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.=C2=A0</div><div dir=3D"=
auto"><br></div><div dir=3D"auto">Why is it =3D=3D 1 on the builder? If peo=
ple want things aligned gpart has an option for years iirc to do that. And =
we want that off for the builds.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Warner</div><div dir=3D"auto"><br></div><div dir=3D"auto">P.s. th=
e last BIOS that I had to deal with where this mattered was a 133MHz pentiu=
m PC104 board in 2002 or 2003.</div><div dir=3D"auto"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>
--0000000000008a131c05e4303d7f--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoABLggPQgDeCZ5FzYCf8243kvr-p8Bj5_JGNnEszGHBw>