From owner-freebsd-questions@freebsd.org Tue Apr 21 14:33:40 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E55C52CF74F for ; Tue, 21 Apr 2020 14:33:40 +0000 (UTC) (envelope-from freebsd-lists-5@thismonkey.com) Received: from mail-01.thismonkey.com (mail-01.thismonkey.com [IPv6:2406:3400:35e:6602::a01:232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thismonkey.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4965fB3KbLz4P35 for ; Tue, 21 Apr 2020 14:33:37 +0000 (UTC) (envelope-from freebsd-lists-5@thismonkey.com) X-TM-Via-MX: mail-01.thismonkey.com Received: from utility-01.thismonkey.com (utility-01.thismonkey.com [IPv6:2406:3400:35e:6601:0:0:a01:120]) by mail-01.thismonkey.com (8.15.2/8.15.2) with ESMTPS id 03LEXMch055913 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Apr 2020 00:33:24 +1000 (EST) (envelope-from freebsd-lists-5@thismonkey.com) Received: from utility-01.thismonkey.com (localhost [127.0.0.1]) by utility-01.thismonkey.com (8.15.2/8.15.2) with ESMTP id 03LEXMbo067341; Wed, 22 Apr 2020 00:33:22 +1000 (EST) (envelope-from freebsd-lists-5@thismonkey.com) Received: (from root@localhost) by utility-01.thismonkey.com (8.15.2/8.15.2/Submit) id 03LEXLgP067329; Wed, 22 Apr 2020 00:33:21 +1000 (EST) (envelope-from freebsd-lists-5@thismonkey.com) Date: Wed, 22 Apr 2020 00:33:21 +1000 From: Scott To: Polytropon , freebsd-questions@freebsd.org Subject: Re: Should fsck honour "failok" in fstab as mount does? Message-ID: <20200421143321.GA33168@thismonkey.com> Mail-Followup-To: Polytropon , freebsd-questions@freebsd.org References: <20200421071319.GA98163@thismonkey.com> <20200421153144.d45a889b.freebsd@edvax.de> <20200421135406.GA74559@thismonkey.com> <20200421160939.aa2fbd89.freebsd@edvax.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200421160939.aa2fbd89.freebsd@edvax.de> User-Agent: Mutt/1.11.4 (2019-03-13) X-Virus-Scanned: clamav-milter 0.102.2 at mail-01.thismonkey.com X-Virus-Status: Clean X-Rspamd-Queue-Id: 4965fB3KbLz4P35 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=thismonkey.com; spf=pass (mx1.freebsd.org: domain of freebsd-lists-5@thismonkey.com designates 2406:3400:35e:6602::a01:232 as permitted sender) smtp.mailfrom=freebsd-lists-5@thismonkey.com X-Spamd-Result: default: False [-3.58 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[thismonkey.com,none]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:10143, ipnet:2406:3400:300::/40, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-1.78)[ip: (-7.86), ipnet: 2406:3400:300::/40(-3.93), asn: 10143(2.85), country: AU(0.01)] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 14:33:41 -0000 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. Scott