Re: Mountroot problems on RPi3/aarch64

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