Date: Tue, 21 Jun 2022 12:24:48 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: Free BSD <freebsd-arm@freebsd.org> Subject: Re: Mountroot problems on RPi3/aarch64 Message-ID: <20220621192448.GA1874@www.zefox.net> In-Reply-To: <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> <CE0A908C-EFF3-455D-B303-BCC56C95EAB1@yahoo.com> <20220619042225.GA2267@www.zefox.net> <3458F90E-CFC9-4B91-8C4A-DD5788239172@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jun 19, 2022 at 02:20:35PM -0700, Mark Millard wrote: > On 2022-Jun-18, at 21:22, bob prohaska <fbsd@www.zefox.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220621192448.GA1874>