OpenWrt Forum Archive

Topic: install kmod-fs-nfs fails (12.09-rc1, r34185)

The content of this topic has been archived on 20 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi,

I just updated my tl-wr1043nd with 12.09-rc1, r34185 and now the nfs kernel modules fail to install:

root@Stimpy:~# opkg install kmod-fs-nfs
Installing kmod-fs-nfs (3.3.8-1) to root...
Downloading http://downloads.openwrt.org/attitude_a … r71xx.ipk.
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-fs-nfs:
*      kernel (= 3.3.8-1-6c06ba2494c9c458b747d6a40b2cc970) *
* opkg_install_cmd: Cannot install package kmod-fs-nfs.

If I force installation (with --force-depends) and then try to mount a previously working nfs mount, it just hangs at mounting:

root@Stimpy:~# mount.nfs -vvv -o nolock 192.168.2.4:/srv/data/OS/openwrt/ /mnt/
mount.nfs: timeout set for Sun Mar 24 12:42:28 2013
mount.nfs: trying text-based options 'nolock,vers=4,addr=192.168.2.4,clientaddr=192.168.2.1'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'nolock,addr=192.168.2.4'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.2.4 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.2.4 prog 100005 vers 3 prot UDP port 46956
^C

I tried changing the exported dir to nfs v4 like some other systems I use internally but to no avail.

I see some more posts and a bug similar to my mount error (https://dev.openwrt.org/ticket/12935).

Did I do something wrong or did the NFS client / kernel module broke somewhere between 12.09-beta and 12.09-rc1?

-- Ralf

No, you just installed an incompatible kmod.

To elaborate on jow's answer: you need to use the package from AArc1. The link above is beta.

opkg update
opkg install kmod-fs-nfs

Interresting, I completely missed that. I adjusted opkg.conf to point to the correct packages and did an "opkg update", "opkg list-upgradable" and upgraded packages that could (only tcpdump).

After that I did "opkg install kmod-fs-nfs nfs-utils" and the mount still failed. After reboot, the router didn't come back up. Only thing I could do was recover, but could not find out the problem so I went for a "firstboot" and reboot. Then the router did come up.

Configured the danm thing (thank you backups!) and tested the nfs mounting which now works like a charm!

Thanks for the help Jow and robthebrew.

I have a patch for this I'll share tomorrow.

Hint: all the kernel modules have the wrong deps. Here's the extract from ~/src/openwrt/trunk/package/kernel/modulesfs.mk file.

It also supports NFS with kerberos too (if you choose to install nfsv-4-common) - only if mit-krb5 wasn't broken in openwrt. I'm going to make a hemidal package for openwrt too if I have time.

define KernelPackage/fs-nfs
  SUBMENU:=$(FS_MENU)
  TITLE:=NFS filesystem support
  DEPENDS:=+kmod-fs-nfs-common
  KCONFIG:= \
    CONFIG_NFS_FS \
    CONFIG_NFS_USE_LEGACY_DNS=y \
    CONFIG_NFS_USE_NEW_IDMAPPER=y \
    CONFIG_NFS_V3_ACL=n \
    CONFIG_NFS_ACL_SUPPORT=n \
    CONFIG_NFS_SWAP=y
  FILES:= $(LINUX_DIR)/fs/nfs/nfs.ko \
    $(LINUX_DIR)/fs/nfs/nfsv3.ko 
  AUTOLOAD:=$(call AutoLoad,40,nfs nfsv3)
endef

define KernelPackage/fs-nfs/description
 Kernel module for NFS support
endef

$(eval $(call KernelPackage,fs-nfs))


define KernelPackage/fs-nfs-common
  SUBMENU:=$(FS_MENU)
  TITLE:=Common NFS filesystem modules
  KCONFIG:= \
    CONFIG_LOCKD \
    CONFIG_SUNRPC \
    CONFIG_SUNRPC_SWAP=y \
    CONFIG_NFS_COMMON=y \
    CONFIG_NFS_ACL_SUPPORT=n
  FILES:= \
    $(LINUX_DIR)/fs/lockd/lockd.ko \
    $(LINUX_DIR)/net/sunrpc/sunrpc.ko 
  AUTOLOAD:=$(call AutoLoad,30,sunrpc lockd)
endef

$(eval $(call KernelPackage,fs-nfs-common))


define KernelPackage/fs-nfs-common-v4
  SUBMENU:=$(FS_MENU)
  TITLE:=Common NFS V4 filesystem modules
  KCONFIG+=\
    CONFIG_SUNRPC_GSS\
    CONFIG_NFS_V4 \
    CONFIG_KEYS=y \
    CONFIG_RPCSEC_GSS_KRB5 
  DEPENDS:= +kmod-fs-nfs-common +kmod-fs-nfs +kmod-crypto-manager \
          +kmod-crypto-cts +kmod-crypto-cbc +kmod-crypto-ecb \
      +kmod-crypto-hmac +kmod-crypto-sha1 +kmod-crypto-aes \
      +kmod-crypto-des +kmod-crypto-md5 +kmod-crypto-arc4
  FILES+=$(LINUX_DIR)/net/sunrpc/auth_gss/auth_rpcgss.ko \
         $(LINUX_DIR)/fs/nfs/nfsv4.ko \
       $(LINUX_DIR)/net/sunrpc/auth_gss/rpcsec_gss_krb5.ko
  AUTOLOAD=$(call AutoLoad,30,auth_rpcgss rpcsec_gss_krb5 nfsv4)
endef

define KernelPackage/fs-nfs-common-v4/description
 Kernel modules for NFS V4  kernel support
endef

$(eval $(call KernelPackage,fs-nfs-common-v4))


define KernelPackage/fs-nfsd
  SUBMENU:=$(FS_MENU)
  TITLE:=NFS kernel server support
  DEPENDS:=+kmod-fs-nfs-common +kmod-fs-exportfs +kmod-nfs-common-v4
  KCONFIG:= \
    CONFIG_NFSD \
    CONFIG_NFSD_FAULT_INJECTION=n \
    CONFIG_NFSD_V2_ACL=n \
    CONFIG_NFSD_V3_ACL=n \
    CONFIG_NFSD_V3=y \
    CONFIG_NFSD_V4=y
  FILES:=$(LINUX_DIR)/fs/nfsd/nfsd.ko
  AUTOLOAD:=$(call AutoLoad,40,nfsd)
endef

define KernelPackage/fs-nfsd/description
 Kernel module for NFS kernel server support
endef

$(eval $(call KernelPackage,fs-nfsd))

I boot nfsv3 in my 3.6 meg image (yes needs portmap), then I can load in the modules into memory. zramfs helps, but it's somewhat broken in it's current version (yes patch coming for that too).

I could be wrong and the kernel could make a nfs.ko (for nfs3 only), but if you want 3 and 4 there is also a nfsv3.ko that needs to be installed. I think this is required in any case for everything to work.

Cheers.

update: oh and also you need to make a few more cryptoapi kernel module package definitions wink You will also be needing a custom kernel with swap support and a other few goodies to make nfs happy.

You get the benefit of swaping your PC's /tmpfs mount containing a linux swapfile in memory for your router, in effect beefing up your routers memory to run more apps (though there is network latency involved - do this if you have a decent router with gigabit lan)

(Last edited by hojuruku on 4 Apr 2013, 19:14)

The discussion might have continued from here.