Re: Mountroot problems on RPi3/aarch64

From: Paul Mather <paul_at_gromit.dlib.vt.edu>
Date: Tue, 21 Jun 2022 19:45:23 UTC
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:
>> 
>>> 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 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 “rw”, “rq” or “ro” 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. :-)