# [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.Last edited by b0nafide on Sat Dec 10, 2016 1:51 am; edited 2 times in total

----------

## krinn

 *b0nafide wrote:*   

> 
> 
> 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. 
> 
> 

 

hostname depend on rc, for openrc it's set in /etc/conf.d/hostname (and domainename), i'm not sure it still use /etc/hostname, what i'm sure, is that i don't have that file myself.

while hostname is for showing your own system hostname, rpcinfo is showing network system name, as such, it should read them from /etc/hosts

remember that dhcp could also set hostname.

try giving it nfsvers=3,vers=3 

 *Quote:*   

>        vers=n         This option is an alternative to the nfsvers option.  It is included for compatibility with other
> 
>                       operating systems

 

so it is state as compatibility and its handling might differ from system or nfs-utils version, the usual crap when something gets more or less deprecated with a blurry state.

in doubt, use nfsvers=3,vers=3 (it won't kill you anyway no?)

----------

## b0nafide

Thanks for the insight   :Very Happy:   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

 *b0nafide wrote:*   

> ...I compiled a kernel with oldnoconfig from the 32bit kernel...

 

This was my mistake. Running make menuconfig without a previous .config and adding the kernel options I wanted fixed this. 

Somehow oldnoconfig broke networking.

----------

