From nobody Sun Aug 07 22:51:35 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 4M1F2F1PY6z4Y3cs for ; Sun, 7 Aug 2022 22:51:49 +0000 (UTC) (envelope-from freebsd-rj@cyclaero.com) Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.163]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M1F2D5THgz3fs1; Sun, 7 Aug 2022 22:51:48 +0000 (UTC) (envelope-from freebsd-rj@cyclaero.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1659912701; s=strato-dkim-0002; d=cyclaero.com; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:Cc:Date: From:Subject:Sender; bh=BdTelD50G7EK5G7Qhs/TBKUTJubJrTuqmDcqKaXgWEI=; b=pwZ5vYFcCx/DFgzq7XN6FF0RIqVaJsKP7lTk4r+hPSP7SqaoHwBYj18NzSAACLJP59 YUULHW+sq6UGws+LrJtsna1Cz3ejkIe1tCVB5kvA1BsyKsaZW5I6dlSCBQj3O4ICd7vt gQXoyeCWgkOHhhr97wXecdie7/JcJEkTeVHBEWxne762qHZDZP2uJDXgzwfGAuHZpnmB ZcTFhhayC7hVtkuwa56NvfWMpnHTcIjOdlHBSFUnvm/f4bARY9hVHbZ9VxytNHy4oKBH I4LOtCqYkdiJ/AgiH7mVy9S0AkWEEbPAHXHTY1SSEiQR4pU/h6z1UfZ4DZ3LaSnwFk9i CWIA== X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg=" X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com by smtp.strato.de (RZmta 47.47.0 AUTH) with ESMTPSA id q0201fy77Mpeths (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Mon, 8 Aug 2022 00:51:40 +0200 (CEST) Received: from rolf-mini.obsigna.com (unknown [177.189.198.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 9FD8763AD1; Mon, 8 Aug 2022 00:51:38 +0200 (CEST) Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 12.4 \(3445.104.15\)) Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use From: "Dr. Rolf Jansen" In-Reply-To: <2016951A-BF16-4780-85FF-0B77E91FBBD4@yahoo.com> Date: Sun, 7 Aug 2022 19:51:35 -0300 Cc: Glen Barber , Warner Losh , "Rodney W. Grimes" , Ed Maste , Mark Millard Content-Transfer-Encoding: quoted-printable Message-Id: <6483BD0C-AFDF-443D-BEA2-9F599C9B8C07@cyclaero.com> References: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com> <99DC4046-AB8D-4D10-9475-94A8DC89DCFA@cyclaero.com> <2016951A-BF16-4780-85FF-0B77E91FBBD4@yahoo.com> To: freebsd-arm X-Mailer: Apple Mail (2.3445.104.15) X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Rspamd-Queue-Id: 4M1F2D5THgz3fs1 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 > Am 07.08.2022 um 19:16 schrieb Mark Millard : >=20 >> On 2022-Aug-7, at 14:51, Dr. Rolf Jansen = wrote: >>=20 >>> Am 07.08.2022 um 16:50 schrieb Mark Millard : >>>=20 >>> On 2022-Aug-7, at 12:32, Glen Barber wrote: >>>=20 >>>> Correct, it was set to =E2=80=9C0=E2=80=9D for these builds. >>>>=20 >>>> I honestly do not have any idea where the problems you are seeing = are creeping in. >>>>=20 >>>> Should it be set back to =E2=80=9C1=E2=80=9D? I=E2=80=99m not sure = how to proceed otherwise. >>>=20 >>> My guess is that if the release/tools/arm.subr line: >>>=20 >>> chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k = ${mddev}s2 >>>=20 >>> was instead (note the added -b use): >>>=20 >>> chroot ${CHROOTDIR} gpart add -t freebsd-ufs -b 64k -a = 64k ${mddev}s2 >>>=20 >>> then the line: >>>=20 >>> chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a >>>=20 >>> would work as expected and things would still be aligned: >>> no aliasing of BSD vs. freebsd-ufs. (In part this is by >>> prior steps already having achieved alignment of BSD.) >>=20 >> =46rom a strict mathematical stand point of view, -a is not necessary = when using -b with an aligned value. >=20 > "-a" controls more than the start offset: also the size. >=20 > QUOTE > -a alignment If specified, then the gpart utility tries = to > align start offset and partition size to = be > multiple of alignment value. > END QUOTE >=20 > I expect your statement would at most apply to the start offset, not = to > everything "-a" does. >=20 >> Personally I don=E2=80=99t use the -a option of gpart anymore since = it started to do funny magics in front of face. If I remember correct, = gpart of the FreeBSD 9.x-RELEASES was still OK (or was it 8?). Nowadays, = I align all my storage media by employing -b with a reasonable value. >>=20 >=20 > I've no clue of the specifics that you are referencing and so can not = check. It started at unexpected offsets and then left unexpected space at the = end - sorry, I don=E2=80=99t use -a anymore for years, and I don=E2=80=99t= remember the very details.=20 That said, why then would we use -b in addition to -a, if -a would show = the expected behaviour on its own. That is because either -a adds some = "funny magic" to the logic, that is stated in the man file, or there is = a bug in gpart. Anyway, using -a and -b together bears the danger of the equation being = overestimated, namely in the case base is not a multiple (incl. 1) of = alignment. Although, that is not the case with your suggestion. -b 64k = -a 64k is OK. Finally, I still wonder what might be the technical reason for aligning = the size. Best regards Rolf=