From nobody Sun Aug 07 23:06:36 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 4M1FMZ0KGVz4Y5MD for ; Sun, 7 Aug 2022 23:06:50 +0000 (UTC) (envelope-from freebsd-rj@cyclaero.com) Received: from mo4-p01-ob.smtp.rzone.de (mo4-p01-ob.smtp.rzone.de [81.169.146.167]) (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 4M1FMX6yrzz3hJ2; Sun, 7 Aug 2022 23:06:48 +0000 (UTC) (envelope-from freebsd-rj@cyclaero.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1659913601; 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=3Itu8SpEDOKHTgBfS1L2LWEA3ei3kXvMwdRl13+jgZ8=; b=PFu1mspn99D3VlLAGLg0wKkaFmTCWtQLJ4wCbyiv6MYb5Xp6AssjoEtb14fBm6hanh xPGB6Rt7IqXMd+5RMOSAB5hX/Jv47iceqh30LIS4Pvi/jCAAlvUTMPj/B0cgw+YewJx0 1Sd7JUblonznODdyauZvK1rO/GvfHIueBMfXRKleX1sIGNQ4OvAaXOFRaLXAK+Nd6b9F v+mIq0GO/VSkeBYUVJjBsltuQCJWucja1LxEcic/VwlRVS0D9aQkWuLFZqMgb9yd4gZF a2524FQF68BgtBZyxz5ct89EItlOOIESqwlQcsQ20CDv7RxU7Zs+u2NGfeEgrFHXQa0C tfAQ== 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 q0201fy77N6ftiL (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Mon, 8 Aug 2022 01:06:41 +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 A471C63A78; Mon, 8 Aug 2022 01:06:39 +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: <6483BD0C-AFDF-443D-BEA2-9F599C9B8C07@cyclaero.com> Date: Sun, 7 Aug 2022 20:06:36 -0300 Cc: Glen Barber , Warner Losh , "Rodney W. Grimes" , Ed Maste , Mark Millard Content-Transfer-Encoding: quoted-printable Message-Id: <71BFB117-151A-4970-A9B3-9BCD14336A64@cyclaero.com> References: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com> <99DC4046-AB8D-4D10-9475-94A8DC89DCFA@cyclaero.com> <2016951A-BF16-4780-85FF-0B77E91FBBD4@yahoo.com> <6483BD0C-AFDF-443D-BEA2-9F599C9B8C07@cyclaero.com> To: freebsd-arm X-Mailer: Apple Mail (2.3445.104.15) X-Rspamd-Queue-Id: 4M1FMX6yrzz3hJ2 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cyclaero.com header.s=strato-dkim-0002 header.b=PFu1mspn; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-rj@cyclaero.com designates 81.169.146.167 as permitted sender) smtp.mailfrom=freebsd-rj@cyclaero.com X-Spamd-Result: default: False [-2.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_NAME_HAS_TITLE(1.00)[dr]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:81.169.146.128/25]; R_DKIM_ALLOW(-0.20)[cyclaero.com:s=strato-dkim-0002]; RCVD_IN_DNSWL_LOW(-0.10)[81.169.146.167:from]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; FREEMAIL_CC(0.00)[freebsd.org,bsdimp.com,gndrsh.dnsmgr.net,yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:6724, ipnet:81.169.144.0/22, country:DE]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[cyclaero.com:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; DMARC_NA(0.00)[cyclaero.com]; RCVD_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > Am 07.08.2022 um 19:51 schrieb Dr. Rolf Jansen = : >=20 >> 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. >=20 > 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 >=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. >=20 > 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. >=20 > Finally, I still wonder what might be the technical reason for = aligning the size. PS: Now I am in nit picking mode - "... the gpart utility tries to ..." =20 Don=E2=80=99t try it, do it! Otherwise, hasta la vista, baby! Hlv,b is meant to the -a option, and not personally.