From nobody Tue Jun 21 19:55:22 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 6CD118772DD for ; Tue, 21 Jun 2022 19:55:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (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 4LSHLb1P5zz4kq3 for ; Tue, 21 Jun 2022 19:55:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1655841327; bh=2P1m9pMTtw144KSa8xaOzHCZOxOhyqnUEIRh9ON2fMM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=WrFfP2AZxvE44mJwBhDDjG0nZDrG5UTTYxHX/bt3LGuyX1lkzg9RmrJAccCHMr+UI7LQObynRLo7xmbXZL9gkkQUiFDoIgfaxucJN4AKDHjRPVhBGqBHULoSjvz+VRibLU+ZWRyiGG1Av89j/ixDU2afOxnZ6GHMkSruyr/VgFpLLACBPmft6tkAWX22KiiNXPSYHNj9DW/MWqZGjtvMTdRFTlC1PRypQfD45wNtiCMYdIymL5y4C7jhJzGKQX3Zu9fZyzcSR9q1tUj/sKSnbrET65Q4MWJlDm3I4/OwPGqa1MLuI7oR2LVui9hkDhfmI7BOR7usMQNc7v1A0ndPrQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1655841327; bh=02jbhM0fbwA8HvLWI5yll8oQp6UTZst7l90pNC3qkQN=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZAlY+F9tyAB18r96BYn5spNxXqKqVqQYCdQmja3MQaHDwXeH1x3bPDXQFAOXH/gMojoPb0B4YKjCwF+AtxYyjjho6D3KMFFu0Le2QdaowdvoWlLXvO10eSi+pt+6JfDbYqTx5s1AZjLHYhiN6J97yxGdHAi14wVZ28rT+eEHa9DseDDRN7Xm2nS83W0Q0ynZE+Sgkm/svRUmPnMBziaf4CdszaNZan5nKU5eeoWfKclThF5GQAHwW0bFXF1dQhNtp8SAS1o0MsB7jXsbSZN/KghTD3lA16tNrT+dZn5QTROL8OgcS42x9SILiXdS6+b0NVKWoXS14s5g0lw2SZQ63Q== X-YMail-OSG: VskcXmkVM1lL.MKrJfk2kUrRiOh1cpSItoqqUefG.y5TlQHcHYf8zJ47x7qFe5O KY7rGFxvB8Bn5B8ytTlflMlCYKNdAI.7KqRkOYmhx3v0fdNLDMnKEEuzUteIVs25w4fX_EQvu.Dd rZO1koGY.3iK3a9VXCYavuAjXXnGXx31_Z8Ppm5xUx6tG8M3FdcYYfPE3NiUOUQ8bOWEUagrXZ38 o04lZ0x80wd0MZQSzhHYxcqSLtiREThnIeiVNeb06ZpkCn8y4HGp5P1zxKbwfswi4tbSkCCsvrG7 Kic1sV43MZl6dRLAp7vNJi_8dugjFlIjvPz.28fp.QO6SFTZAWc2MzKLk8KPbRQBxpK.KiWyjs3I h3chTh9fyGHwpU2VmSG_1wP9WYK7vWIA021Cq8i4qd1a9w6YRWLYmkJFoc9KfUu0voBG82_46io5 st239fUilvvcrjaYKM9Luzp4rxAmcpO3IscdsCNukw1VRBRFetvOAyGyoLb69vjL_nkyVzVZvevl MBYZIL4h.JzoOKzqgc5p2BtzjhNAFhpQGBD_SbZJU1gV9GXc41ERejMSc6kvt1YH_3zl287jR9S6 n6s2BISQZTFApZkhGt090X3g5FbYGNnnD1EEdJxfmjW_S3Tzhb07GxwJup9w4.0sLYUqsSEecshx iAFtiRzElj3FHP0q.uezI4r2VGnFDJ8yyvwWm2m2kjueuru578.F0uZntNqA.c8G76HD3140A68s t9YNan3blv8dlu4.mJHkMnpALmNuQApkBUGVJLD28tsLVAJmk.LzzYd2jx0OdB46PqRHS4gOiHfq c4yRNBP5KxRWipDLfQEDh1Sqq5dlljNDGIeGdvjpwk9VvDI9_X4qdMiX9uLNCc60BreynLcEoMB8 WVTtjRWZU1G4qm2B3wzF0T.J5GnwQcvC5GpOuzzLw.1hV2SuPId79F31pVdJ6eSMQdQtu9aL2h2. LyZUYp3yGF.OPMzjcBkMHlCBF0ztSZJgmN3guTgZ0gNtkl7FQqX1mMxObGAUUxNNTtyhKSX.eI4U pAWBp_kUGr2I4l.avXVZwMg6d5KRCqYZHYYbnjlLKPjUGVtrsbUkI_diVgOmfqXc7uy5mqrYNghp vs1aJkScvC5WSpdmio7okePjxkt2p.cuC3dIbAChAcfY0cmLocgJnihzjg6PuT_kC9aKo4pqoSeY _9vqY7iMiszfmgFeQFgVlrl1o87uehttdCuu3A2l7RFV21WCohLuIv8x70YIRBD93ywGJH3_yJpe V3Oine2iZpGScY4VEfmz.6A02q5rf59.vDCKC0QQBrEraJRZeWNVbJo82NXXa46cu3Gk1dssnrVU g_K.agIydEvPDF0lnUYC0Ze1APa15Z3Mf9GFLWNepkzbUndb.pd2mG2ZzKwYTvKPuxJQ3hdU9ZpA 4oIY3jAzfJQLU2loUU4GR3Ziln2Yw4uajBvFdtdi2LJAY_kBt.JFKQuzC2wieXsrBxzc8wMuf5YY qth40zZN4umZNIs1qiCcvMWx9IaVyV6v9oDXzUzyIINFHLJBJ0TesuubRcoLpq6bMGng.ZiAJ5bK TahGPDCdE3B1C9wdEz1lHl7ER_jsruo4uASiOJz3_okXOs6eMDknZhFAEtVlpOgmqC6LXqZhAGiu kGNrZ27jqJr2M.hx9d57Wf4GtD0zXbMnlm09_h1zAjUalOmTCEjHX3EkfSlA_AGIbuZlgoZz_z0W .705SVXMSLgiHThEp0G56hcE0NZq1b3egS9dIqb_GhEiYdjzCvrw9RfoE6CtzyiSvSupin9THfBT .5jCyZUrIbGacliER2zJC0i8bynPjvtUv6YusKCQ3QUdPmBzhybe0INv0HVgqdz2KLrwOsz2oyju 7Y8XDHJJH1My9lfz5IXr98oU9csGdZ9ca7No1K7o.WvrgJcYloyJ.v7LGgpBjhqa8HYKz5Ktonm8 Zjr_.eZr5wIeM5H2BLQ26GN7empYEIlHO9DqHNI0qxlPhJ2AI.08ioOBoPmFOCbEpW0pZY7yyafq vReHTW1gTihdg84ydFS4zb.3B.PyLGzI79pm6foTC0kHcu0gf4A34cNzofWg5WIoT5Diu9dHoSW8 hanTct98BlsrIwXSJYMTx6OjXFUWSZTATtTU8YySexCJfuN6_dUZTC01ogRiFtf70rvXVXAbJROB fWVon4NfVI7LPqf8Ys3TAaWhRauaMA2oSAP_p.P7_zA3bluvsSLfRL4RclWHDCN_qs6MycZgpG9v Ty3qhUzL4.NUh_xFvxl8hJxg14KQgU1WTUNzurKJRWY68PIFQOixynROiIE7X2ZkU8BcXfmvaIq6 BI0B4QiZtDC60Bivn9DxSufXGzP2BeDA.dbL0f6guJvltrcOqhY5STZcrARH7H3M- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Tue, 21 Jun 2022 19:55:27 +0000 Received: by hermes--canary-production-ne1-6b56569f5b-q4ddm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9ba34ff29d655c1d76ce2046826c0b93; Tue, 21 Jun 2022 19:55:24 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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: Mountroot problems on RPi3/aarch64 From: Mark Millard In-Reply-To: <20220621192448.GA1874@www.zefox.net> Date: Tue, 21 Jun 2022 12:55:22 -0700 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <54365257-9DA2-4058-9354-B5D76E7AAC70@yahoo.com> References: <20220601154142.GA41835@www.zefox.net> <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@yahoo.com> <20220601214401.GA42494@www.zefox.net> <20220602045202.GA44686@www.zefox.net> <1B845A0C-EDDC-407C-96A8-AAF4E92C2A4D@yahoo.com> <20220613153325.GA12588@www.zefox.net> <50CE21C4-CBE5-4ECB-A27E-42B7AAF71822@yahoo.com> <20220619042225.GA2267@www.zefox.net> <3458F90E-CFC9-4B91-8C4A-DD5788239172@yahoo.com> <20220621192448.GA1874@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LSHLb1P5zz4kq3 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=WrFfP2AZ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.43 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; MLMMJ_DEST(0.00)[freebsd-arm]; NEURAL_HAM_SHORT(-0.93)[-0.933]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jun-21, at 12:24, bob prohaska wrote: > On Sun, Jun 19, 2022 at 02:20:35PM -0700, Mark Millard wrote: >> On 2022-Jun-18, at 21:22, bob prohaska wrote: >>=20 >>> On Sat, Jun 18, 2022 at 03:54:19PM -0700, Mark Millard wrote: >>>> I finally started my round of updates from: >>>>=20 >>>> main-n255745-77649f35a7e5-dirty: Sat May 21 18:48:32 PDT 2022 >>>>=20 >>>> to: >>>>=20 >>>> main-n256189-4014365e4219-dirty: Sat Jun 18 01:47:44 PDT 2022 >>>>=20 >>>> So far all the UFS media that I've tried (older and newer) >>>> have worked fine with the update, including fsck_ffs not >>>> finding any problems. >>>>=20 >>>> It does not appear that I'll end up replicating your problem. >>>>=20 >>>=20 >>> When one invokes fsck at the single-user root prompt what actually >>> gets used on a UFS filesystem? Maybe I've got a name problem..... >>>=20 >>=20 >> The below is for a single-user boot, showing: >>=20 >> A) That / is already read-only at that point >> B) A fsck_ffs that just reports (no repairs) >> C) A fsck_ffs that repairs (and reports) >>=20 >=20 > My question is perhaps more naive than you expected 8-) >=20 > I'm just asking how we get to fsck_ffs (or _whatever) from > fsck. There's no explanation I recognize in the fsck man > page, though fsck_ffs is mentioned in the fsck man page. One way to notice the fsck_ffs man page: # man -k fsck git-fsck(1) - Verifies the connectivity and validity of the objects in = the database git-fsck-objects(1) - Verifies the connectivity and validity of the = objects in the database fsck(8) - file system consistency check and interactive repair fsck_ffs, fsck_ufs, fsck_4.2bsd(8) - file system consistency check and = interactive repair fsck_msdosfs(8) - DOS/Windows (FAT) file system consistency checker fsck_ffs is a separate command. fsck is a wrapper that can put fsck_ffs to use: QUOTE (from man fsck) HISTORY A fsck utility appeared in 4.0BSD. It was reimplemented as a = filesystem independent wrapper in NetBSD 1.3 and first appeared in FreeBSD = 5.0. The original filesystem specific utility became fsck_ffs(8) at this = point. END QUOTE QUOTE (from man fsck) -T fstype:fsoptions List of comma separated file system specific options for = the specified file system type, in the same format as mount(8). END QUOTE Using fsck_ffs directly has more explicit options, such as: QUOTE (from man fsck_ffs) -E Clear unallocated blocks, notifying the underlying device = that they are not used and that their contents may be discarded. = This is useful for filesystems which have been mounted on = systems without TRIM support, or with TRIM support disabled, as = well as filesystems which have been copied from one device to = another. See the -E and -t flags of newfs(8), and the -t flag of tunefs(8). END QUOTE >> The context that was handy was not a RPi* but that >> should not matter. >>=20 >> Note that I avoid being the one to type a device >> path to the root partition: I just use "/" and let it >> find the partition it is already using for the >> boot sequence. >=20 > My habit has so far been the reverse, on the notion > that if root isn't where I expect I'd like to know. I took the context as requiring that I (first?) check that the boot file system in actual use. Later other checks might be done. > Next time things don't work as expected I'll try /. >=20 >>=20 >> . . . >> Enter full pathname of shell or RETURN for /bin/sh:=20 >> # mount >> /dev/gpt/CA72optM2ufs on / (ufs, local, noatime, read-only) >> devfs on /dev (devfs) >> # fsck_ffs -n / >> ** /dev/gpt/CA72optM2ufs (NO WRITE) >> ** Last Mounted on / >> ** Root file system >> ** Phase 1 - Check Blocks and Sizes >> ** Phase 2 - Check Pathnames >> ** Phase 3 - Check Connectivity >> ** Phase 4 - Check Reference Counts >> ** Phase 5 - Check Cyl groups >> 2019019 files, 45278396 used, 116718936 free (345928 frags, 14546626 = blocks, 0.2% fragmentation) >> # fsck_ffs -y / >> ** /dev/gpt/CA72optM2ufs >> ** Last Mounted on / >> ** Root file system >> ** Phase 1 - Check Blocks and Sizes >> ** Phase 2 - Check Pathnames >> ** Phase 3 - Check Connectivity >> ** Phase 4 - Check Reference Counts >> ** Phase 5 - Check Cyl groups >> 2019019 files, 45278396 used, 116718936 free (345928 frags, 14546626 = blocks, 0.2% fragmentation) >>=20 >> ***** FILE SYSTEM IS CLEAN ***** >> #=20 >>=20 >> I will note the warning about -y use (in the man page for >> fsck_ffs): >>=20 >> -y Assume a yes response to all questions asked by fsck_ffs; = this >> should be used with great caution as this is a free = license to >> continue after essentially unlimited trouble has been >> encountered. >>=20 >> So, if at some point you had -y "repair" a large number >> of issues, it might have included bad repairs based on >> already bad data. (Such could be an automatic repair, >> rather than one manually run.) >>=20 >> However, the (lack of) background knowledge for answering >> each question and the volume of questions that can >> happen, tends to lead to -y use, even for manual runs. >>=20 >>=20 >=20 > I've never seen any discussion of how to answer fsck's questions > and thought the knowldege required became extinct with the end of > ST506 disks 8-) I assume that the primary folks that work on UFS changes (and historically did so) would have a clue. >> Note: recovering from a building power outage sequence >> and other issues delayed getting to this. >>=20 >> But the power outage sequence happened after a 8 GiByte >> RPi4B had spent between 17 and 18 hours short of 3 weeks >> working on a "bulk -a -c", having built 16343 ports (and >> 171 failures) in the UFS context. The automatic fsck >> that happened once power stayed on took a rather long >> time for the large number of repairs involved, likely >> slowed by the serial console scrolling the reports. >>=20 >> (The bulk run was an experiment with building for armv7 >> and the results were not to be kept.) >>=20 >>=20 >> Side note on RPi2's/RPI3's: >>=20 >> https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/ >>=20 >> reports for Fedora's default configuration choices: >>=20 >> QUOTE >> The serial console is disabled by default on the Raspberry Pi 2 >> and 3 because it requires the device to run at significantly >> slower speeds. >> END QUOTE >>=20 >=20 > That's quite a surprise.=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com