From owner-freebsd-questions@freebsd.org Tue Apr 21 14:09:57 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 E8B9B2CEE4B for ; Tue, 21 Apr 2020 14:09:57 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49656r71WRz4Mp2 for ; Tue, 21 Apr 2020 14:09:56 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([94.222.27.149]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.167]) with ESMTPA (Nemesis) id 1MTiDV-1jo9dI1yMn-00U0XR; Tue, 21 Apr 2020 16:09:41 +0200 Date: Tue, 21 Apr 2020 16:09:39 +0200 From: Polytropon To: Scott Cc: freebsd-questions@freebsd.org Subject: Re: Should fsck honour "failok" in fstab as mount does? Message-Id: <20200421160939.aa2fbd89.freebsd@edvax.de> In-Reply-To: <20200421135406.GA74559@thismonkey.com> References: <20200421071319.GA98163@thismonkey.com> <20200421153144.d45a889b.freebsd@edvax.de> <20200421135406.GA74559@thismonkey.com> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:1GPxPyKWnY982HLTpfhacl1ngO38u4LGkitsuqkbmbG5ZESc90y hoSPP2dzoZnKvzEx0SzYg2s/Dvb6y1uVvzyqGtSIXRi4Kcpix61KwmeFzALztbnRTUPvDtk 2Z/U36xpRuj+93TWnPqxF4vQTZzHMRu0K2rxf8K/yC55Kb78/w9aWXaPJuS6e2FTIRa+Q+T cDUI0rDubEMp/iH3NrapA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:0rT9n0KZSkc=:8oIoPb71uG+n0SsxVRP/C8 gY8Ivl30YSJy8yCzcYBh2VvCQqypt2HAkXbE4AH1JoIsZPvsv4Z21TLLGnSabyc4m++BElxvz J53a3KXhOrGo7CUieHi3EobKsL8GwxL/i6GwoHSD0WPyQIm2pEK0W9tYKf7QlLitA6H372UE5 uUcYAOWsGn6b8rUf/KhI18F1nvwMbmB3WNnLcE432MvjsCkDJk60b9PSr2wBRyZN9gWDK8Sfk 2KYrGJ9M6mQ57JOUcK6ALAwYIezcVpjf9M+7cXqhQOOzksbQOxp0P9oWB5oDFCTj7Iv8wzOpo gyrH7zi8I99gBNO8CWnnNfxxu/UPitNDj+BDjdP/D1yq+/j1HoaUhTc51jmW4DccKIgSj/88o OS0aBZeslQr//MhTw6vVBok+krY/VIAfnrFz7/6OkbuQ+38ErFFgXPIVTVEbEGAeA3QpARadi iTSAEYFGXR9YtVK8CQod6MfKyXmYrWK1cbYq9xLxghq4zvll8c3YvEIgQUSuaGXmLtRqBTT/E 6pC/sQH66XRNFsGLtTnZU2WTTXHWf0J5jsk/yfyAnK7k214TifFTxA0VcSQ6jaVJ/PMNUKx0k H0lCL1jhTnfLPQVB+LC1RgvnqswdC4eJTu9UtSfBgZwfpBp0PU11zSGSL+KZ1oPLZxOHrleKK JAqkusZgR7/8ntU6QC5qbx6ndMEH/YWDkYdTmoUaSPV9dr07ZIIpozgmZhE3wHBbKgs8PtF1U YyCIU5VdaS8udk6OM0sTHS8+lmNvxZ+bhpDfVI6Uo8CU169tphTqmq3y2YAfEuLbn6JCTkdfB 8i/VdLOD9hqg+qYipjR/NdYdahcY6bIvRSmuZJSXvEZ4G3yaUjwUoMprqnaCdBqqcoF7eOt X-Rspamd-Queue-Id: 49656r71WRz4Mp2 X-Spamd-Bar: +++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@edvax.de has no SPF policy when checking 212.227.126.130) smtp.mailfrom=freebsd@edvax.de X-Spamd-Result: default: False [5.86 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[freebsd@edvax.de]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_ORG_HEADER(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RECEIVED_SPAMHAUS_PBL(0.00)[149.27.222.94.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[edvax.de]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.97)[0.974,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000,0]; MID_CONTAINS_FROM(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[130.126.227.212.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[130.126.227.212.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(0.49)[ip: (1.59), ipnet: 212.227.0.0/16(-1.20), asn: 8560(2.08), country: DE(-0.02)] 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:09:58 -0000 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 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). > > 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". I think you're expecting "failok" to do something it is not intended to do. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...