Created attachment 1105279 [details] /var/log/messages The NFS share in my fstab fails to mount on boot, but can be mounted just fine after the system comes up. `systemctl enable NetworkManager-wait-online.service' didn't help, as Network Manager still thinks it's come online before my ethernet device has been configured. I'm running version 1.0.6-8.fc23. > [root@CHWorkstation ~]# cat /etc/fstab | grep chnas > chnas.chd.hubick.com:/mnt/chpool/chdata /home/hubick/chd/chdata nfs defaults,hard,sync,nosuid 0 0 > [root@CHWorkstation ~]# cat /etc/sysconfig/network-scripts/ifcfg-Wired_connection_1 > HWADDR=A0:36:9F:57:04:0A > TYPE=Ethernet > BOOTPROTO=dhcp > DEFROUTE=yes > IPV4_FAILURE_FATAL=yes > IPV6INIT=no > NAME="Wired connection 1" > UUID=e39572ec-a3c1-42bf-9e62-a8b914a1fcce > ONBOOT=yes > PEERDNS=yes > PEERROUTES=yes > AUTOCONNECT_PRIORITY=1 Full log attached, but I think the relevant parts are: > Dec 12 19:27:59 CHWorkstation NetworkManager[960]: <info> (ens6): new Ethernet device (carrier: OFF, driver: 'ixgbe', ifindex: 2) > Dec 12 19:27:59 CHWorkstation NetworkManager[960]: <info> (ens6): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] > Dec 12 19:27:59 CHWorkstation kernel: IPv6: ADDRCONF(NETDEV_UP): ens6: link is not ready > Dec 12 19:28:04 CHWorkstation NetworkManager[960]: <info> startup complete > Dec 12 19:28:04 CHWorkstation systemd: Started Network Manager Wait Online. > Dec 12 19:28:05 CHWorkstation systemd: Reached target Network is Online. > Dec 12 19:28:05 CHWorkstation systemd: Starting Network is Online. > Dec 12 19:28:05 CHWorkstation systemd: Mounting /home/hubick/chd/chdata... > Dec 12 19:28:05 CHWorkstation mount: mount.nfs: Failed to resolve server chnas.chd.hubick.com: No address associated with hostname > Dec 12 19:28:05 CHWorkstation systemd: home-hubick-chd-chdata.mount: Mount process exited, code=exited status=32 > Dec 12 19:28:05 CHWorkstation systemd: Failed to mount /home/hubick/chd/chdata. > Dec 12 19:28:05 CHWorkstation systemd: Dependency failed for Remote File Systems. > Dec 12 19:28:05 CHWorkstation kernel: ixgbe 0000:02:00.0 ens6: NIC Link is Up 10 Gbps, Flow Control: None > Dec 12 19:28:05 CHWorkstation kernel: IPv6: ADDRCONF(NETDEV_CHANGE): ens6: link becomes ready > Dec 12 19:28:05 CHWorkstation NetworkManager[960]: <info> (ens6): link connected > Dec 12 19:28:05 CHWorkstation NetworkManager[960]: <info> (ens6): device state change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40] > Dec 12 19:28:05 CHWorkstation NetworkManager[960]: <info> Auto-activating connection 'Wired connection 1'. > Dec 12 19:28:05 CHWorkstation NetworkManager[960]: <info> (ens6): Activation: starting connection 'Wired connection 1' (e39572ec-a3c1-42bf-9e62-a8b914a1fcce) > Dec 12 19:28:05 CHWorkstation NetworkManager[960]: <info> (ens6): device state change: disconnected -> prepare (reason 'none') [30 40 0] > Dec 12 19:28:05 CHWorkstation NetworkManager[960]: <info> NetworkManager state is now CONNECTING > Dec 12 19:28:05 CHWorkstation NetworkManager[960]: <info> (ens6): device state change: prepare -> config (reason 'none') [40 50 0] When logging in after boot, either a `mount -a` or `systemctl start home-hubick-chd-chdata.mount` will succeed. Could this be related to Bug 1034921 or Bug 1054364 or Bug 1054364 (all supposedly fixed)? Much Thanks!
Sorry, the last potential duplicate should have been Bug 1062704.
Adding the fstab option 'comment=systemd.mount' didn't fix this for me, but then also adding '_netdev' did. > [root@CHWorkstation ~]# cat /etc/fstab | grep chnas > chnas.chd.hubick.com:/mnt/chpool/chdata /home/hubick/chd/chdata nfs defaults,hard,sync,nosuid,_netdev,comment=systemd.mount 0 0 I can understand 'comment=systemd.automount', but shouldn't 'comment=systemd.mount' be the default for fstab entries? And isn't '_netdev' a safe assumption for NFS mounts? i.e. Shouldn't this all have Just Worked?
(In reply to Chris Hubick from comment #2) > Adding the fstab option 'comment=systemd.mount' didn't fix this for me, but > then also adding '_netdev' did. I lied. It made it work once in a while, but still less than half the time. Some kind of race condition then I'm guessing :-(
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.