Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Apr 2020 00:33:21 +1000
From:      Scott <>
To:        Polytropon <>,
Subject:   Re: Should fsck honour "failok" in fstab as mount does?
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Tue, Apr 21, 2020 at 04:09:39PM +0200, Polytropon wrote:
> On Tue, 21 Apr 2020 23:54:06 +1000, Scott wrote:
> > On Tue, Apr 21, 2020 at 03:31:44PM +0200, Polytropon wrote:
> > > On Tue, 21 Apr 2020 17:13:20 +1000, Scott wrote:
> > > work. The file /etc/fstab is the filesystem table intended
> > > for use with mount; the fact that fsck uses it is just a nice
> > > side effect, but not its primary use. That's why the options
> > > field is intended for the mount command.
> > 
> > True, but that doesn't preclude fsck's use of any hints it may glean from 
> > /etc/fstab.
> The 6th field of /etc/fstab, the "fsck column", is intnded
> to be used by fsck, as per the manual, but of course this
> does not say anything about "what to do in case of problems".
> > > The effect that the system drops into single-user mode is
> > > also intended. When fsck is invoked - upon filesystem error -
> > 
> > Sure, but the point of `failok' is to continue booting even if the so 
> > optioned filesystem cannot mount for whatever reason.  Unfortunately fsck 
> > makes no use of this indication and prevents booting.  These two commands, 
> > fsck and mount need to work in tandem.
> Yes, that is correct. However, it looks like "noauto" is
> basically what you're searching for. During the boot process,
> specific filesystems are gathered from /etc/fstab, and their
> consistency is tested before mounting, afterwards they are
> mounted. Later mounting and manual mounting is possible too,
> even with filesystems specified in /etc/fstab, but with the
> "noauto" mount option - in this case, fsck won't even look
> at them, except mount itself could complain ("so-and-so was
> not properly dismounted").

So you've established that fsck parses the fs_mntops column for advice, which 
is great.  Why not just make it recognise the `failok' option?
> So the consensus seems to be: If you don't want fsck to look
> at a filesystem and maybe stop the boot process, use "noauto".
> If you want it to be mounted later on, do so manually (with
> of of the methods I mentioned, or entirely interactively).

Yes but I DO want fsck to look at the filesystem, but continue if it fails 
(for example, if the device does not exist).  Just like I DO want mount to 
mount the filesystem, but continue if it can't.

> > > If you don't want fsck to stumble upon a damaged filesystem,
> > > do not include it in /etc/fstab. You can still use a custom
> > > rc.d-style script or an entry in /etc/rc.local if you wish
> > > to "maybe mount" non-vital or optional filesystems later on.
> >  
> > Sure, but why would you want to do it that way?  The same could be said when 
> > the `failok' option was not available to mount.
> Right, this approach does not even require "failok".
> > Consider the situation where a device specified in /etc/fstab is not present 
> > during boot, say a USB stick.  You've added the `failok' option to its 
> > /etc/fstab entry, declaring that if you can't mount the device, ignore the 
> > error and continue. fsck will still drop into single user mode.  Does that 
> > make sense?
> Yes, because the entry in /etc/fstab says the device is _required_
> during the boot process - any non-"noauto" entry is to be checked
> and mounted during system boot. The opposite of "noauto" is "auto",
> and it is the default - meaning, according to the manual: "to be
> automatically mounted at system startup". So any of such entries
> is considered "required for booting".

That's not completely true, because for NFS mounts we have the `bg' option, 
which allows the system to continue booting even if it can't be mounted.  
i.e.: not all `noauto' filesystems are _required_.

> I think you're expecting "failok" to do something it is not
> intended to do.

Not really.  I want `failok' to do something it doesn't currently.  Where 
would be the harm in patching fsck to recognise it?

Given the resistance perhaps I should be pushing for fsck to continue on a 
non-existent device (really, how does a missing device fail a consistency 
check?). Then mount will presumably fail if the `failok' is not present.


Want to link to this message? Use this URL: <>