From nobody Sat Aug 13 00:30:34 2022 X-Original-To: freebsd-hackers@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 4M4M016SJdz4Z4H5; Sat, 13 Aug 2022 00:30:41 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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 (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M4M0162ctz3G4c; Sat, 13 Aug 2022 00:30:41 +0000 (UTC) (envelope-from gjb@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660350641; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VINIE4Iq4ABuqbCN8aiWS+ZoRa3oSpND1AjjwK8jSko=; b=kr8fFEnNjxx9nydVabQ2Lq7bp0N6wP7cFoF0bVV029hH6fTMMK+CPc+Mcdfts21FaLImaT 4MrDf0UHOjzqROT2e0HAp3+mE3jlDCbp0oI8S4/z+qRWjfNEGvjJwDkt+yuO/gW5IwI3Ra wuG1CdbbpCbK5Dm6DARYVSfCtiisOTGcyAJ03GGGqiexxRCvl1R6q6RHFVoOq0pqduqOWL +iBLS0FtXDH0xJQ+BiprQRarommmKUg+wCo/7LGOpnaOnWCNGn2lkhi0SINwGRSyAtvZSe yuubX+2klQfwTWU4RWUY9Y0C6Bs5eMsXZyeZdeZOW3AedmPqmhBrRHQjWIH4Og== Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 3B610610; Sat, 13 Aug 2022 00:30:41 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Sat, 13 Aug 2022 00:30:34 +0000 From: Glen Barber To: Mark Millard Cc: Ed Maste , Warner Losh , "Rodney W. Grimes" , FreeBSD Hackers , freebsd-arm , "Dr. Rolf Jansen" Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use Message-ID: <20220813003034.GP30607@FreeBSD.org> References: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com> <0E0083BD-A749-4112-8FDA-62326EA95F8A@freebsd.org> <20220809181513.GG30607@FreeBSD.org> <944D4959-780A-4A45-B8F7-9F3E00741E48@yahoo.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Mua2edsUln3Jw4OC" Content-Disposition: inline In-Reply-To: <944D4959-780A-4A45-B8F7-9F3E00741E48@yahoo.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660350641; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VINIE4Iq4ABuqbCN8aiWS+ZoRa3oSpND1AjjwK8jSko=; b=uwvR9dRQfCZd6KvrybDxpMt6RB0fPP44V+454+PXWuOmabfYlOzbJfs+bOlEU1kxfXN/Me H04YHijNq+z3A7fNeAuncI0hbwFJU3VgIdzCLu7mezCu4/mUFABgDHDAobmN0qNRG8INvJ OQczwEvSqEHwyB4PRaEfF4ntGkW2h5MKbehqrrbHX0caPneQ6t0qOku/EsJj2dDzEO3qaA xMwEwdi5Sz359GWModYda/LzTT02BZRNpZzboIQS6Q48k2a8mNJcNA4kK2/yensmwwacA6 LNbVkIgrPcArA8PZ83+6Aia64FUpHIZQ+al9MWl3+oppTBfcYZo8D7JSVXI+4w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660350641; a=rsa-sha256; cv=none; b=b9hIhMhhzw4+2tbqD3XUJIC7YKMy0Cpj4t4h+kIVBjx5o5SWal2jcQtdAJxmdOBNaeBsRy 7yGVH2IQmn6MRbee3WBFso4DapV3fiMLF5rHFZOifkTLI0KcXrwxObI1n3cJoXbNRPws6t uSlhzR9W447XyHuQGGmWmer11lhPp9ijSEIyARQmyVVPjoktmE1mbv22AKe4gmr/00jBUG SkSD2+0gUqPxCpu6vILIUtSpJWbVAJngo7DlhHVfzUq0QAM15js7xVFlPxZk2y8FAjuT/H /zT/Llo6I0VyFfSyOLMr8ORR3wA64SBWXqmWgP7+e9Zc/vUCnt5g7CX6PfVWiw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Mua2edsUln3Jw4OC Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 12, 2022 at 05:16:12PM -0700, Mark Millard wrote: > On 2022-Aug-9, at 11:55, Mark Millard wrote: >=20 > > On 2022-Aug-9, at 11:15, Glen Barber wrote: > >=20 > >> On Tue, Aug 09, 2022 at 02:06:14PM -0400, Ed Maste wrote: > >>> On Sun, 7 Aug 2022 at 18:43, Glen Barber wrote: > >>>>=20 > >>>> Will do. I=E2=80=99ll commit the suggested change to main tomorrow. > >>>>=20 > >>>> Thank you for your vigilant investigation. > >>>=20 > >>> Shall I commit the enforce_chs check now? > >>> --- > >>> commit 6ee7d69e6b526f35789b23ba570025f1c3b39c1a > >>> Author: Ed Maste > >>> Date: Tue Jul 19 16:47:49 2022 -0400 > >>>=20 > >>> release: ensure enforce_chs sysctl is 0 > >>>=20 > >>> We do not want CHS-based alignment for VM or SD card release images. > >>>=20 > >>> Sponsored by: The FreeBSD Foundation > >>>=20 > >>> diff --git a/release/tools/arm.subr b/release/tools/arm.subr > >>> index 6e4ae731a0b9..01c5303cd4e1 100644 > >>> --- a/release/tools/arm.subr > >>> +++ b/release/tools/arm.subr > >>> @@ -62,6 +62,10 @@ umount_loop() { > >>> } > >>>=20 > >>> arm_create_disk() { > >>> + if [ $(sysctl -n kern.geom.part.mbr.enforce_chs) !=3D 0 ]; th= en > >>> + return 1 > >>> + fi > >>> + > >>> # Create the target raw file and temporary work directory. > >>> chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev} > >>> if [ "${PART_SCHEME}" =3D "GPT" ]; then > >>>=20 > >>=20 > >> Good question. Do we still want to ensure it is set to '0'? I'm a bit > >> confused from the back-and-forth on the original thread. > >>=20 > >> If we do want to ensure it is set to '0', yes, please go ahead. > >>=20 > >=20 > > Hopefully this week's experiment with explicitly avoiding BSD > > and freebsd-ufs having the same offset inside BSD (avoiding > > both offsets being zero) will allow the UFS labeling to work > > right: freebsd-ufs being tied to a unique offset inside BSD. > >=20 > > I really doubt that using kern.geom.part.mbr.enforce_chs=3D1 to > > cause the offsets to be different is reasonable, despite that > > it happens to make them distinct: the freebsd-ufs offset is > > better controlled explicitly elsewhere. > >=20 >=20 > The experiment with this week's snapshot is working just fine. > It is based on the update: >=20 > QUOTE > The branch main has been updated by gjb: >=20 > URL: https://cgit.FreeBSD.org/src/commit/?id=3D45add40717c24ef0b5418664fa= e1718b15a0422b >=20 > commit 45add40717c24ef0b5418664fae1718b15a0422b > Author: Glen Barber > AuthorDate: 2022-08-08 14:59:29 +0000 > Commit: Glen Barber > CommitDate: 2022-08-08 14:59:29 +0000 >=20 > release: fix alignment for arm SoCs > =20 > MFC after: 3 days > Submitted by: Mark Millard > Sponsored by: Rubicon Communications, LLC ("Netgate") > --- > release/tools/arm.subr | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/release/tools/arm.subr b/release/tools/arm.subr > index 3dea17339958..25d4640cc26b 100644 > --- a/release/tools/arm.subr > +++ b/release/tools/arm.subr > @@ -77,7 +77,7 @@ arm_create_disk() { > chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F ${FAT_TYPE} /dev/${mdd= ev}s1 > chroot ${CHROOTDIR} gpart add -t freebsd ${mddev} > chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2 > - chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k ${mddev}s2 > + chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k -b 64k ${mddev}s2 > chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a > fi > END QUOTE >=20 > This is unlike when the "-b 64k" was not present. This > includes rebooting after the initial boot, unlike before. > This is for dd'ing to USB3 NVMe SSD media and testing, > for both of: >=20 > FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220812-6a70a0c8bfa-257314.img > FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220812-eb2a9b78586-252107.img >=20 > (The -b use implicitly also changed the size of the freebsd-ufs > slice, making it smaller.) For the media growfs is involved in > the initial boot. >=20 > glabel list now shows ufs/rootfs bound to da0s2a and does not > show a ufs/rootfsa at all. There is no binding to da0s2 (BSD) > shown. >=20 > # glabel list > Geom name: da0s1 > Providers: > 1. Name: msdosfs/MSDOSBOOT > Mediasize: 52428800 (50M) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 1048576 > Mode: r1w1e1 > secoffset: 0 > offset: 0 > seclength: 102400 > length: 52428800 > index: 0 > Consumers: > 1. Name: da0s1 > Mediasize: 52428800 (50M) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 1048576 > Mode: r1w1e2 >=20 > Geom name: da0s2a > Providers: > 1. Name: ufs/rootfs > Mediasize: 240003866624 (224G) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 53542912 > Mode: r1w1e1 > secoffset: 0 > offset: 0 > seclength: 468757552 > length: 240003866624 > index: 0 > Consumers: > 1. Name: da0s2a > Mediasize: 240003866624 (224G) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 53542912 > Mode: r1w1e2 >=20 > # gpart show -p > =3D> 63 468862065 da0 MBR (224G) > 63 1985 - free - (993K) > 2048 102400 da0s1 fat32lba [active] (50M) > 104448 468757680 da0s2 freebsd (224G) >=20 > =3D> 0 468757680 da0s2 BSD (224G) > 0 128 - free - (64K) > 128 468757552 da0s2a freebsd-ufs (224G) >=20 > A difference in behavior is that "gpart show" does not > report the ufs/rootfs labeling. For all I know, this > could be expected. glabel does show ufs/rootfs . >=20 > I do not know what would happen if only the size had > been made smaller but the starting offset had been left > at 0. >=20 > But the evidence from the "without -b" and "with -b" > testing is that having starting offset 0 in BSD > and the same size as BSD can be a problem for the > freebsd-ufs slice as processed by the initial boot, > at least when ufs labeling is in use (here ufs/rootfs). >=20 > So far, this week's snapshots look good to me for the > issue having been avoided but ending up better aligned > overall than when kern.geom.part.mbr.enforce_chs=3D1 was > in use. >=20 > If a larger alignment is needed at some point for > freebsd-ufs, adjusting the pair of gpart add arguments > "-a 64k -b 64k" should deal with it. >=20 >=20 > Notes: >=20 > The USB3 NNVMe SSD based testing was with a 8GiByte > RPi4B and so does have the addition of: >=20 > # > # Local addition that avoids USB3 SSD boot failures that look like:=20 > # uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT=20 > # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port = ?=20 > initial_turbo=3D60=20 >=20 > in the config.txt file that the RPi* firmware uses. > (It is for a separate issue --and FreeBSD does not > have such in place by default at this time.) >=20 Mark, Thank you very much for the detailed information, and of course for reporting the problem, and testing variations of the correct behavior. Glen --Mua2edsUln3Jw4OC Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmL28KUACgkQAxRYpUeP 4pO27g//dXjEFscvG6vXKerHSwgSjTNT09+LzwL3ENMTvf4NyB68K3Eje5MiWeCR FSwvLaIXK8LH7oLdTasstHe5dP35ICBAJANJS23CfQdoEDS3T/7cnVd5vbAOUSyl mlovvgQPoWZgRLHIJ0THYCIC+S3rK7YF0lW1Nk5vMrK1hQpYh5s9dFDJ1k8bOQLL ek5q2Bo3E8h0LhtbgvDGSZLlh7BMBzWxzPuoCBvws2Ga3PKLL7Jb5uutGqeHL2bS 4CZrJQDalFs/+55R0D1qQyMakTnQ43llBgy7XggLKitMpXVoG2bX12LLQB1GtnU/ zciF/nCD0BTY1Cyy8kuKz4/U1FjpBVYfdL20BOLE3XM7Yo4wzDj5BgXbHL7vLrJN CphXPsmHnRFLETfxVA64QbTRlPpAj/fc3g3Eav/pfau3ubjmvCk9i9QrokSG+OWl 9BLu0UwPaZZfir8jREahV+Pd0a4G3zy8HGsHyq7KTqqm/mzGL2Qx5eKBUAa8OywG jbrJiF72PCU+83y39uSYZthVQx8t3A5+r4V/27Y3Em5pvYEEMELRfF3907hPErmP 0OPxo6yFs7FAkLJmZeWfa+brttfRfh2HeQx6U3kh2cF7/cRFKWxu3qORI5tCr/jm B+wZj6mJQGZ3pnUy8Pr+8LvFA75A+TvFdsOZSWj8H93JB1+O8RU= =KC81 -----END PGP SIGNATURE----- --Mua2edsUln3Jw4OC--