From nobody Sun Aug 07 19:32:35 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 4M18cQ3qqVz4Ymfs; Sun, 7 Aug 2022 19:32:38 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail0.glenbarber.us", Issuer "Gandi Standard SSL CA 2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M18cQ2p3wz48jC; Sun, 7 Aug 2022 19:32:38 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from smtpclient.apple (70.15.90.15.res-cmts.sewb.ptd.net [70.15.90.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id D695F56052; Sun, 7 Aug 2022 19:32:36 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 mail0.glenbarber.us D695F56052 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 (1.0) 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: Glen Barber In-Reply-To: Date: Sun, 7 Aug 2022 15:32:35 -0400 Cc: Warner Losh , "Rodney W. Grimes" , Ed Maste , FreeBSD Hackers , freebsd-arm Message-Id: References: To: Mark Millard X-Mailer: iPhone Mail (19G71) X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Rspamd-Queue-Id: 4M18cQ2p3wz48jC 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 Correct, it was set to =E2=80=9C0=E2=80=9D for these builds. I honestly do not have any idea where the problems you are seeing are creepi= ng in. Should it be set back to =E2=80=9C1=E2=80=9D? I=E2=80=99m not sure how to p= roceed otherwise. Glen Sent from my phone. Please excuse my brevity and/or typos. > On Aug 7, 2022, at 12:10 AM, Mark Millard wrote: >=20 > =EF=BB=BFThe oddities look like indicated below. >=20 > # mdconfig -u md1 -f FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220805-e24c5= c60d72-257129.img > # gpart show > . . . >=20 > =3D> 63 10485697 md1 MBR (5.0G) > 63 1985 - free - (993K) > 2048 102400 1 fat32lba [active] (50M) > 104448 10381312 2 freebsd (5.0G) >=20 > =3D> 0 10381312 md1s2 BSD (5.0G) > 0 10381312 1 freebsd-ufs (5.0G) >=20 > =3D> 0 10381312 ufsid/62ed01f3345560d8 BSD (5.0G) > 0 10381312 1 freebsd-ufs (5.0G) >=20 > =3D> 0 10381312 ufs/rootfs BSD (5.0G) > 0 10381312 1 freebsd-ufs (5.0G) >=20 > So: ufs/rootfs apparently identifies the BSD instead of the > freebsd-ufs . Same for the ufsid/* . This leads to: >=20 > # gpart show -p=20 > . . . >=20 > =3D> 63 10485697 md1 MBR (5.0G) > 63 1985 - free - (993K) > 2048 102400 md1s1 fat32lba [active] (50M) > 104448 10381312 md1s2 freebsd (5.0G) >=20 > =3D> 0 10381312 md1s2 BSD (5.0G) > 0 10381312 md1s2a freebsd-ufs (5.0G) >=20 > =3D> 0 10381312 ufsid/62ed01f3345560d8 BSD (5.0G) > 0 10381312 ufsid/62ed01f3345560d8a freebsd-ufs (5.0G) >=20 > =3D> 0 10381312 ufs/rootfs BSD (5.0G) > 0 10381312 ufs/rootfsa freebsd-ufs (5.0G) >=20 > freebsd-ufs has the unexpected label: ufs/rootfsa >=20 > # ls -Tld /dev/ufs/* > crw-r----- 1 root operator 0x6c Aug 6 20:19:58 2022 /dev/ufs/rootfs > crw-r----- 1 root operator 0x6e Aug 6 20:19:58 2022 /dev/ufs/rootfsa >=20 > Things were actually set up for ufs/rootfs naming as the > identification of the freebsd-ufs content, per the > release/tools/arm.subr commands ( from last month's > main-n256584-5bc926af9fd1 ): >=20 > if [ "${PART_SCHEME}" =3D "MBR" ]; then > chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s ${FAT_SIZ= E} ${mddev} > chroot ${CHROOTDIR} gpart set -a active -i 1 ${mddev} > chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F ${FAT_TYPE}= /dev/${mddev}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} newfs -U -L rootfs /dev/${mddev}s2a > fi >=20 > Note that the newfs command references /dev/${mddev}s2a instead > of /dev/${mddev}s2 but the rootfs label ends up referencing > /dev/${mddev}s2 . >=20 > Is having "0 10381312" for the md*s2 and for the md*s2a a > fundamental problem? Does freebsd-ufs ( a.k.a. md*s2a ) need > to be moved to a different (non-zero) offset inside BSD? >=20 > Or is this a different kind of bug? >=20 > I'll not repeat the kinds of explorations that I reported last > week unless someone wants to request something. >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com >=20