Date: Tue, 21 Jun 2022 15:45:23 -0400 From: Paul Mather <paul@gromit.dlib.vt.edu> To: Free BSD <freebsd-arm@freebsd.org> Cc: Mark Millard <marklmi@yahoo.com>, bob prohaska <fbsd@www.zefox.net> Subject: Re: Mountroot problems on RPi3/aarch64 Message-ID: <3E37B905-2627-469A-BA20-32FD79F8D12D@gromit.dlib.vt.edu> 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 Jun 21, 2022, at 3:24 PM, 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.
The fsck man page (at least the one currently on 13-STABLE) says this:
If no file systems are specified, fsck reads the table /etc/fstab =
to
determine which file systems to check. Only partitions in =
/etc/fstab
that are mounted =E2=80=9Crw=E2=80=9D, =E2=80=9Crq=E2=80=9D or =
=E2=80=9Cro=E2=80=9D and that have non-zero pass number
are checked. File systems with pass number 1 (normally just the =
root
file system) are always checked one at a time.
and this:
If the -t or -T flags are not specified, fsck will attempt to =
determine
the file system type and call the appropriate file system check =
utility.
Failure to detect the file system type will cause fsck to fail with =
a
message that the partition has an unknown file system type.
I don't know what precise mechanism fsck uses to determine which =
fsck_XXX binary to invoke to check a file system, but I can posit at =
least two possibilities:
1) It uses the "FStype" field from /etc/fstab as its guess;
2) More likely, it invokes "fstyp" to detect what file system the device =
contains.
The fstyp man page includes this description:
The fstyp utility is used to determine the filesystem type on a =
given
device. It can recognize BeFS (BeOS), ISO-9660, exFAT, Ext2, FAT, =
NTFS,
and UFS filesystems. When the -u flag is specified, fstyp also
recognizes certain additional metadata formats that cannot be =
handled
using mount(8), such as geli(8) providers, and ZFS pools.
E.g.:
# fstyp /dev/mirror/efi
msdosfs
# fstyp /dev/mirror/swap
fstyp: /dev/mirror/swap: filesystem not recognized
# fstyp -u /dev/gpt/zfs0
zfs
Cheers,
Paul.
PS: This guess is worth what you paid for it. :-)=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E37B905-2627-469A-BA20-32FD79F8D12D>