From nobody Sun Aug 07 19:50:21 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 4M190z2mt7z4Ypr5 for ; Sun, 7 Aug 2022 19:50:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4M190x71sbz3D9d for ; Sun, 7 Aug 2022 19:50:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659901823; bh=ms5YE/uSFH+aKxrPdovtf3vsgMPHoVwUDElZ79Qhfbw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=S+FKvDyQsLawrAXVH1sjM3NfmEqIaaXqzB9DMbYxA3ee8AJ0wj/DgB/S18ECfkwk+Ao2diS6sy0t1u1bUjA7WPvRLFD7CZzNplzwfth75YXKXJFsqH58onFfx8FE3B16kL7O5kqI125ayw6FpkKptuTVGkR086YjUNQ6bHCzn8GHAy9f6UZi/aGMzFTWb2R5VVuL0tzOFjX6kBgsWfH1mMBKKFJ9zNIVI70WLsE66XhiZMBSeB8pCi8eUksi5zckIbyj7Q8vAZbnm/CJXR5h1J6dsRIO9y09htsFc0QwQfNNJFCkYZ4sgoOAQEYEG1sPdF3wzk1UoSCZ+wWmT3BPxQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659901823; bh=3QxCHxTyPL3MLHpREC+T3GQ98nYyJvUanGkiHP7w2N4=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=F7+nbVC3HCzI7OC14VVhDjAxx38As6gjobOfUpwTNap41leZjZyd4wQijb3ljXBQARKnHotUqVa+gmgT9N8tRVnqnmRjE+QvGPf1t0ucZMWNRlMC9SEyywWpDAlMzf4dDUZ9a2AfRyCBJIbH27fNOcJ523eCan3eBeXp6uBo0GF/9HqdXPF+DJwKtpl9762tJHbXGwSgEbzlvWWlQdqVipV6TYodYCjMolLHmKCaPdxUCYMmx+1oWXS71uYB3i6zKGb/VcXREaCK9r4xQasCP39DtDYuByWQ0qaMIZ4dSRsWht9ssPHu1GAS9evVQtbh4Agnn8rcLvBDoEihktxv8Q== X-YMail-OSG: ZzC3IsEVM1l7CpyWcLEgIlYIs2FDPxGUJkcQqF1YB6U5lz9yHkWqKburQyZz4O7 iJCkN_QuOwr_ePfZPHnBfcKqdwkVRxo4TqZVeIYBJMtV16YAHv3j3QW6U9GnNC.7nlRYjK6eBOfC HRtIXRYPHJMQSXsC9fy7nN3OcFgWRKzW0Rze785B51Ggt1alzTLbM5VaxYh3.PpVrucKMak4q4AA H2zFetwc2nTU2jVuK4ccD7HSEG7QHztMK9kQIgQZTxUhP3qESKncx6pSvdHQaVmS6bIYdO7y5wRE Ll56HM4mX5EEjX_2E9E2N.ZAuqTb33X00LV_6LVYm2r9vfVUFGAwOBNRWXBBVy_OSOFp0H8My_cb BqASdRV.tqVaZRAlydMlI8JX88rlIN1YVUemuuxyqnDS7rAM7JipydFwEpev6DmJ8TVbndU_J7KF pzME_Y7RMKkEpCd3uiyiobvSOPUVbV9u4hOEA0dkkX3lu1ct_lEX9daz0OV5SOakMJlFPKtSTbY9 peL3Ma2xEdqOJSVPx.H_mjUzhGTgZkuMoH2zWhCE_f9GOb3KXvAJEQnpj8Zo6CsZJ4YG_f9mI_Wo 3U9kPCdrJPQPPiKvKBQM3YKDc5sUKrMtMD9htRoloEQQG3TkvO2gSc4hdKLe94By3fteTlxCrU6h _5SERDQc9ksU1jBypLjAienzVJcfxyVLP39z7FUgdfwrRJUDDNaS05A4gKN8TqwMR3O077zJTsWa j7RXdDq3uhC5nsWpO8AWUQtHorMswVoAvZaKum4jT4z_WyQILdssHe7jks9g0T9UtoMeEirRanVy E7hMmRxTI3rXjNcr3TsUrWtVXxLuA5fXP8HS6e7B2MPFcV.p9IPmAf5tLHwsRQJO4RoXfbnqogXq 2LWUYr1dTeVLEjYIlFydKEbVPu3.x3RpBDJrdtHEJijsXwRexrVxvrkLpMQeqUWT6Rb6SaICaVqP VuBNXGicY8ETQC5Z79Nlz0XAfXWC0ZyTGme4KE9GawcBCYUwVRwx5ovQVOJgvAQSLX75xqsk5zLq w4FGyRQsmLiKcZMROKubpHBatvDOhGsoMViPOmnhzG2mUc_k2PUdR9QR0lg6GjWIr2o2gqXhslgc hbTvk27tlluKJjA7XYw4NOqqZSivIhpFIpgTdbXgpwFSvGVivRrZLuJ9PYEJ3pKcj1fHV3S5VTD2 SpbfW2epN9yMVwY0_0QsBjEktLs6bp0xPxozz3hLJ1Vgc6zjUZoeiB7DE03LydIvKZn.3aAI11r3 kCnskgGFFpFm0IT0FkD.1Ye66tpuJOoeUYvLHS2Byc3F1GRZmfubHD3ZU5bb4_U.9mFuguXye8UT Ph9QO4tdSKOVuwQurFC2NH6dxqmYfgnb9jPQQg9Yete7T29vKlS1m6b.sEYhydCbSstN2WLd1M4Z Xl_bR5c_z2Xr.SoSnrJ8SJm4KfuDCPzO.8aPpTVahvOJvgLc4Se0tafk0xrZV1ORg7kIqFrJnDju EqkF0TXaq55PpnsaKD1z4dqKsvJmG7rAwZPuP_nYiKewHcXMa7J6h66FrE4LL7lshuiCZNYbjjcQ riGnRyJtaGPXNXaDMbJ6gakxpobH5CvhlYW2nWD_1j0hGcn8LNVqb7ZLh.WYY0.2F52pvA4jO1xo 965iwcXHH_DqUvp.jZfsHwmAsdFH12Xv6Pw5PJG.cGD9SbZDy1r5L5vsLArF_uxXmFdpGwZoRyce vR_bTjzRPLIZZypQ3crBG_JVjxOGbJ1aDDj9RxJH06R5RuzdJsfunYBtRMBT8mf5Zx4OwEdwCj9H ne2wkBgHjtsanbnvzc8U04qyGU6Zw8Ma2uP0RLKDjBlT_j6B.OtmoqiTDHaEA4mAPS5TmqsEW2uU jtKm_4dIBB5X1ky8NPWmvLWKXww7vTd9mTMtxZSQ7SJeRM91IAtey4hbRv7c9A0oYUcBGTLyJrZD 0Ik_PvGHSPqj0HPvQ97n88l54lezgopnDvQC2AKNchz9cSBRumCEGhFMqS7a1fmfuCMIddtwFdTc pGN15U61MejvoLAZndfGjbBuneTSsR8JQSiuek8Y9srIrk6yVf7ZXYcfkOZrBg0wtWASGZHEun35 awN6neHJHSZv_kqfmYG3O0svB6NV5cXJkwwweEIMmX6c5khkOAN9ASb5SHavtRcI7JH1t6UgcWPO qdQC.._oC4Gn54BYODxymZCKOjzldJRGvc2pNDohfc7q_AFc23V0dq_cTBauKut8VJFr3FIYu6NK rS3WPiS8xJfNv0v1eYBDAqI6HoZI.YYMgs8OGLyuBwfvOEOXy6NLF_i_oQgM7ObvDskZOT2uyCid WLt9vNYcS X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sun, 7 Aug 2022 19:50:23 +0000 Received: by hermes--production-gq1-686964ccb6-fq25x (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4960ff856c766e649e2ea3f0ff4987e8; Sun, 07 Aug 2022 19:50:22 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) 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: Mark Millard In-Reply-To: Date: Sun, 7 Aug 2022 12:50:21 -0700 Cc: Warner Losh , "Rodney W. Grimes" , Ed Maste , FreeBSD Hackers , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com> References: To: Glen Barber X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4M190x71sbz3D9d X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=S+FKvDyQ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.80 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.995]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_MEDIUM(-0.30)[-0.304]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.30:from]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_FIVE(0.00)[6]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_DN_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On 2022-Aug-7, at 12:32, Glen Barber wrote: > 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. My guess is that if the release/tools/arm.subr line: chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k = ${mddev}s2 was instead (note the added -b use): chroot ${CHROOTDIR} gpart add -t freebsd-ufs -b 64k -a 64k = ${mddev}s2 then the line: chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a 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.) But I do not know how to classify doing so: Work around? Known required-procedure for -L rootfs to correctly identify the the freebsd-ufs /dev/${mddev}s2a ? Absent better information from folks that know more, I'd suggest trying such an adjusted release/tools/arm.subr next week, leaving kern.geom.part.mbr.enforce_chs=3D0 in place, if such an experiment can be reasonable. > Glen > Sent from my phone. > Please excuse my brevity and/or typos. >=20 >> 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-e24c5c60d72-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_SIZE} ${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