SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
My onboard NIC (eth0) broke and I put in a PCI device. It shows up as eth3 and network is up and running. But during the boot process I noticed that the IP's of my nfs clients couldn't get resolved anymore, even after configuring the network with pkgtools again. Looking in /etc/inet1.conf I found IP and gateway as eth0. So I entered both to eth3 there and rebooted. No more error message about non resolving nfs clients but the clients still can't connect anymore.
Since the onboard NIC is disabled in BIOS why does the PCI NIC show up as eth3? Originally it shows up as eth0 but gets renamed during boot:
Quote:
[ 7.936433] 8139too 0000:05:06.0: eth0: RealTek RTL8139 at 0xa000, ...
[ 8.671118] udevd[1190]: renamed network interface eth0 to eth3
How can I prevent the NIC from getting renamed? Is there another way to make nfs working again? Any help appreciated.
As with 14.0, the system udev rules now reside in /lib/udev/rules.d/ instead
of /etc/udev/rules.d/ in older versions. There should never be a reason
to edit anything in /lib/udev/rules.d/, so if you think you have a case
where this is required, either you're wrong or it needs to be addressed in
the upstream source. However, you can override default rules by placing
one with an identical name inside /etc/udev/rules.d/ The rules files in
/etc/udev/rules.d/ are still intended to (maybe) be edited as needed by
local system administrators, and as such, the rules for optical and network
devices will still be placed there.
Speaking of udev, pay particular attention to 70-persistent-net.rules and
70-persistent-cd.rules in /etc/udev/rules.d/ -- these two are automatically
generated by the system. If you remove, add, and/or replace some hardware
(specifically network cards and/or optical drives) in a machine, you will
probably need to edit one or both of the rules files mentioned above (or
just remove them and reboot to create new ones).
After further investigation it looks like nfs is running but not exporting the shares.
This is /etc/exports
Quote:
# See exports(5) for a description.
# This file contains a list of all directories exported to other computers.
# It is used by rpc.nfsd and rpc.mountd.
/mnt/volume1 borg(rw,no_subtree_check) chaotica(rw,no_subtree_check)
/mnt/volume2 borg(rw,no_subtree_check) chaotica(rw,no_subtree_check)
/mnt/volume3 chaotica(rw,no_subtree_check)
/mnt/volume4 borg(rw,no_subtree_check) chaotica(rw,no_subtree_check)
/mnt/sda2/home2 chaotica(rw,no_subtree_check)
Starting nfsd
Quote:
Starting NFS server daemons:
/usr/sbin/exportfs -r
/usr/sbin/rpc.rquotad
/usr/sbin/rpc.nfsd 8
/usr/sbin/rpc.mountd
[ 7064.198964] nfsd: last server has exited, flushing export cache
[ 7065.319045] svc: failed to register lockdv1 RPC service (errno 97).
[ 7065.319157] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
[ 7065.319190] NFSD: unable to find recovery directory /var/lib/nfs/v4recovery
[ 7065.319197] NFSD: starting 90-second grace period
There is no /var/lib/nfs/v4recovery. Maybe that's the issue?
Everything worked fine with the onboard NIC before. I don't understand what's wrong here.
Whenever I install Slackware on a machine - the first thing I do is to comment out the first few lines of /etc/rc.d/rc.nfsd - thus:
Code:
# if [ ! -r /etc/exports ]; then # no config file, exit:
# exit
# elif ! grep -v '^#' /etc/exports | grep '/' 1> /dev/null 2> /dev/null ; then
# exit # no uncommented shares in /etc/exports
# fi
Then I make it executable (chmod a+x /etc/rc.d/rc.nfsd)
And finally: /etc/rc.d/rc.nfsd start
The reason I comment it out is that if I have a usb-disk connected to the machine at start-up, I nfs-export it in /etc/rc.d/rc.local (after checking with 'blkid -U' that it is actually present ...
The whole carbunkle goes something like this:
Code:
df -a | grep -wq '/usb$' || { # proceed if not mounted, /usb is my mountpoint
usbid="xxxxxxxxxxxxxxxxxxxxxxxxx" # whatever is the blkid of the usb-disk
usbdev="$(blkid -U $usbid)" || usbdev=""
test "x$usbdev" = x || { # so it's present :-)
if mount -o rw,noatime $usbdev /usb; then echo ":: $usbdev mounted on /usb ..."
else echo "-- failure mounting $usbdev ..."; fi
}
unset usbid usbdev # the environmentalists are gonna luv me!
}
df -a | grep -wq '/usb$' && { # ok, it _is_ mounted
ok=no
exportfs | ( while read a b; do
test "x$a" = x/usb && { ok=yes; break; }
done )
test $ok = no && { # not exported, so do it
exportfs -iv -o rw,insecure,no_root_squash 192.168.1.0/24:/usb
}
unset ok
}
I shouldn't really have to comment-out the top lines as indicated, I've just always done it that way - and it always works ...
Last edited by perbh; 07-11-2013 at 09:31 PM.
Reason: typos
ml4711 pointed me into the right direction. How could I miss using the exportsf command for checking? Exporting works.
So I checked on the client side what happens when mounting the shares: No route to host! What I found then is so embarrassing: wrong IP address. After configuring the new NIC I didn't check the settings again. It turned out that the host got a DHCP address from the router although I configured a static IP. To my surprise NetworkManager was running which I never use, maybe I started it by accident, no idea. Disabling did the trick.
I think I learned my lesson checking the basic things first.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.