https://bugzilla.novell.com/show_bug.cgi?id=875373 https://bugzilla.novell.com/show_bug.cgi?id=875373#c1 Thomas Blume changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |systemd-maintainers@suse.de | |, thomas.blume@suse.com AssignedTo|systemd-maintainers@suse.de |thomas.blume@suse.com --- Comment #1 from Thomas Blume 2014-04-28 08:31:44 UTC --- The purpose of making /var/run a symlink to run is FHS compliance. For details, see the FHS compliance section at: http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard Seems you are overwriting this symlink when providing /var as a symlink to the encrypted home. So you should be aware that your system might not be FHS compliant with this setup. However, systemd-tmpfiles-setup.service has a dependency to local-fs.target. This includes the mount of /home. Still, cryptsetup.target starts only after local-fs.target. It could work if we make systemd-tmpfiles-setup.service depending on cryptsetup.target. But this requires that cryptsetup.target doesn't depend on any directory that systemd-tmpfiles-setup.service creates. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=875373 https://bugzilla.novell.com/show_bug.cgi?id=875373#c3 --- Comment #3 from Christian Boltz 2014-04-28 13:34:18 CEST --- (In reply to comment #1) # ls -l /var /var/run lrwxrwxrwx 1 root root 13 25. Jul 2009 /var -> home/sys-var// lrwxrwxrwx 1 root root 4 26. Apr 22:50 /var/run -> /run/ So my /var/run _is_ a symlink as expected - but it needs /home mounted to be available. (AFAIK the FHS does not forbid that /var is a symlink, right? ;-) (In reply to comment #2)

Partly agree ... IMHIO this service requires a split that is a [...]

Can we please change the order so that "mount all file systems" comes first (before creating the /var/run symlink)? (But: the /var/run symlink should never be deleted, therefore I wonder why it needs to be created ;-) BTW: This bug seems to be a race condition - today's boot worked without problems... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=875373 https://bugzilla.novell.com/show_bug.cgi?id=875373#c5 --- Comment #5 from Thomas Blume 2014-04-28 13:33:16 UTC --- I still see a problem with ordering here. /home is a directory not required in the init process, but /var (resp. /run) is. Making /var depending on the availability of /home is IMHO not quite correct. In order to fullfill this, you will need to make /home available as early as the mounts required for the init process. In order to do so, you could use the rd.luks parameters to enable the crypsetup of /home from within the initrd. (see details at: http://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator...) This should be early enough to not conflict with the systemd-tmpfiles-setup.service. However, if you really want to make sure that the crypt setup is done before the tmpfiles get created, you need to add a dependency in in /usr/lib/systemd/system/systemd-tmpfiles-setup.service, e.g. change: After=systemd-readahead-collect.service systemd-readahead-replay.service local-fs.target into: After=systemd-readahead-collect.service systemd-readahead-replay.service local-fs.target cryptsetup.target Still, this can only be a custom setup, because if a user is not using crypted devices, cryptsetup.target wouldn't be active and this dependency should fail. Can you try wheter either of these suggestions work? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=875373 https://bugzilla.novell.com/show_bug.cgi?id=875373#c7 Thomas Blume changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |suse-beta@cboltz.de --- Comment #7 from Thomas Blume 2014-05-05 12:40:43 UTC ---

Nevertheless, I still think local-fs.target should include "all encrypted filesystems mounted".

The problem is that already the mount of encrypted file systems requires the presence of (/var)/run. systemd-tmpfiles-setup.service creates amongst others the directory: /run/systemd/ask-password (see /usr/lib/tmpfiles.d/systemd.conf). This directory is used in turn by systemd password agents that ask for passwords of encrypted file systems (see details at http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents/). So, you will have a cyclic dependency between the encrypted filesystem that provide /var/run (and the symlink to /run) and the password agent that needs /run, in order to get the password for mounting the file system. Interestingly it seems to work on your system as you apparently have no problem getting a password prompt for your /home. However, I guess this is because there is already a directory /run/systemd/ask-password before your /home gets mounted (this is also the case when mounting /home from within the initrd). Still, this is not really the way how things should be. You are welcome to provide any idea how to avoid such cyclic dependencies, but currently I don't see any possibility. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=875373 https://bugzilla.novell.com/show_bug.cgi?id=875373#c9 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |suse-beta@cboltz.de --- Comment #9 from Dr. Werner Fink 2014-05-06 06:42:32 UTC --- (In reply to comment #8) Hmm ... could you try to change the openvpn service that is to make it depend on local-fs.target? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=875373 https://bugzilla.novell.com/show_bug.cgi?id=875373#c11 Christian Boltz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|suse-beta@cboltz.de | --- Comment #11 from Christian Boltz 2014-05-18 21:32:04 CEST --- (In reply to comment #10)

...

Directories in /run are not a problem - /run is part of my (not encrypted) / partition and therefore available from the beginning.

Ok, this explains why it works on your machine. But what happens if /run is not part of /?

/run is never part of / - it's a tmpfs (IIRC since some releases) and therefore always available.

Your comment already includes a cyclic dependency: [...] This cycle could IMHO only be solved by an additional target that depends on both local-fs.target and cryptsetup.target.

Basically yes - something like a all-filesystems.target. In practise, the better way would probably be: - rename local-fs.target to local-fs-unencrypted.target - create a new local-fs.target that includes local-fs-unencrypted.target and cryptsetup.target This way would have the advantage that all the units that depend on local-fs.target are "automagically" fixed. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.