Date:Thu, 17 Mar 2022 17:34:03 -0400 (EDT)
From:Mouse
Message-ID: <202203172134.raa26...@stone.rodents-montreal.org>
| Though it seems like a good discussion in that some real progress was
| made, in that the lack of a "noerror" or "allowfail" or whatever flag
|
>> Though it seems like a good discussion in that some real progress
>> was made, in that the lack of a "noerror" or "allowfail" or whatever
>> flag [...]
> The major issue is that it requires the results of the fsck to be
> available to the mount stage, which isn't so easy to do when both are
> ju
On Thu, Mar 17, 2022 at 11:16:16PM +1100, Simon Burge wrote:
> Broadly I think I can summarise to the following options:
>
> 1. The existing critical_filesystems_zfs rc.conf variable, which
> mixes ZFS configuration in both rc.conf and with ZFS itself.
> 2. Add ZFS "critical" properties for
Hi :)
On Fri, Mar 18, 2022 at 09:21:26AM -0400, Mouse wrote:
> Another option might be for all optional systems to be fscked and
> mounted in the background, without even delaying rc for them, never
> mind erroring if they fail. This makes it possible to handle the error
> reporting via things li
>> Getting even more radical (and intrusive to the status quo), I would
>> suggest having _all_ fsck and mount runs happening in the
>> background, with other rc stuff delaying until the filesystem(s)
>> needed is/are mounted. (Figuring out how to handle / would be one
>> of the interesting bits.)
Le Fri, Mar 18, 2022 at 12:41:36PM -0400, Mouse a écrit :
>
>
> [...] The biggest issues I
> would expect to have are the ones surrounding dealing with / (and any
> other mountpoints needed for this - I'd be inclined to require that the
> binaries involved be on /). I suspect / may have to cont
> I always wondered---as for '/'---if, for consistency, there should
> not be a "kernel root", i.e. a filesystem linked to the kernel and
> with the essential utilities, this minimal system being in fact what
> an administrator deals with, including for remote administration,
> when going single us
