fsck and memory filesytems (fsck_mfs: No such file or directory)

[Christopher Key]

Boris Samorodov wrote:
> On Mon, 05 Nov 2007 17:00:06 +0000 Christopher Key wrote:
>
>   
>> I recently had a powercut to my FreeBSD home server, and I'm now
>> getting the following messages at startup:
>>     
>
>   
>> Starting file system checks:
>> /dev/ad8s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS
>> /dev/ad8s1a: clean, 466797 free (2837 frags, 57995 blocks, 0.6%
>> fragmentation)
>> fsck: exec fsck_mfs for md in /sbin:/usr/sbin: No such file or directory
>> fsck: exec fsck_mfs for md in /sbin:/usr/sbin: No such file or directory
>> /dev/ad8s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS
>> /dev/ad8s1f: clean, 214294022 free (173430 frags, 26765074 blocks,
>> 0.1% fragmentation)
>> /dev/mirror/gm0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS
>> /dev/mirror/gm0s1d: clean, 16121593 free (1441 frags, 2015019 blocks,
>> 0.0% fragmentation)
>> /dev/mirror/gm0s2d: FILE SYSTEM CLEAN; SKIPPING CHECKS
>> /dev/mirror/gm0s2d: clean, 63140067 free (4187 frags, 7891985 blocks,
>> 0.0% fragmentation)
>> /dev/ad8s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS
>> /dev/ad8s1e: clean, 8049657 free (1169 frags, 1006061 blocks, 0.0%
>> fragmentation)
>> /dev/mirror/gm0s3d: FILE SYSTEM CLEAN; SKIPPING CHECKS
>> /dev/mirror/gm0s3d: clean, 84638779 free (1779 frags, 10579625 blocks,
>> 0.0% fragmentation)
>> /dev/ad8s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS
>> /dev/ad8s1d: clean, 6625471 free (47 frags, 828178 blocks, 0.0%
>> fragmentation)
>> THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY:
>>        mfs: md (/tmp)
>> Unknown error; help!
>> NEnter full pathname of shell or RETURN for /bin/sh:
>>     
>
>
>   
>> The problem is, I'm sure, is essentially identical to that described in,
>>     
>
>   
>> http://www.mail-archive.com/freebsd-current@freebsd.org/msg21675.html
>>     
>
>   
>> namely that the entry for the memory filesystem, /tmp, in /etc/fstab
>> is confusing fsck.  My /etc/fstab looks like,
>>     
>
>   
>> # cat /etc/fstab
>> # Device                Mountpoint      FStype  Options         Dump
>> Pass#
>> /dev/ad8s1b             none            swap    sw              0       0
>> /dev/ad8s1a             /               ufs     rw              1       1
>> md                      /tmp            mfs     rw,-s64m
>> 2      2
>>     
>         ^^^ [1]
>
>   
>> /dev/ad8s1f             /usr            ufs     rw              2       2
>> /dev/ad8s1e             /var            ufs     rw              2       2
>> /dev/ad8s1d             /var/tmp        ufs     rw              3       3
>>     
>                                                                  ^^^^^^^^^^ [2]
>   
>> /dev/mirror/gm0s1d      /svn            ufs     rw              2       2
>> /dev/mirror/gm0s2d      /data           ufs     rw              2       2
>> /dev/mirror/gm0s3d      /music          ufs     rw              2       2
>>     
>
>   
>> I can get the system to boot quite happily by carrying on into single
>> user mode and exiting, but I still get the same behaviour next reboot.
>>     
>
>   
>> Does anyone have any suggestions?
>>     
>
> [1] According to man(5) fstab:
> -----
>      The sixth field, (fs_passno), is used by the fsck(8) program to determine
>      the order in which file system checks are done at reboot time.  The root
>      file system should be specified with a fs_passno of 1, and other file
>      systems should have a fs_passno of 2.  File systems within a drive will
>      be checked sequentially, but file systems on different drives will be
>      checked at the same time to utilize parallelism available in the hard-
>      ware.  If the sixth field is not present or is zero, a value of zero is
>      returned and fsck(8) will assume that the file system does not need to be
>      checked.
> -----
>
> Seems that you need to use "0" istead of "2". I'd say the same for the
> fifth field here.
>
> BTW, I can't find what does [2] mean (the values "3" here)...
>
>
> WBR
>   
Thanks Boris, Daniel,

Setting the pass# to 0 for /tmp worked perfectly.

The reason for having a pass# of 3 for /var/tmp was, to put it 
succinctly, because it was mounted within a filesystem with a pass# of 2.

My understanding was that the fsck didn't start to check a filesystem 
with a pass# of n+1 until it had successfully checked all those with a 
pass# of n.  I expected that you would always want to make sure that, 
before checking some filesystem, you ensured that its mount point was 
valid first, and hence gave it a greater pass# that the filesystem in 
which it gets mounted.  Hence / having a pass# of 1, and /usr/ var etc 
having a pass# of 2.

If anyone knows otherwise, I'd appreciate the correction.

Regards,

Chris