First reboot after upgrading to glibc-2.23-r1 and all nfs mounts failed with mount.nfs protocol not supported. rebuilding of nfs-utils fails: /bin/sh ../../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -Wall -Wextra -Wstrict-prototypes -pipe -march=native -O2 -pipe -Wl,-O1 -Wl,--as-needed -o exportfs exportfs.o ../../support/export/libexport.a ../../support/nfs/libnfs.a ../../support/misc/libmisc.a -lwrap libtool: link: x86_64-pc-linux-gnu-gcc -Wall -Wextra -Wstrict-prototypes -pipe -march=native -O2 -pipe -Wl,-O1 -o exportfs exportfs.o -Wl,--as-needed ../../support/export/libexport.a ../../support/nfs/libnfs.a ../../support/misc/libmisc.a -lwrap Makefile:505: recipe for target 'exportfs' failed make[2]: Leaving directory '/var/tmp/paludis/net-fs-nfs-utils-1.3.3/work/nfs-utils-1.3.3/utils/exportfs' Makefile:449: recipe for target 'all-recursive' failed make[1]: Leaving directory '/var/tmp/paludis/net-fs-nfs-utils-1.3.3/work/nfs-utils-1.3.3/utils' Makefile:473: recipe for target 'all-recursive' failed ../../support/nfs/libnfs.a(nfsexport.o): In function `exp_unexp': nfsexport.c:(.text+0x167): undefined reference to `major' nfsexport.c:(.text+0x17f): undefined reference to `minor' collect2: error: ld returned 1 exit status make[2]: *** [exportfs] Error 1
Is there a work around. This is a major loss of functionality as nfs shares cannot be connected without a rebuild of nfs-utils.
runtime breakage is different from buildtime breakage. the sysmacros.h header change should have 0 impact at runtime behavior. please attach the full build log from your glibc-2.23 build, or at least `emerge -pv glibc`.
r sys-libs/glibc:2.2::gentoo 2.23-r1 to ::installed replacing 2.23-r1 -audit -caps -debug -gd (-hardened) (multilib) nscd -profile rpc (-selinux) -suid -systemtap -vanilla build_options: -dwarf_compress -optional_tests -trace work=tidyup Reasons: target
BTW I downgraded to glibc-2.22-r4 and nfs mount worked immediately. Back to 2.23-r1 and broken again so it is definitely a runtime regression. If I could rebuild nfs-utils I could get further. I already rebuilt all the dependencies of nfs-utils but that did not help.
build breakage is fixed by this: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6db2e20c272323a10ea3afe3741f8c282bfa2d6a but that still doesn't explain the runtime failure.
I rebuilt nfs-utils with the nfs-utils-1.3.3-sysmacros.patch successfully. That did not fix the runtime breakage sudo mount -t nfs -o nolock MyBookLiveDuo:/nfs/music /home/harrisl/music mount.nfs: Protocol not supported
more details sudo mount -v -t nfs -o nolock MyBookLiveDuo:/nfs/music /home/harrisl/music mount.nfs: timeout set for Thu Apr 14 08:03:11 2016 mount.nfs: trying text-based options 'nolock,vers=4.2,addr=192.168.1.136,clientaddr=192.168.1.217' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'nolock,vers=4.1,addr=192.168.1.136,clientaddr=192.168.1.217' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'nolock,vers=4.0,addr=192.168.1.136,clientaddr=192.168.1.217' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'nolock,addr=192.168.1.136' mount.nfs: prog 100003, trying vers=16, prot=6 mount.nfs: trying 192.168.1.136 prog 100003 vers 16 prot TCP port 2049 mount.nfs: portmap query retrying: RPC: Program/version mismatch mount.nfs: prog 100003, trying vers=16, prot=17 mount.nfs: trying 192.168.1.136 prog 100003 vers 16 prot UDP port 2049 mount.nfs: portmap query failed: RPC: Program/version mismatch mount.nfs: Protocol not supported if I force nfs vers=2 then the mount works. Neither v3 or v4 work with glibc-2.23-r1
the fact that vers=2 mounts are working but 3 and 4 not should be a good clue as to the cause.
More info: sudo mount -v -t nfs -o vers=3,nolock MyBookLiveDuo:/nfs/music /home/harrisl/music works but leaving the vers out fails. So something is broken in the code that tries and determines the nfs version to use.
More testing. The new ebuild didn't change anything. I also tried with -bundled-libs but that fails in the apploader. I went back to the ::gentoo ebuild and that is giving the same failure when launching as vmware from console. I am running successfully only when starting from a new scope using systemd-run. I am going the post the log for the successful run.
Created attachment 430526 [details] applog from systemd-run start on ::gentoo ebuild
Created attachment 430528 [details] ui.log from successful start using ::gentoo ebuild and systemd-run
posted to wrong bug
any better luck with 2.25?
(In reply to Andreas K. Hüttel from comment #14) > any better luck with 2.25? no response
no longer a problem. Upgrades must of fixed it
