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 continue to be
> handled more or less the way it is now: fsck before anything else,
> remount or reboot depending on the result, then carry on with startup.
>
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 user (for me "real" root i.e. kernel user; when the
user level filesystems are mounted, the "root" is more an administrative
superuser). All in all, to "allow" some devices to appear
(to be usable) is a kind of manipulation of the namespace too. The rc
stuff will then mount other things, including perhaps an "user level"
'/', upon this initial root, perhaps shadowing what is in it (or this
initial root being then mounted read-only as /rescue when going
multi-user).
This is not totally orthogonal to the discussion, since the problem
of filesystems that one wants to be mounted if they are available but
without panicking the system if they are not, is a particular case,
specially when the system is physically out of reach, of being
still able to fix and administrate if something goes wrong.
But this is indeed more involved than what is discussed here.
FWIW,
--
Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
http://kertex.kergis.com/
http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
