08.03.2016 17:06, Greg Freemyer пишет:
On Tue, Mar 8, 2016 at 1:20 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
08.03.2016 03:09, Greg Freemyer пишет:
On Mon, Mar 7, 2016 at 6:18 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
On 03/07/2016 01:49 PM, Andrei Borzenkov wrote:
07.03.2016 21:41, Greg Freemyer пишет:
The destination does not exist (it used to).
But ignoring that rather big issue, why does a failed mount of a tertiary filesystem cause systemd to crash and burn.
Because all mount points in /etc/fstab are mandatory unless marked as optional. There is nothing new - countless number of times I had to "fix" server that stayed in "rescue mode" because someone removed access to SAN storage but forgot to edit fstab. Without any systemd involved.
+1.
Or, RTFM, use "nofail" ... maybe
Anton,
I have read the fstab entry many times. I've also admin'ed servers for years (or decades).
I somehow missed:
== If you have an fstab entry with the default "auto" mount and "fail" behavior and the mount fails, then mail processing will be disallowed. Further, all ssh access will be terminated. And for good measure any X-Windows GUI will also be terminated.
Your computer will fall-back to minimally functional systemd maintenance mode and all troubleshooting must occur exclusively via the console. ==
I am not sure how you managed to reach this state and I would be very interested in seeing logs on debug level (boot with systemd.log_level=debug added to and "quiet" removed from kernel command line, reproduce problem and upload "journalctl -b" somewhere). Your system should have stayed in rescue mode from the very beginning (i.e. it would not enter normal run level 3/5).
Andrei,
Generating the logs is easy.
Would you like me to just boot and let the system sit for 15 minutes, OR go ahead and trigger maintenance mode earlier?
If it is easy, do both :) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org