For a few days, i have the same problem on several (gentoo) systems. At mount, nfs shares declared in /etc/fstab do not mount anymore. Saying "mount.nfs: Network is unreachable" It used to be, and once logged, i can do "/etc/init.d/netmount restart" to fix the problem. It is NOT a nfs configuration problem. I think the most important change recently was to bring back IPv6 on my local network. Few lines before this failure, i can see the dhcp started on my interface ("Bringing up ..."). It mentions ipv6, but i can't see anything about the ipv4. The last line of this dhcp stuff is "forked to background". Once booted, it seems dhcp has managed to get ipv4, as i can ssh from outside, i can ping, i can remount nfs stuff and such. So my (wild) guess, is that the /etc/init.d/net.lo stuff is returning before network is actually setup, and that it happens only by chance that it works on ipv4-only. It's quick enough for network to be ready before other services start. Could it be ? Do you have any other explanation ? Is there a way to prevent this 'forked in background' behaviour ? Reproducible: Always
Ok, this was indeed linked to ipv6. According to dhcpcd documentation, it forks by default whenever any protocol (ipv4,ipv6) got an address. It happens that ipv6 is quicker (no dhcp here, only RA). I can turn around the problem using this line in /etc/conf.d/net : #dhcpcd_enp0s18="--waitip=4 --waitip=6" # if you want to be specific dhcpcd="--waitip=4 --waitip=6" # for all interfaces (beware that "man dhcpcd" mentions "--waitip 4", while you actually need a '=') Still, i think we got a problem, and my recommendation would be to add "--waitip=4 --waitip=6" by default in /lib/netifrc/net/dhcpcd.sh
