Description of problem: I have my system set up with an encrypted volume, and an sshfs mount depending on the same, i.e. (simplified): (/etc/fstab) /dev/mapper/luks-<UUID> /crypt ext4 defaults 1 2 server:/mount /mount fuse.sshfs idmap=file,uidfile=/crypt/uidmap,gidfile=/crypt/gidmap 0 0 (/root/.ssh/config) Host server User user IdentityFile /crypt/id_rsa As a result of this configuration, I am unable to boot the machine; systemd insists on trying (and failing) to mount the sshfs file systems before the network is started and before even other mounts (e.g. /home, /var) are up, much less /crypt. Version-Release number of selected component (if applicable): systemd-44-21.fc17.x86_64 How reproducible: Always Steps to Reproduce: 1. Set up volumes as described. 2. Try to boot computer. Actual results: systemd drops into emergency mode and cannot be recovered; only / is mounted (not e.g. /home, /var) and networking is not started. Attempting to start cryptsetup.target or cryptsetup@luks-<UUID>.service sometimes asks for passphrase and sometimes hangs, and tends to self-deactivate. Attempting to start *.mount tends to hang. Attempting to start network fails, kills shell, and goes back into emergency mode. (Basically, it is impossible to boot the system, even with manual coaxing, at this point.) Expected results: Asks for crypt volume passphrase; boots successfully, with sshfs files systems mounted. Additional informatoin: The most obvious bug seems to be that networking is not being required for sshfs mounts. Figuring out what key ssh wants might be a bit much, although there should also already be a dependency on the crypt volume from the idmap options. (Just having the networking dependency probably is enough that it would work, even if the crypt volume dependency is missing, as networking probably does not start before the local file systems are mounted.) Possibly related to bug 591836.
systemd cannot magically determine that the network needs to be up for a mount. mount uses "_netdev" in the mount options to declare that. If you use that in the mount options this part of the issue should be fixed, as systemd honours that. Determining the other dependency automatically is not feasible either. We cannot really add support for parsing the options for a gazillion of userspace file systems to systemd to determine the deps. A possible work-around could be to write a .mount unit for this entry and specify the dep explicitly, but that's not particularly sexy.
So, how about adding something similar for other dependencies? The simplest would be e.g. '_dep=crypt.mount' that could depend on anything systemctl knows about; '_netdev' could then be an alias for '_dep=network.target' (guessing that is the equivalent dep, anyway; might be wrong). I think that would be less painful than writing a series of .mount's when more than one FS is affected.
That's a good idea I guess! *** This bug has been marked as a duplicate of bug 812826 ***