Re: Mountroot problems on RPi3/aarch64

On 2022-Jun-21, at 12:24, bob prohaska <fbsd@www.zefox.net> wrote:

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

One way to notice the fsck_ffs man page:

# man -k fsck
git-fsck(1) - Verifies the connectivity and validity of the objects in the database
git-fsck-objects(1) - Verifies the connectivity and validity of the objects in the database
fsck(8) - file system consistency check and interactive repair
fsck_ffs, fsck_ufs, fsck_4.2bsd(8) - file system consistency check and interactive repair
fsck_msdosfs(8) - DOS/Windows (FAT) file system consistency checker

fsck_ffs is a separate command. fsck is a wrapper that can
put fsck_ffs to use:

QUOTE (from man fsck)
HISTORY
     A fsck utility appeared in 4.0BSD.  It was reimplemented as a filesystem
     independent wrapper in NetBSD 1.3 and first appeared in FreeBSD 5.0.  The
     original filesystem specific utility became fsck_ffs(8) at this point.
END QUOTE

QUOTE (from man fsck)
     -T fstype:fsoptions
             List of comma separated file system specific options for the
             specified file system type, in the same format as mount(8).
END QUOTE

Using fsck_ffs directly has more explicit options, such as:

QUOTE (from man fsck_ffs)
     -E      Clear unallocated blocks, notifying the underlying device that
             they are not used and that their contents may be discarded.  This
             is useful for filesystems which have been mounted on systems
             without TRIM support, or with TRIM support disabled, as well as
             filesystems which have been copied from one device to another.

             See the -E and -t flags of newfs(8), and the -t flag of
             tunefs(8).
END QUOTE


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

I took the context as requiring that I (first?) check
that the boot file system in actual use. Later other
checks might be done.

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

I assume that the primary folks that work on UFS
changes (and historically did so) would have a
clue.

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



===
Mark Millard
marklmi at yahoo.com