On 03/05/15 21:26, Leslie Rhorer wrote:
I am having a persistent problem. I have an array system that is
having problems. Obviously, that needs to get fixed, but it is
taking quite some time to find the root cause. In the meantime, the
array is not bootable, so it is not needed during the initrd phase of
the startup. Previously, this made little difference, but in Jessie,
the system refuses to transition to Runlevel 2 while any mount target
in fstab is failing. This is a real problem, because the system is
headless, and getting the system working from the console is a huge
pain. I don't think this behavior was present prior to Jessie. In
any case, does anyone have any recommendations on how to get the
system to boot at least to the point where ssh is available even if
the array assembly fails?
By default, all entries in /etc/fstab are "auto" (mount automatically at
boot) and "fail" (treat failure to mount as an error condition).
sysvinit mounts those filesystems by invoking "mount -a", and doesn't
actually pay any attention to the exit status of that command. Even if
half the world doesn't get mounted, sysvinit will stumble on with its
attempt to bring up the system.
systemd, on the other hand, treats "auto,fail" filesystems as being
Required (i.e. a hard dependency) by "local-fs.target", which is a
dependency of the various "normal operation" targets analogous to
sysvinit runlevels 2-5. Any mount failure among those filesystems will
result in systemd refusing to complete the boot sequence, as something
important is clearly missing.
There are two ways to resolve this by editing /etc/fstab:
1. Mark the affected filesystems 'noauto' while they are out of
commission; this prevents them from being automatically mounted.
2. Mark the affected filesystems 'nofail' while they are out of
commission; this reduces the dependency from "Requires" (hard
dependency) to "Wants" (soft dependency i.e. systemd will try to mount
them, but will not treat a failure to do so as preventing the boot
sequence from completing).
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: https://lists.debian.org/[email protected]
