Date: Sat, 13 Aug 2022 00:30:34 +0000 From: Glen Barber <gjb@freebsd.org> To: Mark Millard <marklmi@yahoo.com> Cc: Ed Maste <emaste@freebsd.org>, Warner Losh <imp@bsdimp.com>, "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org>, "Dr. Rolf Jansen" <freebsd-rj@cyclaero.com> 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> In-Reply-To: <944D4959-780A-4A45-B8F7-9F3E00741E48@yahoo.com> References: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com> <0E0083BD-A749-4112-8FDA-62326EA95F8A@freebsd.org> <CAPyFy2AfGxgND-2KaPUy8RnS6MYaxQBnGDPBkz9vDhLekNN%2BbQ@mail.gmail.com> <20220809181513.GG30607@FreeBSD.org> <B1F1DA0E-128A-4778-8EF1-AD8F8F9102C5@yahoo.com> <944D4959-780A-4A45-B8F7-9F3E00741E48@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <marklmi@yahoo.com> wrote:
>=20
> > On 2022-Aug-9, at 11:15, Glen Barber <gjb@FreeBSD.org> 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 <gjb@freebsd.org> 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 <emaste@FreeBSD.org>
> >>> 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 <gjb@FreeBSD.org>
> AuthorDate: 2022-08-08 14:59:29 +0000
> Commit: Glen Barber <gjb@FreeBSD.org>
> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220813003034.GP30607>