Bug#763652: boot failure: similar case, possible explanation

[chrysn]

hello,

i've encountered a very similar situation (log files attached), tricky
to debug because booting would only occasionally fail.

it is my current impression that things fail when there are nested mount
points, and the outer mount point needs a time-consuming fsck.

nikolaus, is that plausible with your system?

i can't debug this too more right now because it's exceeding the
scheduled downtime, but hope to be able to provide more information on
request.

best regards
chrysn
-------------- next part --------------
  UNIT                         LOAD   ACTIVE SUB    DESCRIPTION
? systemd-modules-load.service loaded failed failed Load Kernel Modules

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
-------------- next part --------------
/dev/poseidon/core-root		/		ext3	defaults		0 1

/dev/md0			/boot		ext3	defaults		0 2

proc				/proc		proc	defaults		0 0

/dev/noraid/core-swap		none		swap	sw			0 0

/dev/noraid/core-tmp		/tmp		ext3    rw,nosuid,nodev		0 2
/dev/poseidon/core-var		/var		ext3    rw,nosuid,nodev		0 2
/dev/poseidon/core-usr		/usr		ext3	rw,nodev		0 2
/dev/poseidon/core-usr-local	/usr/local	ext3	rw,nodev		0 2

/dev/poseidon/core-home	/home		ext3	acl		0 2
/dev/poseidon-btrfsraid/daten-3tb-a /home/shared/daten-3tb/ btrfs nosuid,nodev,subvol=data 0 2
/dev/poseidon-btrfsraid/daten-3tb-a /mnt/daten-3tb-root/ btrfs nosuid,nodev 0 2


cgroup          /cgroup         cgroup  defaults        0       0

/dev/poseidon/sid-root		/srv/lxc/poseidon-sid/rootfs/	ext3	user_xattr	0 1
/dev/poseidon/print-root	/srv/lxc/poseidon-print/rootfs/	ext4	defaults	0 1
/dev/poseidon/backup-root	/srv/lxc/poseidon-backup/rootfs/	ext4	defaults	0 1
/dev/poseidon/backup-home-users	/srv/lxc/poseidon-backup/rootfs/home/users/	ext4	defaults	0 1
/dev/poseidon/mailbox-root	/srv/lxc/poseidon-mailbox/rootfs/	ext4	defaults	0 1
/dev/poseidon/mailbox-home-users	/srv/lxc/poseidon-mailbox/rootfs/home/users/	ext4	defaults	0 1
/dev/poseidon/mailhub-root	/srv/lxc/poseidon-mailhub/rootfs/	ext4	defaults	0 1
/dev/poseidon/albert-photos /srv/lxc/poseidon-sid/rootfs/home/users/adengg/photos/ ext4 defaults 0 1
/dev/poseidon/albert-data /srv/lxc/poseidon-sid/rootfs/home/users/adengg/data/ ext4 defaults 0 1
/dev/poseidon/sid-var-cache-squiddebproxy /srv/lxc/poseidon-sid/rootfs/var/cache/squid-deb-proxy ext4 defaults 0 1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: systemd-analyze-dump.xz
Type: application/x-xz
Size: 36176 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20150422/57ab8b2e/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: journalctl-alb.xz
Type: application/x-xz
Size: 13584 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20150422/57ab8b2e/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20150422/57ab8b2e/attachment-0001.sig>