<p>Sorry for dropping the list...</p>
<p>On Apr 2, 2012 4:04 PM, &quot;Colin Guthrie&quot; &lt;<a href="mailto:colin@guthr.ie">colin@guthr.ie</a>&gt; wrote:<br>
&gt;<br>
&gt; &#39;Twas brillig, and Tom Gundersen at 02/04/12 14:51 did gyre and gimble:<br>
&gt; &gt;&gt; &gt; In our discussions, I was concerned that remote-fs.target was a<br>
&gt; &gt;&gt; &gt; pre-requisite of systemd-user-sessions.service as on my machine, my<br>
&gt; &gt;&gt; &gt; /mnt/scratch NFS mount delayed the display manager startup when it has<br>
&gt; &gt;&gt; &gt; absolutely nothing to do with logins.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Why should remote fs be ordered before user login at all?<br>
&gt; &gt;<br>
&gt; &gt; Never mind this comment, I was being daft. The other question still holds.<br>
&gt;<br>
&gt; :) Yeah for /home on NFS is the reason which I presume you realised :D</p>
<p>Indeed, and this is what I<br>
am using...</p>
<p>&gt; &gt;&gt; I have been using automount to achieve similar behaviour to what you<br>
&gt; &gt; want. Might that be an option?<br>
&gt;<br>
&gt; Well it&#39;s an option, but still not one that is currently handled gracefully.</p>
<p>I agree, it can and should be improved, though the user experience is not too bad at the moment.</p>
<p>&gt; If the /home is now an NFS automount (or /home/$USER itself), then the<br>
&gt; network still needs to be available for the automount to work.</p>
<p>Currently, it is up to the admin to select which mounts should block boot. In other words, to get the feature you describe I would mark the partitions that are needed for login as regular mounts and the ones that are not needed as automounts.</p>

<p>However, we can do better, and this is what I do: mark all partitions as automount and let kdm start while /home is being fscked or mounted over nfs.</p>
<p>&gt; If prefdm starts and lets users login before the network is ready, will<br>
&gt; the automount simply block until the network is available?</p>
<p>Correct, this would have to be improved before the general user would be happy with home on automount. Currently kdm blocks with a black screen until home is mounted. In an ideal world, kdm would first of all show fsck progress from systemd, and second of all make reads from /home asynchronous (so pictures would appear once home is mounted). Maybe it would also make sense for kdm to not allow the user to log in until some info (such as previous session) is available, in which case kdm should block with a &quot;please wait&quot; message. At any rate, imho gdm/kdm should decide how to act without systemd having to be involved.</p>

<p>&gt; If so then it&#39;s a reasonable workaround IMO, but it may still be<br>
&gt; desirable to get the mounts available first (e.g. to look up faces or<br>
&gt; find users&#39; last login session type in the DM itself etc.)<br>
&gt;<br>
&gt; Otherwise the DM may only be half ready - e.g. hang while reading the<br>
&gt; users&#39; homedir (and waiting for the mount).</p>
<p>See above.</p>
<p>&gt; So maybe the fixed mounts are still desirable.</p>
<p>I agree, at least in the short/medium term. Though I am not sure if we need an extra target for this, the admin could simply leave the /home partition as not  automounted.</p>
<p>Just my two cents :-) </p>
<p>Cheers,</p>
<p>Tom</p>