From nobody Tue Jul 19 22:45:13 2022 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LnYnf4s8Zz46lXN for ; Tue, 19 Jul 2022 22:45:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LnYnf0cSDz3PB5 for ; Tue, 19 Jul 2022 22:45:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2e.google.com with SMTP id t127so14804740vsb.8 for ; Tue, 19 Jul 2022 15:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7IT3NKuZrf7x70WMY/wDvkQk3POtLJG6Cru2ya/2fQg=; b=jfhVWJkUy35znES0bxAfHWb6CRu2c2y18DMHUz+tcNrMUrkfhYvZGxVB+XSFMt2kSC qZbB22arKHqCLqHkB9H2UPCxEqKFSg7hhpaKLlzp/DGLrSblDfzu9wQtZeT7eUv4IgwB bwW8BAyBaXH08GYuZfpLjq0l36z3ldZDTgKKUyHvFVGG6UN0i7JvMSIyxftza4rfkwf1 jbSbbovJGFOc4oVqn7rg9i4zUF0vhuR3kuxaYspx0WVzo0RET6O43UFpyYl6DdwqLCjj BHbG9JAtjfepOLJJv04E5JfIjxELphtgfNJii3GAolMM7xxHvd7PlgyGAj/h0Hgaj/C8 d/Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7IT3NKuZrf7x70WMY/wDvkQk3POtLJG6Cru2ya/2fQg=; b=GREDvN1gSK6VaeRnvVJ9rUCMJlZG34tbJ1GWnYaWCfqnC/TW5faX2w1ccBKKLG5Yto VCyTt8xgPfri6AC3DCW63VwfsWT2XbLAEsk6npbMaMTt6RhkQC6527DnMdiYE/B+P3Kh A5rwJ6vk+sBwWKJgJHyaapotSiBZ2y3FvMPavOASV9fBHQDPdYenSE8Lsjh8IZaoVtrp gYCVB/LrRerH+E9lkKM1vMLmCEvAcIkEnB8WvEiMwWZ6iuKWYc3tiiJF2MdLNkqI3H7V 7XgI70HgGutZsIoA0ZQN91WOCMFTCSDDMtN9jHYteh0vfQpuT4oI6LDvEBBWN3GLlyzE Ocmg== X-Gm-Message-State: AJIora839roxN/rhFXY8oePU22RKYNop2wT3jCzKyhY2oxBkgV95Bdmt xdEMpJl2scpl+CGbv1pCoaZjfAFyH2QcfWTTaWSM8A== X-Google-Smtp-Source: AGRyM1tLqaDHYBoaHfon0wh94tTiRaPaa0KjTRs0k+ICaa7ABQrH+YHmfc9LSv8YJHLAe24TM5rXAUHrJ69yoVgpYe8= X-Received: by 2002:a05:6102:346:b0:357:79f5:63ae with SMTP id e6-20020a056102034600b0035779f563aemr13028175vsa.40.1658270725568; Tue, 19 Jul 2022 15:45:25 -0700 (PDT) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 References: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com> <202207171708.26HH81bA062303@gndrsh.dnsmgr.net> <20220719204245.GL30607@FreeBSD.org> In-Reply-To: <20220719204245.GL30607@FreeBSD.org> From: Warner Losh Date: Tue, 19 Jul 2022 16:45:13 -0600 Message-ID: Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv [odd alignment for SBC images] To: Glen Barber Cc: Ed Maste , "Rodney W. Grimes" , Mark Millard , dev-commits-src-main@freebsd.org, "Dr. Rolf Jansen" , freebsd-arm Content-Type: multipart/alternative; boundary="0000000000008a131c05e4303d7f" X-Rspamd-Queue-Id: 4LnYnf0cSDz3PB5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=jfhVWJkU; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2e) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[dev-commits-src-main@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_CC(0.00)[freebsd.org,gndrsh.dnsmgr.net,yahoo.com,cyclaero.com]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2e:from]; ARC_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; PREVIOUSLY_DELIVERED(0.00)[dev-commits-src-main@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-ThisMailContainsUnwantedMimeParts: N --0000000000008a131c05e4303d7f Content-Type: text/plain; charset="UTF-8" On Tue, Jul 19, 2022, 2:42 PM Glen Barber 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 > > 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


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() {
>=C2=A0 }
>
>=C2=A0 arm_create_disk() {
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0if [ $(sysctl -n kern.geom.part.mbr.enforc= e_chs) !=3D 0 ]; then
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return 1
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0fi
> +
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# Create the target raw file and temp= orary work directory.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0chroot ${CHROOTDIR} gpart create -s $= {PART_SCHEME} ${mddev}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if [ "${PART_SCHEME}" =3D &= quot;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.=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.

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

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.

Warner

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.
--0000000000008a131c05e4303d7f--