[solved] mount.nfs sending nfsv3 null packets to server

[b0nafide]

Many years ago with dracut 038 I created an initramfs to assist me with mounting a read-only root file system as nfs. Everything back then worked well and I had no problems mounting nfs as root. I have not had to think about that initramfs for a long time.

Recently someone brought in a machine to the shop that was pure efi, no legacy boot modes available in the bios. I've spent a lot of time getting my various tools booting over the network, so I resolved to support network booting over efi. Indeed, some time later I had ipxe.efi in place and booting various 64bit efi stub enabled kernels and other wimboot images. So far so good.

For a custom image of mine built with gentoo, the old kernel and initramfs were built with 32bit support only for maximum compatibility. The plan was to migrate everything to 64bit.

So I did a fresh install of amd64 in a chroot and copied over the world file and make.conf with the correct march and cflags and got everything emerged and upgraded to recent versions. I compiled a kernel with oldnoconfig from the 32bit kernel (with 64bit support and appropriate processor options) proceeded to create the initramfs with dracut 044 and got it booting!

Everything seemed great. Except that the mount.nfs operation was timing out. I don't support nfsv4 in my configuration, just nfsv3... I pass vers=3,nolock as a mount option (it's exported read-only)

Delving into it a bit further over the course of several days, including rpcdebug and looking at nfs statistics on the server, I found that rpcinfo -p returned the expected results on both the client and the server however trying to mount.nfs caused the client to send nfsv3 null packets to the server only, which naturally did not respond.

All of the other clients I have tested with mount nfs successfully. When I run nfsstat on the server I can see 'null' under "Server nfs v3:" increment for each mount.nfs attempt by the buggy client.
When I set 'rpcdebug -m rpc -s all' mount.nfs produce output that shows a successful transmission and then sleeping and retrying, without any error.

The client that cannot mount can ping the server. That client can also mount cifs without an issue.

At one point I was thinking that maybe I had to go back a kernel versions or several but I can mount nfs from a recent systemrescuecd image as well and that's a higher kernel version than the one I'm trying with. I've done a meld comparison of .configs from a known working kernel and the one that isn't working on my client. Nothing seems to stand out that could be effecting nfs.

Someone on the Arch linux nfs howto mentioned that if the server doesn't have a proper hostname, the mount.nfs operation will time out. Perhaps the opposite is true? I notice when I do an 'rpcinfo -b portmapper 3' the buggy client only reports it's ipv4 address, not a hostname, however /etc/hostname exists and is readable. uname -a reports the correct hostname.

Anyways, this is mostly a rant, I don't have logs from my client readily available just quite yet.

[krinn]

[b0nafide]

Thanks for the insight unfortunately I can't dive back into this problem until Monday or so.

[b0nafide]

Unfortunately, none of the approaches I tried worked to mount nfs with my custom kernel and initramfs. I still kept getting the same strange behavior of null nfsv3 paclets being sent by the client only. One of these good days I may try again.

I ended up going a different route to achieve the same results, which was to customize a systemrescuecd image to my liking and booting that from the network instead.

[b0nafide]