On Mon, Mar 7, 2016 at 12:01 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
On 03/07/2016 10:50 AM, Per Jessen wrote:
Greg Freemyer wrote:
I got a journal dump before and after the failure (journalctl -xb > log). About 500 lines of logs added in the post failure log.
I went through and fixed every minor complaint until my server would run smoothly.
Commenting out this line from fstab was the "fix".
=== #/srv_new/portal_backup_container /home/portal_backup/portal_backup ext4 loop 0 0 ===
So something is not quite right about "/srv_new/portal_backup_container". What happens if you try to mount it manually?
The big thing for me that makes this a pretty major bug is that the above line for some reason made my server unusable as a server. Something about it caused systemd to revert to maintenance mode 15 minutes after boot.
Most probably failure to mount that filesystem - I've seen that before.
Quite possibly so. Trying to mount it manually might show what is going on.
On the face of it, it looks like its trying to do do a "bind" mount (q.v. man page) but without the "--bind". After all the "/srv/.." part is not a device. Does it actually exist? Does the destination exist?
Hmm... 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. If no one knows, I'll just open this as a bugzilla. BTW; This isn't a --bind mount. It is a loopback mount. I'm supposed to have a large file at /srv_new/portal_backup_container that itself is a filesystem that I loopback mount. I know that is strange, but it is needed to overcome an issue with the NFS mount options setup my my cloud provider. Inside the loopback mount I have total control of the mount options. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org