From nobody Sun Jun 19 21:20:35 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 5DD3A8647D9 for ; Sun, 19 Jun 2022 21:20:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (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 4LR5Kr1bcwz4hHX for ; Sun, 19 Jun 2022 21:20:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1655673641; bh=appN3tXmlfSnN3FDjcIXDSAv0twnd5Ot2aAPliqxoD8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CoD3KG9fWB+mcuGhVNKXv+Jz0TklvYYBwddvO4IUKT68DB4DmK/1MOfgVQ+xsgqAFIM33w6d6OP1GzyvOweTTk9dlFWuZ0NIJ2JN1L8UFCRNWXNd9C1l8INPDJfz3h6dNdrAET25bPv9hXXbrS6ApU84Jjh6hK1uuq2tvXl2S7AWUgGyM7K9CsZMuGt2vQ/7I4fsKYATIzIcvpJXpuxtkqmC4POL8SO1avnQLYA2TFpgKy6ILGPuPpu/VMRJ+y/fobEBcDkuOOlvxkyyCncOtKjlgGrbqtr3oj7AH/jKJF7VO7/LSQE4nFvghqZalJCW6VBoYqL2MC5yj9hijuou9A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1655673641; bh=LTZyoqFVWEm896vOkiOdTzb98sF69Rct6XpYaqcnSag=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=SAEDTclTuhbvfvrar+YJwil+2pd4YbFDZ8wbkyPdi+CH035xXKj3iPKxpwEz2gyUERFaIvOPo2Qja8+gJxLemiP//pNvrs0CD4HTHG0Raa2X3a16cQYJDqYoUsBjMegIYeWMSytTmXYHbA5mde4CQBhdcoHvEYbN+RIb9u8RFGVDC7bajdZzaN8lU8o5IcO/gu3aErxzEWDLEpMyfen73u4L9462KoxNmRIsdqwUNfhAdr4BK6kElM7czQHTLG6rtnbHgRpW4qCQ6TtKyq2f67l2AUMjtQVCmKYcLC17szbxAedxOWrR5mCVpelp3L2Qnihz4I4OnLm0EKE5BEr/wA== X-YMail-OSG: 0NKI.nsVM1nJzk6dRh70VOeukKOWs_4UvD4PjWjF7SBc.RjHnALrYD7UM.o201Y AoDFDjmtqpLasjjsTHlVYaBG0tRtSyKspTfBOo7SlFgYFsPuegoxizx5ZCFKBN9.c5ukearjEueB 7coekHoH0Nq4njRpVAMNGYqAc7Tnifa6eI.ndaukmapG.FY8q.lF1gwoAzgZ1SHwEYXoD0nh41dt _O57ZUhVUWJTx6VbS3o1BF9_MaFWET2jmbfa8pdwvC2TO7tbb4rCXAypKYxmUhFKcpdwj3TtvSXr 5WBQwGF67MpfD2UAqBSum9rrY10CX90Y6DPR9pwsxsOkt9TD39_Q9cMe.eLsYm_DbpHRh7eBGSpf 7Cjs.PH0AnsH8tUfWtilg2rzVfp20TzoA0lY_7n3STehCLj_G0JUN.zg9ROOgZzyLbQ4dktukyE. 3zY0RNwcRj2j33xAq8a7N49ABHCAga4WQtVgjgePCKNBrDupWkQpsiD.tNuSQowq8kQH3SpfPHU_ uusDT5gaUm7wm7s7bfaNyFKEAx8jx8ogP._Ad7Mtd5BPfNdicWRcGklbgYbUhwfLeHKc2EMfskl7 zPgRxg8S.TAnTLeYfhlI8NkMwIX_mKBIXr4J0Ms69bVagm95EP5meuYH1wo6O3PHO7VEY0uXkbpt k18SUYs6BjHrSPr1AUbNO0yrjX6uz2yOXkdbAPPtvBwI9_nbEAshETrXn6W_GMRsgN8oTaLOS71Y 6giPMIuNKgJRkjHLT64BuPSwN4CxyXxqa0C47IMNqTrqrB_WlWaUY7x06Vm0La150jXS0XYFqV2t 1ad9Yw.T90D_KDYK8euuwQvZQ8t8QwJkVIAgCp5JJrtN95sP6ph3l5o3DnZQBwFH91YATUbEfry5 Ch.u3qyd1.1zFT2k320ko664aLfecQKNLo6wR7D1zwQ3Uo7teQgjbDvvdXNXxOvOxhveJByvX6v2 UaNxzTJ5MBZOfRHPBoz6UFn1lKL9D8gi6Y.DrLqXEQE7angJ8VAwKqk9J_7WPBHvYtZaeygpS_X4 Dn4t5utdUmtJnmiBQvYZUG7sa0r4jeX5YorwHvpXtgpCDULVrs0u8JLudmK306WK4SJiNvOuSqVw wav6edgsFE9zF89qJpTzA4Amkru4zeH4n3KW_JsJtYgkNMkdvm1plXpMaVO0C3lKvJIsrExaFS2H rkSg1Uku9u7ABcsnh_jFCK3DKeX5FctB.lcFOjSmqwQ_J5gXrnYZmGqjkaIUwdYoN6_JuFnE_I3q RcInqDheLvxqgZmqkrvHt.nFdOoeOf1VjpK5U5OkqLC.fibSZxj..fET84svJWrklXxV0_xNlpAz 4o_._yMkCt8FRUgONiDSEBbgPOPBoKlGREpvwWVjOr8CLAVmQqHGmmwRvAufFGS8omAYv1LP9CNY z39VHkMqCXVfSRCzI8quetKT4qAJDy.SuVUf82sRp3l.c0jdIOIA06_N_avlq1t5CGgF0YPRVf7M 8TsKnJ3OoJpUipoJQ.30Ernuod1yN1JEBaQ0CdcqQTACW0Lk4ZEpGENRZ.sSzRoM.HcsriYS8Yfa bHZ4Y9rZGD8p.g8tVNtxmOgPqc2i4RkiE1MdmM_dMjCq.3Yslao3HehUqwEeUu3xa956veiTGlk4 9IqWnT9QjCX.oYfpBBwxV_EWPnfJx9zWzX9Pudf_oAHhJCUl1O__mBxRnMFHdzR.wF9VWZIExf32 NH3.8QbQTr3dHyc_EMOBW9ZarNpfw9q.3EK20Sgg4h9L_U_BdbxPoxJ78Stx_GykJdHfGyfFt2a5 eAVe1bzDtB7fjODnsSAvpLwaxOXoRFDuIaNlrC81t6uzr3wje29MW36HP0dx0W6881jbov8mUHao Fjrushss8UFtcyjsQz4wi9b_CYM.oPObaZIYyXIjRJqJD6Yb4gOGsemV9qlQWBFW03XvgSbO5ATA h1g2LfdenA9pAxTr5gu1lC41qut1NN.7e7KJO.1x2ly5ULbcmCeZSELvGJZncKMQlHLL9eju5jFA 9bkyUlfYWsNqKfZLwWdQXTG64dAgMImvTSEIpJ.C4CFPtqPwcJ2WVLGjR6cnt9XeRlimV3DoHS.l 2nnmycbmVHGqVnbnB1QpZ4xdjyv7pI2GCRGnzTo5a5j076l8R8Rb85z8JFS9_UdJy1mBrfUkYsly ecO2W27ql_3PxtSawsYeAnVcLbW7upKtYpKi97ezW3if1HFXzQigkmFNOX2RLS3F0ufrvwEr9EnH 5CgiH5rHpQF6bV3XTMi7pC5vM12zx_1vQv8jCBIM4GHHuewz9yPZTrRq57yTsE7KCzQloaYzdsoV FwuT2IG5PHoWB2a.1ld3uSnndE815QN2CFEVt64rzxvAzzQ7CBnvEb4vMsGh0ZOb7RP8- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 19 Jun 2022 21:20:41 +0000 Received: by hermes--canary-production-gq1-677bd878b7-85vm8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bc8501b21ade799736a2e9bda0691852; Sun, 19 Jun 2022 21:20:36 +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: <20220619042225.GA2267@www.zefox.net> Date: Sun, 19 Jun 2022 14:20:35 -0700 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <3458F90E-CFC9-4B91-8C4A-DD5788239172@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> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LR5Kr1bcwz4hHX X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=CoD3KG9f; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 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.999]; 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]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MLMMJ_DEST(0.00)[freebsd-arm]; 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-18, at 21:22, bob prohaska wrote: > 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 The below is for a single-user boot, showing: 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) The context that was handy was not a RPi* but that should not matter. 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. . . . 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) ***** FILE SYSTEM IS CLEAN ***** #=20 I will note the warning about -y use (in the man page for fsck_ffs): -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. 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.) 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. Note: recovering from a building power outage sequence and other issues delayed getting to this. 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. (The bulk run was an experiment with building for armv7 and the results were not to be kept.) Side note on RPi2's/RPI3's: https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/ reports for Fedora's default configuration choices: 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 I've never explored the specifics of the tradeoffs involved and they do not seem to document them. (I assume this is more than normal serial output related time. But I'd also expect that it is not something fedora specific.) =3D=3D=3D Mark Millard marklmi at yahoo.com