Re: Mountroot problems on RPi3/aarch64

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)

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: 
# 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.


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.)

===
Mark Millard
marklmi at yahoo.com