At boot time the start of rpcbind fails when module ipv6 isn't availble (by autoload feature), therefore NFS mounts will not come up. At the moment, the whole system is build with USE="-ipv6". But the ebuild of rpcbind don't provide a ipv6-useflag to disable this. If i provide a ipv6 module after boot, a simple 'mount -a' will make things come up in a proper way. The module is loaded by this.
Created attachment 268777 [details, diff] rpcbind-0.2.0.ebuild.ipv6.patch you can try this patch to the ebuild, although you really should get out of the stone age and support IPv6 and no, rpcbind itself does not attempt to load any module. any autoloading is due to other configuration in your system.
Dear SpanKY, thanks for support and your proposal, i'll check out your hint suggested by the patch asap. Of course we all should get out of the stone age, but it seems to me that will be easier to introduce IPv6 outside in the internet than in a large companies intranet ;) It's no great deal to enable ipv6 in the kernel despite of it's not used yet, but as long as Gentoo provides a global common use-flag to enable/disable ipv6 this should by respected as much as possible. I disabled it for security to avoid open backdoors, because no one will take care of ip6 configuration of applications yet. An if rpcbind in fact isn't designed to be compiled or usable without the IPv6 stack available, it may be marked inside the ebuild. I'm still a ebuild newbie but i notice some maybe appropriate inside the app-emulation/lxc ebuild: A declaration of CONFIG_CHECK="~foo" and corresponding error message declarations ERROR_foo="bar"
Dear SpanKY, I have verified that the Makefile is patched through the prepare step. But the resulting rcpbind still fails at startup with an FATAL: cannot create socket for udp6 This message is from rpcbind.c, L. 308. I havn't figure it out yet, but at some part of the code a #ifdef INET6 clause is missing. This seems to cause something ipv6 related in the sockets to set up. Maybe the automatic binding to "::1"?
After adding IPV6 support to the kernel as static, the error messages of rpcbind disappears. But the netmounts don't happen, however. It turns out, that the core reason for this is a issue in the /etc/init.d/netmount script. I fully confirm the situation if found described in bug #362331 a few minutes before. If i disable the the test for the portmap service or change it to test for the rpcbind, the nfs keywords are not stripped from the file system type list. I'll continue to figure out, if this "FATAL" error messages of rpcbind in case of absence of the ipv6 stack are not only cosmetical problems.
Dear SpanKY, now, after get /etc/init.d/netmount working with rpcbind, it turns out that the *unmodified* rpcbind-0.2.0 will output the two messages FATAL: cannot create socket for {udp,tcp}6 if the kernel have *no* support for ip6 included, but will be started nevertheless with the ip4-sockets opened. # netstat -tulpn | grep rpcbind tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 6480/rpcbind udp 0 0 0.0.0.0:111 0.0.0.0:* 6480/rpcbind udp 0 0 0.0.0.0:715 0.0.0.0:* 6480/rpcbind All nfs are up and available, and i can't see any other regression in functionality, yet. From that, the error messages may be treated as "cosmetic". Because the work derived so far -- to chain the use flag -ipv6 as a -DINET6 -- will not fix the issue because of upstream source code quality, you as the Gentoo maintainer may decide to close the bug as "won't fix here in Gentoo", may point the rpcbind maintainer to this. And the efforts of the Gentoo team should be focused on #362331. Thank you for quick support and suggestions Guido
*** Bug 415021 has been marked as a duplicate of this bug. ***
Thanks for your efforts. Let's call this UPSTREAM as it's not something we can handle.
Hi Sam, it's OK to clean up the gruft here. But for the log: Even 10 years later, we don't use IPv6 -- but at least, still Gentoo ;) Guido
