I recently upgraded two of our linux machines from RH5.0 to RH6.0. After the upgrade procedure we found that neither of the machines was accepting NFS mounts from any machine. After a little poking and prodding, I discovered that nfs was no longer being started at boot time and was no longer included in rc3.d, 4.d, or 5.d. After I inserted entries for nfs in those directories, the nfs server once again began functioning normally. Not sure if this is a bug, but it certainly was a nuisance! - Owen Steinert
*** Bug 3250 has been marked as a duplicate of this bug. *** Upgrading a machine from 5.2 to 6.0 doesn't preserve nfs starting at boot.
*** Bug 3250 has been marked as a duplicate of this bug. *** Upgrading a machine from 5.2 to 6.0 doesn't preserve nfs starting at boot. ------- Additional Comments From jbj 06/03/99 16:12 ------- *** This bug has been marked as a duplicate of 3241 ***
I have verified this to happen on a test machine in our lab. I did a stock 5.0 install with nfs emabled in runlevels 3,4,5. I then did a upgrade to 6.0. Upon inspection of the runlevels that nfs was enabled in I found that only runlevel 4 was enabled so therefore there was a change when it should not have.
*** Bug 3397 has been marked as a duplicate of this bug. *** I have several machines formerly running RH 5.2 On a few, I did a full install to RH 6.0 On the others, I did an upgrade install. When the installs/upgrades were complete, we discovered that the systems that were "upgraded" were no longer able to serve NFS mounts. In particular, when another client tried to mount one of the upgraded system's exported filesystems, the following error was returned: mount: RPC: Program not registered Tracking things down further, we discovered that mountd was running properly on the machines that were "installed", but missing (i.e. not running) on the machines that were "upgraded". Here's the output of rpcinfo for a machine that was "installed": /usr/sbin/rpcinfo -p node8 program vers proto port 100000 2 tcp 111 rpcbind 100000 2 udp 111 rpcbind 100024 1 udp 987 status 100024 1 tcp 989 status 100011 1 udp 998 rquotad 100011 2 udp 998 rquotad 100005 1 udp 1008 mountd 100005 1 tcp 1010 mountd 100005 2 udp 1013 mountd 100005 2 tcp 1015 mountd 100005 3 udp 1018 mountd 100005 3 tcp 1020 mountd 100003 2 udp 2049 nfs 100021 1 udp 1026 nlockmgr 100021 3 udp 1026 nlockmgr 100021 1 tcp 1024 nlockmgr 100021 3 tcp 1024 nlockmgr 300019 1 tcp 624 amd 300019 1 udp 625 amd And, here's the rpcinfo output of a machine that was "upgraded": /usr/sbin/rpcinfo -p node3 program vers proto port 100000 2 tcp 111 rpcbind 100000 2 udp 111 rpcbind 100021 1 udp 1024 nlockmgr 100021 3 udp 1024 nlockmgr 100021 1 tcp 1024 nlockmgr 100021 3 tcp 1024 nlockmgr Please note that before the upgrades/installs all of our machines were running properly as NFS servers. Following the upgrades/installs we confirmed that the proper entries were in /etc/fstab and /etc/exports. This problem has been consistently observed on several formerly working, but now "upgraded" to 6.0 systems. So, what's wrong? And, why should upgrading disable the ability to serve NFS? Thanks, Alan Broder ajb
This is an rpm problem; knfsd obsoleted nfs-server, but nfs-server saw that it was the last version of itself being installed, so it removed the symlinks. Fixed in knfsd-1.4.7-7.