You are not logged in.
Hello,
since the kmod/udev updates last weekend the nfs module is not automatically inserted into the kernel anymore. I'm mounting NFS share on my notebook which was working without any manual module loading before last weekend. Now when trying to start netfs it results in
mount.nfs: No such deviceI tried adding the nfs module into the modules array in rc.conf which gives a 'failed' notification upon booting for "Loading User-Specified Modules"
MODULES=(acpi-cpufreq eeepc-laptop nfs)lsmod|grep nfsonly lists nfs_acl and not nfs. I can insert the module manually via 'modprobe nfs' and mounting works again.
Is this a kmod issue? Can anyone help me with this?
Regards
UPDATE: Adding the nfs module in my mkinitcpio.conf seems to fix the issue. It would be still interesting to know if that's some sort of new bug.
Last edited by unull (2012-01-27 14:11:53)
Offline
I didn't think of trying mkinitcpio.conf. I'll have to try that since putting /etc/rc.conf isn't working for me, either. I'm hoping it's a kmod issue that gets worked out over the weekend...
Offline
Are you autostarting the daemons?
You're just jealous because the voices only talk to me.
Offline
Are you autostarting the daemons?
I'm starting netfs only through my netcfg profiles through Post-Up hooks. Might that be the issue?
Last edited by unull (2012-01-28 12:27:42)
Offline
No - that's how I do it too, and everything's working as before i.e. module is autoloaded as required.
I know that doesn't particularly help you, just answering your question about netcfg.
Last edited by tomk (2012-01-28 12:51:25)
Offline
Please post the output of 'modprobe -c'
Offline
I upgraded to kmod 4-2 and I can see some verbose info while booting, however, /var/log/boot shows just the usual stuff.
Offline
???
Usually the NFS module is loaded in /etc/mkinitcpio.conf along with the net hook, but usually this is only needed for a diskless client kernel compilation.
The only thing I ever need since the nfs module is loaded automatically is to place rpcbind & nfs-common into the daemons section in /etc/rc.conf and I'm able to mount nfs with no problem on every bootup.
I may have to CONSOLE you about your usage of ridiculously easy graphical interfaces...
Look ma, no mouse.
Offline
The only thing I ever need since the nfs module is loaded automatically is to place rpcbind & nfs-common into the daemons section in /etc/rc.conf and I'm able to mount nfs with no problem on every bootup.
Yes, that worked until last week or so but not anymore, as I wrote in my 1st post.
Offline
nomorewindows wrote:The only thing I ever need since the nfs module is loaded automatically is to place rpcbind & nfs-common into the daemons section in /etc/rc.conf and I'm able to mount nfs with no problem on every bootup.
Yes, that worked until last week or so but not anymore, as I wrote in my 1st post.
I'm seeing the same behavior. The mkinitcpio.conf change listed above works for me, FWIW, but that shouldn't be needed here.
I can manually load the module once the system finishes booting, so I wonder if it's a module loading order thing related to rc.conf
Offline
unull wrote:nomorewindows wrote:The only thing I ever need since the nfs module is loaded automatically is to place rpcbind & nfs-common into the daemons section in /etc/rc.conf and I'm able to mount nfs with no problem on every bootup.
Yes, that worked until last week or so but not anymore, as I wrote in my 1st post.
I'm seeing the same behavior. The mkinitcpio.conf change listed above works for me, FWIW, but that shouldn't be needed here.
I can manually load the module once the system finishes booting, so I wonder if it's a module loading order thing related to rc.conf
Please post the other modules you have in rc.conf.
I'm starting to think this is a duplicate of: https://bbs.archlinux.org/viewtopic.php?pid=1051315
If any module in MODULES fail, loading stops. Please go through your modules in rc.conf one at a time and make sure each of them individually loads.
Offline
Please try one of the packages below for your architecture... assuming its the same problem as what I linked in the above thread, this should fix it...
i686: http://dev.archlinux.org/~dreisner/kmod … pkg.tar.xz
x86_64: http://dev.archlinux.org/~dreisner/kmod … pkg.tar.xz
Offline
hmm... just re-read some of this, and I noticed that you (unull, that is) said you're only using netfs, a detail that I mssed when I posted above. I'm using nfs-common and rpcbind as well, as recommended by the wiki - maybe you should try that.
Offline
I will be able to test the packages tonight, but in the meantime I can add some information about my situation.
Prior to this update, I was not manually loading the nfs module from rc.conf. In fact, I loaded no modules from rc.conf at all. I was instead using the init scripts rpcbind and nfs-common. nfs-common *should* load the module on its own, if you have a non-empty /etc/exports file (I do).
After this update and subsequent reboot, I found that NFS had "stopped working." In my cause I use autofs and not direct entries in /etc/fstab; automount was complaining of the following:
>> mount.nfs4: No such device
At this point I googled around and realized that the nfs module was not loaded. I was then able to stop autofs and restart nfs-common, which loaded the module. After this I restarted autofs, which resulted in the expected behavior (everything worked).
Thinking that adding 'nfs' to MODULES in rc.conf might do the trick, I made that change and rebooted - but I found that I was in the exact same situation as before. I had to manually restart nfs-common again and the module was loaded. And that finally lead me to this thread, and the successful workaround by loading nfs in the initial ramdisk as configured in mkinitcpio.conf.
I can report another possibly related situation: one of my (non-root) partitions in this system uses btrfs. Prior to this update, I had done nothing special to make this work; it simply mounted properly on boot, as any other filesystem in fstab does.
However, I now find that I must manually load the btrfs module in order for the filesystem to be mounted. I have added this to rc.conf (but have not yet tested whether it resolves the problem). I should note that the wiki documentation for btrfs implies that you *should* need to load the module from rc.conf, but I had never found that to be true in practice prior to this update.
Offline
However, I now find that I must manually load the btrfs module in order for the filesystem to be mounted
This isn't even a function of mount -- the kernel itself will insert FS modules for you (via the internal function path __request_module => call_usermodehelper_fns)
# lsmod | grep btrfs
# mount LABEL=foo /mnt
# lsmod | grep btrfs
btrfs 610736 1
zlib_deflate 20340 1 btrfs
libcrc32c 1034 1 btrfsOffline
JeremyT wrote:However, I now find that I must manually load the btrfs module in order for the filesystem to be mounted
This isn't even a function of mount -- the kernel itself will insert FS modules for you (via the internal function path __request_module => call_usermodehelper_fns)
# lsmod | grep btrfs # mount LABEL=foo /mnt # lsmod | grep btrfs btrfs 610736 1 zlib_deflate 20340 1 btrfs libcrc32c 1034 1 btrfs
That is the expected behavior... but it surely does not work for me. ext4 mounted just fine.
I have had minimal time to investigate this, I just thought I would mention it since it coincided with my nfs trouble and I wondered if it was related.
Offline
Offline
Anyone able to test the kmod-4-3 packages I posted? Would like to ship this to the masses before kmod 5 is released (because I'm sure it's going to have different demons...)
I have the same problem as unull. However, the package you posted did not correct the issue on my system; the nfs module is still not being loaded automatically.
However, when I restart the "nfs-common" daemon, I get the following error:
:: Stopping rpc.idmapd daemon [DONE]
:: Stopping rpc.statd daemon [DONE]
:: Starting rpc.statd daemon [DONE]
:: Mounting pipefs filesystem [BUSY]
ERROR: could not insert 'nfs': Is a directory
[DONE]
:: Starting rpc.idmapd daemon [DONE]Any thoughts?
Offline
Anyone able to test the kmod-4-3 packages I posted? Would like to ship this to the masses before kmod 5 is released (because I'm sure it's going to have different demons...)
I installed your kmod package, however I saw no change in behavior.
Offline
falconindy wrote:Anyone able to test the kmod-4-3 packages I posted? Would like to ship this to the masses before kmod 5 is released (because I'm sure it's going to have different demons...)
I installed your kmod package, however I saw no change in behavior.
Thanks, but I'm not interested in your unrelated mount oddity.
Offline
JeremyT wrote:falconindy wrote:Anyone able to test the kmod-4-3 packages I posted? Would like to ship this to the masses before kmod 5 is released (because I'm sure it's going to have different demons...)
I installed your kmod package, however I saw no change in behavior.
Thanks, but I'm not interested in your unrelated mount oddity.
I am describing the NFS module's failure to load without adding it to the initial ramdisk, which I thought your kmod was supposed to address. Perhaps I have misunderstood its purpose.
Offline
falconindy wrote:Anyone able to test the kmod-4-3 packages I posted? Would like to ship this to the masses before kmod 5 is released (because I'm sure it's going to have different demons...)
I have the same problem as unull. However, the package you posted did not correct the issue on my system; the nfs module is still not being loaded automatically.
However, when I restart the "nfs-common" daemon, I get the following error:
:: Stopping rpc.idmapd daemon [DONE] :: Stopping rpc.statd daemon [DONE] :: Starting rpc.statd daemon [DONE] :: Mounting pipefs filesystem [BUSY] ERROR: could not insert 'nfs': Is a directory [DONE] :: Starting rpc.idmapd daemon [DONE]Any thoughts?
Yeah. Its trying to resolve /var/lib/nfs as a module. Its fixed in git, though I'm not sure this is a change I can easily backport.
Offline
The new kmod package doesn't solve the issue for me, too. I only have
MODULES=(acpi-cpufreq eeepc-laptop ipv6)in rc.conf. Each of those load properly and work.
Offline