From nobody Tue Jun 21 19:24:48 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 7D6EF87318E for ; Tue, 21 Jun 2022 19:24:57 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSGgD1mztz4gk1 for ; Tue, 21 Jun 2022 19:24:56 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 25LJOmPf002455 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 21 Jun 2022 12:24:49 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 25LJOmQJ002454; Tue, 21 Jun 2022 12:24:48 -0700 (PDT) (envelope-from fbsd) Date: Tue, 21 Jun 2022 12:24:48 -0700 From: bob prohaska To: Mark Millard Cc: Free BSD Subject: Re: Mountroot problems on RPi3/aarch64 Message-ID: <20220621192448.GA1874@www.zefox.net> 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> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3458F90E-CFC9-4B91-8C4A-DD5788239172@yahoo.com> X-Rspamd-Queue-Id: 4LSGgD1mztz4gk1 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [2.49 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_HAM_MEDIUM(-0.96)[-0.956]; NEURAL_SPAM_SHORT(0.55)[0.547]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, Jun 19, 2022 at 02:20:35PM -0700, Mark Millard wrote: > 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: > >> > >> main-n255745-77649f35a7e5-dirty: Sat May 21 18:48:32 PDT 2022 > >> > >> to: > >> > >> main-n256189-4014365e4219-dirty: Sat Jun 18 01:47:44 PDT 2022 > >> > >> 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. > >> > >> It does not appear that I'll end up replicating your problem. > >> > > > > 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..... > > > > 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) > My question is perhaps more naive than you expected 8-) 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. > 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. My habit has so far been the reverse, on the notion that if root isn't where I expect I'd like to know. Next time things don't work as expected I'll try /. > > . . . > Enter full pathname of shell or RETURN for /bin/sh: > # 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 ***** > # > > 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. > > 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-) > 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 > That's quite a surprise. Thanks for writing! bob prohaska