From nobody Wed Jul 20 16:34:19 2022 X-Original-To: freebsd-arm@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 4Lp1WG6hqvz4XNvl; Wed, 20 Jul 2022 16:34:34 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lp1WG4S1vz3yZ0; Wed, 20 Jul 2022 16:34:34 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 26KGYJPq074209; Wed, 20 Jul 2022 09:34:19 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 26KGYJjv074208; Wed, 20 Jul 2022 09:34:19 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202207201634.26KGYJjv074208@gndrsh.dnsmgr.net> Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv [odd alignment for SBC images] In-Reply-To: To: Warner Losh Date: Wed, 20 Jul 2022 09:34:19 -0700 (PDT) CC: Glen Barber , Ed Maste , "Rodney W. Grimes" , Mark Millard , dev-commits-src-main@freebsd.org, "Dr. Rolf Jansen" , freebsd-arm X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Rspamd-Queue-Id: 4Lp1WG4S1vz3yZ0 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > 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 > > > + Yes Please, once the builder issue is addressed. > > > # 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. I do agree that this appears to be the actual problem, and given that it is now known that this value is set to 1 on the builders just goes to confirm that. > > 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. Thats a question I would like to see answered as well. > > 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. Concur, CHS is pretty much ignored since 2000ish, other than a few bioses may blow chunks with a divide by zero if you leave them empty. NOTE that the ending CHS address in a partition entry is often used to decide the "fake" geometry of an LBA device by the BIOS, so IMHO if are going to do 1MB (2048 sector) type alignments we should be using fake CHS values that are something like my favorive S=32, H=64, which comes from very early SCSI translations, and tends to "just work everywhere". The magical value 1023 for Cylinders is often used to indicate it is fake, the other value less often used is to just use the low 10 bits of what ever the translated value comes out to be. Please lets not continue to produce these wonky images. -- Rod Grimes rgrimes@freebsd.org