Lennart Poettering [2015-02-11 17:05 +0100]: > Actually, the fact that the unit changes directly from "dead" to > "mounted" is interesting. The unit does not go through "mounting", > which means that it's not the unit that is invoking the /bin/mount > command for this but something else.. Do you see anything about this > in the logs?
Thanks for that hint, that's really useful. Indeed it looks much better after a successful boot (full log at http://people.canonical.com/~pitti/tmp/debug-fstab-unmount/journal-works.txt): | # egrep 'f865.*device|home.mount' journal-works.txt | Feb 11 22:55:59 donald systemd[1]: Installed new job home.mount/start as 49 | Feb 11 22:55:59 donald systemd[1]: Installed new job dev-disk-by\x2duuid-f86539b0\x2d3a1b\x2d4372\x2d83b0\x2dacdd029ade68.device/start as 48 | Feb 11 22:55:59 donald systemd[1]: Expecting device dev-disk-by\x2duuid-f86539b0\x2d3a1b\x2d4372\x2d83b0\x2dacdd029ade68.device... | Feb 11 22:56:00 donald systemd[1]: dev-disk-by\x2duuid-f86539b0\x2d3a1b\x2d4372\x2d83b0\x2dacdd029ade68.device changed dead -> plugged | Feb 11 22:56:00 donald systemd[1]: Job dev-disk-by\x2duuid-f86539b0\x2d3a1b\x2d4372\x2d83b0\x2dacdd029ade68.device/start finished, result=done | Feb 11 22:56:02 donald systemd[1]: home.mount changed dead -> mounting | Feb 11 22:56:02 donald systemd[1]: home.mount changed mounting -> mounting-done | Feb 11 22:56:02 donald systemd[1]: Job home.mount/start finished, result=done | Feb 11 22:56:02 donald systemd[1]: Child 530 belongs to home.mount | Feb 11 22:56:02 donald systemd[1]: home.mount mount process exited, code=exited status=0 | Feb 11 22:56:02 donald systemd[1]: home.mount changed mounting-done -> mounted | Feb 11 22:56:04 donald systemd[1335]: dev-disk-by\x2duuid-f86539b0\x2d3a1b\x2d4372\x2d83b0\x2dacdd029ade68.device changed dead -> plugged | Feb 11 22:56:04 donald systemd[1335]: home.mount changed dead -> mounted So now I have a nice comparison. I replaced /bin/mount and /bin/umount with a wrapper which logs the calls to "mount"; nothing calls umount during boot, and in the successful case I see systemd doing all the mounts, in the failing case they are completely missing. That indicates that the other thing that's messing with the mounts is not calling the binary but the mount() syscall. So I'll go and search for things which mount() stuff around during boot. I figure this is something Debian/Ubuntu specific as it would certainly have popped up someplac else by now. > Maybe fallout from the GPT auto-discovery? if you turn that off, does > it work then? No, I already disabled both the GPT and the EFI generators, no change. (And they don't produce actual units either, seems for me the fstab generator trumps them). Thanks! Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
