On Sat, 2014-11-08 at 00:37 +0000, Simon McVittie wrote: [...] > On 07/11/14 20:23, Simon McVittie wrote: > > Bug M1, reported by Matthew Grant, present in 1:1.2.8-6: "NFS mounts > > from /etc/fstab do not work". (What symptoms? What error messages?) This > > one might be related to NFS entries in /etc/fstab that don't have _netdev. > > The symptom that *I* get on some boots is these messages in the NFS > client's Journal/syslog (my test-case for NFS is mounting one machine's > /srv onto the other machine's /srv): > > mount[309]: mount.nfs: Network is unreachable > systemd[1]: srv.mount mount process exited, code=exited status=32 > systemd[1]: Failed to mount /srv. > systemd[1]: Dependency failed for Remote File Systems. This line seems to indicate that /srv was a dependency for 'Remote File Systems', i.e. it has correctly been recognised as remote. > systemd[1]: Unit srv.mount entered failed state. > > ... because systemd tries to mount /srv shortly before the DHCP client > comes up, which isn't going to work well. > > Does that resemble what you get? > > The patched packages do not improve this; neither do they make it worse. > > systemd is meant to recognise network mounts in fstab automatically (it > knows about cifs, smbfs, sshfs, ncpfs, ncp, nfs, nfs4, gfs, gfs2, > glusterfs) so it should't be necessary to have _netdev in the options > field, but perhaps that isn't working correctly for whatever reason? Or > perhaps waiting for network-online.target is not necessarily sufficient > with some network connectivity setups? (My test systems are using > ifupdown and DHCP, not NetworkManager or systemd-networkd or anything.) But network-online.target doesn't seem to have any integration with ifupdown, i.e. there is no ifupdown-wait-online.service. > > Bug M2, reported by Matthew Grant, present in 1:1.2.8-6: "NFS exports > > also fail due to rpcbind not starting before nfs-common and nfs- > > kernel-server". > > I have not been able to reproduce this, with or without native systemd > units. > > One possible reason why this could happen sometimes is that > /etc/init.d/rpcbind has "Provides: rpcbind", which seems ... redundant. > I would expect it to have "Provides: $portmap" in order to be ordered > before nfs-common, which has "Required-Start: $portmap". So would I. But this should result in breakage under sysvinit too. > If that is in error, cloning an rpcbind bug would seem appropriate. [...] Yes. Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once.
Attachment:
signature.asc
Description: This is a digitally signed message part