Date: Tue, 21 Jun 2022 12:55:22 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: Free BSD <freebsd-arm@freebsd.org> Subject: Re: Mountroot problems on RPi3/aarch64 Message-ID: <54365257-9DA2-4058-9354-B5D76E7AAC70@yahoo.com> In-Reply-To: <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> <CE0A908C-EFF3-455D-B303-BCC56C95EAB1@yahoo.com> <20220619042225.GA2267@www.zefox.net> <3458F90E-CFC9-4B91-8C4A-DD5788239172@yahoo.com> <20220621192448.GA1874@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
>>=20
>>> On Sat, Jun 18, 2022 at 03:54:19PM -0700, Mark Millard wrote:
>>>> I finally started my round of updates from:
>>>>=20
>>>> main-n255745-77649f35a7e5-dirty: Sat May 21 18:48:32 PDT 2022
>>>>=20
>>>> to:
>>>>=20
>>>> main-n256189-4014365e4219-dirty: Sat Jun 18 01:47:44 PDT 2022
>>>>=20
>>>> 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.
>>>>=20
>>>> It does not appear that I'll end up replicating your problem.
>>>>=20
>>>=20
>>> 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.....
>>>=20
>>=20
>> The below is for a single-user boot, showing:
>>=20
>> 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)
>>=20
>=20
> My question is perhaps more naive than you expected 8-)
>=20
> 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.
>>=20
>> 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.
>=20
> 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 /.
>=20
>>=20
>> . . .
>> Enter full pathname of shell or RETURN for /bin/sh:=20
>> # 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)
>>=20
>> ***** FILE SYSTEM IS CLEAN *****
>> #=20
>>=20
>> I will note the warning about -y use (in the man page for
>> fsck_ffs):
>>=20
>> -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.
>>=20
>> 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.)
>>=20
>> 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.
>>=20
>>=20
>=20
> 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.
>>=20
>> 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.
>>=20
>> (The bulk run was an experiment with building for armv7
>> and the results were not to be kept.)
>>=20
>>=20
>> Side note on RPi2's/RPI3's:
>>=20
>> https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/
>>=20
>> reports for Fedora's default configuration choices:
>>=20
>> 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
>>=20
>=20
> That's quite a surprise.=20
>=20
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54365257-9DA2-4058-9354-B5D76E7AAC70>