Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 548196 - net-fs/nfs-utils - mount.nfs fails on boot after switching to ipv6 (and only on boot)
Summary: net-fs/nfs-utils - mount.nfs fails on boot after switching to ipv6 (and only ...
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-30 00:12 UTC by Thomas Capricelli
Modified: 2021-08-19 19:08 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Capricelli 2015-04-30 00:12:23 UTC
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
Comment 1 Thomas Capricelli 2015-04-30 00:44:21 UTC
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