Bug#739721: systemd: NFS shares are not automatically mounted during boot
Somewhere along the line my particular problem with NFS mounts failing to work at boot with systemd has been fixed on all of my systems. I've kept up to date with upgrading Debian packages on all of my systems, and one of these seems to have addressed my problems. But I couldn't say which one it is. Regards, Jim. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739721: systemd: NFS shares are not automatically mounted during boot
Am 31.10.2014 um 01:30 schrieb Jim Barber: My network config on the host is very simple: $ cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 Try changing that to auto eth0 Hi. I have made the change to my network configuration but there is no change in behaviour. The result from the systemctl status command is still the same. $ cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static address 10.1.1.2/24 gateway 10.1.1.1 ethernet-wol g # This is an autoconfigured IPv6 interface iface eth0 inet6 auto And: $ systemctl status -l usr-local-share.mount ● usr-local-share.mount - /usr/local/share Loaded: loaded (/etc/fstab) Active: failed (Result: exit-code) since Mon 2014-11-03 08:12:37 AWST; 20s ago Where: /usr/local/share What: gecko:/usr/local/share Docs: man:fstab(5) man:systemd-fstab-generator(8) Process: 394 ExecMount=/bin/mount -n gecko:/usr/local/share /usr/local/share -t nfs -o _netdev,noatime,nolock,bg,rsize=8192,wsize=8192 (code=exited, status=32) Nov 03 08:12:37 trex mount[394]: mount.nfs: Network is unreachable Nov 03 08:12:37 trex systemd[1]: usr-local-share.mount mount process exited, code=exited status=32 Nov 03 08:12:37 trex systemd[1]: Failed to mount /usr/local/share. Nov 03 08:12:37 trex systemd[1]: Unit usr-local-share.mount entered failed state. On my other i386 system that exhibits the same problem I was already using the 'auto' rather than 'allow-hotplug' directive in the /etc/network/interfaces file. None of my NFS file systems are mounted after boot, but once logged in I can manually mount them. Regards, Jim. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739721: systemd: NFS shares are not automatically mounted during boot
Am 31.10.2014 um 01:30 schrieb Jim Barber: Package: systemd Version: 215-5+b1 Hi. I have a similar problem, and I think it belongs in this bug report. On boot, NFS file systems used to work fine. It was after upgrading from initscripts version 2.88dsf-53.4 to 2.88dsf-57 that all my NFS mounts no longer mount on boot. I was going to report the bug against that package but the change log for it states: Version 2.88dsf-55.1 says: * Skip the mountnfs hook when being triggered by the networking SysV init script and instead use the systemd built-in mechanisms to mount remote file systems. This avoids a deadlock caused by the rpcbind SysV init script depending on $network and the $network LSB facility being provided by the networking SysV init script. (Closes: #746587) So I figured it is likely to be systemd now... Once I log in and run a 'mount -a' all NFS file systems are mounted just fine. I have done a number of boots on this system and also another system and they consistently fail to mount NFS after the upgrade above. This system I am reporting about is an amd64 architecture box, and the other is running an i386 version of Debian. Note that I have a couple of other NFS mounts too, all of which fail in the same way. Two of the mounts from come my main Linux server, and the other mount comes from a Synology NAS. Looking at one of my filesystems I see: $ systemctl status -l usr-local-share.mount ● usr-local-share.mount - /usr/local/share Loaded: loaded (/etc/fstab) Active: failed (Result: exit-code) since Fri 2014-10-31 07:51:39 AWST; 5min ago Where: /usr/local/share What: gecko:/usr/local/share Docs: man:fstab(5) man:systemd-fstab-generator(8) Process: 341 ExecMount=/bin/mount -n gecko:/usr/local/share /usr/local/share -t nfs -o _netdev,noatime,nolock,bg,rsize=8192,wsize=8192 (code=exited, status=32) Oct 31 07:51:39 trex systemd[1]: usr-local-share.mount mount process exited, code=exited status=32 Oct 31 07:51:39 trex mount[341]: mount.nfs: Network is unreachable Oct 31 07:51:39 trex systemd[1]: Failed to mount /usr/local/share. Oct 31 07:51:39 trex systemd[1]: Unit usr-local-share.mount entered failed state. This seems to suggest my network wasn't ready. My network config on the host is very simple: $ cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 Try changing that to auto eth0 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#739721: systemd: NFS shares are not automatically mounted during boot
Package: systemd Version: 215-5+b1 Hi. I have a similar problem, and I think it belongs in this bug report. On boot, NFS file systems used to work fine. It was after upgrading from initscripts version 2.88dsf-53.4 to 2.88dsf-57 that all my NFS mounts no longer mount on boot. I was going to report the bug against that package but the change log for it states: Version 2.88dsf-55.1 says: * Skip the mountnfs hook when being triggered by the networking SysV init script and instead use the systemd built-in mechanisms to mount remote file systems. This avoids a deadlock caused by the rpcbind SysV init script depending on $network and the $network LSB facility being provided by the networking SysV init script. (Closes: #746587) So I figured it is likely to be systemd now... Once I log in and run a 'mount -a' all NFS file systems are mounted just fine. I have done a number of boots on this system and also another system and they consistently fail to mount NFS after the upgrade above. This system I am reporting about is an amd64 architecture box, and the other is running an i386 version of Debian. Note that I have a couple of other NFS mounts too, all of which fail in the same way. Two of the mounts from come my main Linux server, and the other mount comes from a Synology NAS. Looking at one of my filesystems I see: $ systemctl status -l usr-local-share.mount ● usr-local-share.mount - /usr/local/share Loaded: loaded (/etc/fstab) Active: failed (Result: exit-code) since Fri 2014-10-31 07:51:39 AWST; 5min ago Where: /usr/local/share What: gecko:/usr/local/share Docs: man:fstab(5) man:systemd-fstab-generator(8) Process: 341 ExecMount=/bin/mount -n gecko:/usr/local/share /usr/local/share -t nfs -o _netdev,noatime,nolock,bg,rsize=8192,wsize=8192 (code=exited, status=32) Oct 31 07:51:39 trex systemd[1]: usr-local-share.mount mount process exited, code=exited status=32 Oct 31 07:51:39 trex mount[341]: mount.nfs: Network is unreachable Oct 31 07:51:39 trex systemd[1]: Failed to mount /usr/local/share. Oct 31 07:51:39 trex systemd[1]: Unit usr-local-share.mount entered failed state. This seems to suggest my network wasn't ready. My network config on the host is very simple: $ cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet static address 10.1.1.2/24 gateway 10.1.1.1 ethernet-wol g # This is an autoconfigured IPv6 interface iface eth0 inet6 auto The journalctl output suggests my network was up before the NFS filesystems attempted to start as you can see in the first 2 lines of the below followed by the NFS mount attempt: Oct 31 07:51:39 trex kernel: sky2 :03:00.0 eth0: Link is up at 1000 Mbps, full duplex, flow control both Oct 31 07:51:39 trex kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Oct 31 07:51:39 trex kernel: Key type dns_resolver registered Oct 31 07:51:39 trex kernel: NFS: Registering the id_resolver key type Oct 31 07:51:39 trex kernel: Key type id_resolver registered Oct 31 07:51:39 trex kernel: Key type id_legacy registered Oct 31 07:51:39 trex ifup[326]: mount.nfs: Network is unreachable Oct 31 07:51:39 trex systemd[1]: usr-local-share.mount mount process exited, code=exited status=32 Oct 31 07:51:39 trex mount[340]: mount.nfs: Network is unreachable Oct 31 07:51:39 trex mount[341]: mount.nfs: Network is unreachable Oct 31 07:51:39 trex ifup[326]: mount.nfs: Network is unreachable Oct 31 07:51:39 trex systemd[1]: Failed to mount /usr/local/share. At least it looks that way to me. It doesn't say when the IPv4 address was applied, but since it is static, I'd imagine it was immediate. The /etc/fstab file: $ cat /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # file system mount point type options dump pass # / was on /dev/sda2 during installation LABEL=root / ext4 relatime,errors=remount-ro 0 1 # swap was on /dev/sda1 during installation LABEL=swap noneswapsw 0 0 /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/sdb1
Bug#739721: systemd: NFS shares are not automatically mounted during boot
Control: reopen -1 Control: found -1 215-5+b1 On Sun, 14 Sep 2014 17:20:47 +0200 Michael Biebl bi...@debian.org wrote: I'm going to close this bug for now. If you still encounter any issues and you have additional information, please let us know, so we can reopen the bug report. I'm seeing this issue and it seems that others have added more info since the bug was closed here, hence reopening as suggested. For my part I'm seeing it on an up to date Jessie system (apt upgrade this morning) talking to a Wheezy server. My /etc/network/interfaces is: # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet dhcp My /etc/fstab contains: filer01:/srv/exports/music /storage/music nfs defaults,nosuid,intr,rsize=32768,wsize=32768,nfsvers=3,tcp,sec=sys filer01:/srv/exports/media /storage/media nfs defaults,nosuid,intr,rsize=32768,wsize=32768,nfsvers=3,tcp,sec=sys filer02:/srv/exports/mythvideo /var/lib/mythvideo nfs defaults,nosuid,intr,rsize=32768,wsize=32768,nfsvers=3,tcp,sec=sys,actimeo=5 filer02:/srv/exports/mythtv /var/lib/mythtv/recordings nfs defaults,nosuid,intr,rsize=32768,wsize=32768,nfsvers=3,tcp,sec=sys,actimeo=5 On most boots some subset of these do not come up. Before the apt upgrade this morning I was running 208-8 and the failure was only intermittent. Since updating to 215-5+b1 I've been seeing at least one of the mounts failing on each boot. On failure I see: # systemctl status -l var-lib-mythtv-recordings.mount ● var-lib-mythtv-recordings.mount - /var/lib/mythtv/recordings Loaded: loaded (/etc/fstab) Active: failed (Result: exit-code) since Sun 2014-10-19 12:35:04 BST; 3min 53s ago Where: /var/lib/mythtv/recordings What: filer02:/srv/exports/mythtv Docs: man:fstab(5) man:systemd-fstab-generator(8) Process: 428 ExecMount=/bin/mount -n filer02:/srv/exports/mythtv /var/lib/mythtv/recordings -t nfs -o defaults,nosuid,intr,rsize=32768,wsize=32768,nfsvers=3,tcp,sec=sys,actimeo=5 (code=exited, status=32) Oct 19 12:35:04 iranon rpc.statd[454]: Version 1.2.8 starting Oct 19 12:35:04 iranon rpc.statd[454]: Flags: TI-RPC Oct 19 12:35:04 iranon rpc.statd[454]: failed to create RPC listeners, exiting Oct 19 12:35:04 iranon mount[428]: mount.nfs: rpc.statd is not running but is required for remote locking. Oct 19 12:35:04 iranon mount[428]: mount.nfs: Either use '-o nolock' to keep locks local, or start statd. Oct 19 12:35:04 iranon mount[428]: mount.nfs: an incorrect mount option was specified Oct 19 12:35:04 iranon systemd[1]: var-lib-mythtv-recordings.mount mount process exited, code=exited status=32 Oct 19 12:35:04 iranon systemd[1]: Failed to mount /var/lib/mythtv/recordings. Oct 19 12:35:04 iranon systemd[1]: Unit var-lib-mythtv-recordings.mount entered failed state. The output is essentially identical in each case. Running mount -a lets everything come up. rpcbind seems to be running: # systemctl status -l rpcbind.service ● rpcbind.service - LSB: RPC portmapper replacement Loaded: loaded (/etc/init.d/rpcbind) Drop-In: /run/systemd/generator/rpcbind.service.d └─50-rpcbind-$portmap.conf Active: active (running) since Sun 2014-10-19 12:35:04 BST; 4min 29s ago Process: 434 ExecStart=/etc/init.d/rpcbind start (code=exited, status=0/SUCCESS) CGroup: /system.slice/rpcbind.service └─460 /sbin/rpcbind -w Oct 19 12:35:04 iranon rpcbind[434]: Starting rpcbind daemon The timestamps are very close to the mounts -- so perhaps a race? That fits in with the observation in message #77 that this is related to portmap (AIUI rpcbind is the new portmap). Looking over the bug I think I've supplied the sort of information you've generally been looking for, if there's anything else you need though just give a shout. Cheers, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739721: [Pkg-systemd-maintainers] Bug#739721: Bug#739721: Bug#739721: systemd: NFS shares are not automatically mounted during boot
Am 05.07.2014 17:12, schrieb Michael Biebl: Am 22.02.2014 00:16, schrieb John Paul Adrian Glaubitz: On 02/22/2014 12:10 AM, Michael Biebl wrote: Just tried again (with two VMs): The NFS server being a wheezy system, the client system is an up-to-date SID system. Worked like a charm. Ok, it seems to be a local configuration issue then. I will try to pin point the problem and hopefully post the reason and solution soon. Any news? Just another friendly ping. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#739721: [Pkg-systemd-maintainers] Bug#739721: Bug#739721: Bug#739721: systemd: NFS shares are not automatically mounted during boot
Am 22.02.2014 00:16, schrieb John Paul Adrian Glaubitz: On 02/22/2014 12:10 AM, Michael Biebl wrote: Just tried again (with two VMs): The NFS server being a wheezy system, the client system is an up-to-date SID system. Worked like a charm. Ok, it seems to be a local configuration issue then. I will try to pin point the problem and hopefully post the reason and solution soon. Any news? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#739721: [Pkg-systemd-maintainers] Bug#739721: systemd: NFS shares are not automatically mounted during boot
Am 21.02.2014 22:48, schrieb John Paul Adrian Glaubitz: Package: systemd Version: 204-6 Severity: important Hi! I am writing this bug report to raise the awareness about this issue among the Debian systemd maintainers and to make sure it gets resolved before we release Jessie which is supposed to adopt systemd as the default init system. I think it might even be justified to raise the priority to critical but I wanted to avoid systemd being automatically removed from testing. I am not sure though that it is actually a bug in systemd or the unit files it is shipping or in the related NFS packages in question. If it's not a systemd issue, please feel free to reassign the bug to the proper package (e.g. nfs-common). The issue is that NFS mounts which are in the /etc/fstab are no longer being automatically mounted when a fresh installation of Debian Jessie is booted with System V Init replaced with systemd. Thus, one has to issue a mount -a to ensure all filessystems are mounted. The issue has also been reported upstream [1], but seems to have been resolved now in Fedora 20 and Rawhide (see below). On an affected machine, running Debian Jessie (systemd 204), the output of systemctl doesn't provide any useful information: Please include more details about your network setup and the nfs configuration. The nfs shares should be mounted via the nfs ifupdown hooks which worked successfully last time I tested it. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#739721: [Pkg-systemd-maintainers] Bug#739721: systemd: NFS shares are not automatically mounted during boot
Hi Michael! Thanks for your quick reply! On Fri, Feb 21, 2014 at 11:04:46PM +0100, Michael Biebl wrote: Please include more details about your network setup and the nfs configuration. The nfs shares should be mounted via the nfs ifupdown hooks which worked successfully last time I tested it. The machines are all connected through 1 GBit ethernet, however the NFS servers are located in a different virtual network (VLAN) and subnet. All Linux clients have unfiltered access to the servers. The fstab entry for the NFS share currently looks like this: home:/srv/home /home nfs vers=3,nosuid,nodev,intr,tcp,comment=systemd.automount 0 0 The network configuration is static, not using network manager (it has been disabled, in fact) and looks like this on an example client: # The loop back interface auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 160.xx.xx.xx netmask 255.255.255.0 gateway 160.xx.xx.xx where I have replaced some of the numbers with x in this mail. The DNS servers are manually configured, too. Is there anything else you were thinking of? Thanks! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739721: [Pkg-systemd-maintainers] Bug#739721: Bug#739721: systemd: NFS shares are not automatically mounted during boot
Am 21.02.2014 23:22, schrieb John Paul Adrian Glaubitz: Hi Michael! Thanks for your quick reply! On Fri, Feb 21, 2014 at 11:04:46PM +0100, Michael Biebl wrote: Please include more details about your network setup and the nfs configuration. The nfs shares should be mounted via the nfs ifupdown hooks which worked successfully last time I tested it. The machines are all connected through 1 GBit ethernet, however the NFS servers are located in a different virtual network (VLAN) and subnet. All Linux clients have unfiltered access to the servers. The fstab entry for the NFS share currently looks like this: home:/srv/home /home nfs vers=3,nosuid,nodev,intr,tcp,comment=systemd.automount 0 0 The network configuration is static, not using network manager (it has been disabled, in fact) and looks like this on an example client: # The loop back interface auto lo iface lo inet loopback auto eth0 Does changing to allow-hotplug eth0 make a difference? iface eth0 inet static address 160.xx.xx.xx netmask 255.255.255.0 gateway 160.xx.xx.xx where I have replaced some of the numbers with x in this mail. The DNS servers are manually configured, too. Is there anything else you were thinking of? Due to various reasons, remote mounts are currently handled differently on Debian then on Fedora, so you can't compare those two. As said, NFS shares are mounted via the ifupdown hook, so you might check /etc/network/if-up.d/mountnfs and add some debug statements in there to see what's going wrong. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#739721: [Pkg-systemd-maintainers] Bug#739721: Bug#739721: systemd: NFS shares are not automatically mounted during boot
On Fri, Feb 21, 2014 at 11:30:24PM +0100, Michael Biebl wrote: # The loop back interface auto lo iface lo inet loopback auto eth0 Does changing to allow-hotplug eth0 make a difference? Unfortunately, no. The behavior is still the same. iface eth0 inet static address 160.xx.xx.xx netmask 255.255.255.0 gateway 160.xx.xx.xx where I have replaced some of the numbers with x in this mail. The DNS servers are manually configured, too. Is there anything else you were thinking of? Due to various reasons, remote mounts are currently handled differently on Debian then on Fedora, so you can't compare those two. Yes, that's what I was thinking as well. However, I could actually reproduce the problem with Fedora 20 and Rawhide as well before I was reporting the bug here, so I assumed the issue on Fedora was the same. I also talked with Lennart on this regard and he said it's an issue with nfs-utils which wasn't ordering the dependencies correctly, but I wasn't able to track down the origin up the bug yet. All I know is that it happened on Fedora as well and I need to perform a fresh installation of Fedora and test without updates. As said, NFS shares are mounted via the ifupdown hook, so you might check /etc/network/if-up.d/mountnfs and add some debug statements in there to see what's going wrong. That's a good starter, thanks a lot for the heads-up! I'll see if I can find more. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739721: [Pkg-systemd-maintainers] Bug#739721: Bug#739721: systemd: NFS shares are not automatically mounted during boot
Am 21.02.2014 23:40, schrieb John Paul Adrian Glaubitz: On Fri, Feb 21, 2014 at 11:30:24PM +0100, Michael Biebl wrote: # The loop back interface auto lo iface lo inet loopback auto eth0 Does changing to allow-hotplug eth0 make a difference? Unfortunately, no. The behavior is still the same. iface eth0 inet static address 160.xx.xx.xx netmask 255.255.255.0 gateway 160.xx.xx.xx where I have replaced some of the numbers with x in this mail. The DNS servers are manually configured, too. Is there anything else you were thinking of? Due to various reasons, remote mounts are currently handled differently on Debian then on Fedora, so you can't compare those two. Yes, that's what I was thinking as well. However, I could actually reproduce the problem with Fedora 20 and Rawhide as well before I was reporting the bug here, so I assumed the issue on Fedora was the same. I also talked with Lennart on this regard and he said it's an issue with nfs-utils which wasn't ordering the dependencies correctly, but I wasn't able to track down the origin up the bug yet. All I know is that it happened on Fedora as well and I need to perform a fresh installation of Fedora and test without updates. As said, NFS shares are mounted via the ifupdown hook, so you might check /etc/network/if-up.d/mountnfs and add some debug statements in there to see what'sing wrong. That's a good starter, thanks a lot for the heads-up! I'll see if I can find more. Just tried again (with two VMs): The NFS server being a wheezy system, the client system is an up-to-date SID system. Worked like a charm. The client has /etc/network/interfaces: allow-hotplug eth0 iface eth0 inet dhcp /etc/fstab 192.168.178.86:/srv/nfs /nfs nfs auto 0 0 → systemctl status nfs.mount nfs-common.service rpcbind.service ifup@eth0.service nfs.mount - /nfs Loaded: loaded (/etc/fstab) Active: active (mounted) since Sa 2014-02-22 00:03:46 CET; 4min 43s ago Where: /nfs What: 192.168.178.86:/srv/nfs nfs-common.service - LSB: NFS support files common to client and server Loaded: loaded (/etc/init.d/nfs-common) Active: active (running) since Sa 2014-02-22 00:03:28 CET; 5min ago Process: 345 ExecStart=/etc/init.d/nfs-common start (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/nfs-common.service ├─394 /sbin/rpc.statd └─496 /usr/sbin/rpc.idmapd Feb 22 00:03:27 debian systemd[1]: Starting LSB: NFS support files common to client and server... Feb 22 00:03:27 debian rpc.statd[394]: Version 1.2.8 starting Feb 22 00:03:27 debian sm-notify[398]: Version 1.2.8 starting Feb 22 00:03:28 debian systemd[1]: Started LSB: NFS support files common to client and server. Feb 22 00:03:30 debian systemd[1]: Started LSB: NFS support files common to client and server. rpcbind.service - LSB: RPC portmapper replacement Loaded: loaded (/etc/init.d/rpcbind) Active: active (running) since Sa 2014-02-22 00:03:27 CET; 5min ago Process: 253 ExecStart=/etc/init.d/rpcbind start (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/rpcbind.service └─337 /sbin/rpcbind -w Feb 22 00:03:27 debian systemd[1]: Starting LSB: RPC portmapper replacement... Feb 22 00:03:27 debian systemd[1]: Started LSB: RPC portmapper replacement. Feb 22 00:03:30 debian systemd[1]: Started LSB: RPC portmapper replacement. ifup@eth0.service - ifup for eth0 Loaded: loaded (/lib/systemd/system/ifup@.service; static) Active: active (exited) since Sa 2014-02-22 00:03:28 CET; 5min ago Process: 535 ExecStart=/sbin/ifup --allow=hotplug %I (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/ifup@.service/ifup@eth0.service └─1022 dhclient -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0 Feb 22 00:03:29 debian ifup[535]: DHCPOFFER from 192.168.178.1 Feb 22 00:03:30 debian dhclient[578]: DHCPACK from 192.168.178.1 Feb 22 00:03:30 debian ifup[535]: DHCPACK from 192.168.178.1 Feb 22 00:03:30 debian dhclient[578]: bound to 192.168.178.100 -- renewal in 357099 seconds. Feb 22 00:03:30 debian ifup[535]: bound to 192.168.178.100 -- renewal in 357099 seconds. Feb 22 00:03:30 debian ifup[535]: Starting rpcbind (via systemctl): rpcbind.service. Feb 22 00:03:30 debian ifup[535]: Starting nfs-common (via systemctl): nfs-common.service. Feb 22 00:03:46 debian ifup[535]: Filesystem mounted on /dev/shm; setting up compatibility bind mount. ... (warning). Feb 22 00:03:46 debian ifup[535]: Please remove this mount from /etc/fstab; it is no longer needed, and it is preventing completion of the transition to /run/shm. ... (warning). Feb 22 00:03:46 debian ifup[535]: mount: special device /run/shm does not exist -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#739721: [Pkg-systemd-maintainers] Bug#739721: Bug#739721: systemd: NFS shares are not automatically mounted during boot
severity 739721 normal thanks On 02/22/2014 12:10 AM, Michael Biebl wrote: Just tried again (with two VMs): The NFS server being a wheezy system, the client system is an up-to-date SID system. Worked like a charm. Ok, it seems to be a local configuration issue then. I will try to pin point the problem and hopefully post the reason and solution soon. Meanwhile, I will lower the severity. Thanks for your input. Highly appreciated! -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
