[opensuse] Mounting NFS Shares During Boot
Hi, It seems like a routine thing, but I can't find any information. Given an NFS share (server-side) and an fstab entry (client-side) that can be successfully mounted manually, what must be done on the cliet side to get that share mounted during reboot? Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz wrote:
Hi,
It seems like a routine thing, but I can't find any information.
Given an NFS share (server-side) and an fstab entry (client-side) that can be successfully mounted manually, what must be done on the cliet side to get that share mounted during reboot?
From my /etc/fstab:
fileserver:/some/where /else/where nfs rsize=8192,wsize=8192 0 0 /Per -- Per Jessen, Zürich (19.6°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday May 12 2009, Per Jessen wrote:
Randall R Schulz wrote:
Hi,
It seems like a routine thing, but I can't find any information.
Given an NFS share (server-side) and an fstab entry (client-side) that can be successfully mounted manually, what must be done on the cliet side to get that share mounted during reboot?
From my /etc/fstab:
fileserver:/some/where /else/where nfs rsize=8192,wsize=8192 0 0
I don't think this is about the obvious. Naurally, I have a suitable entry in /etc/fstab. Perhaps I should clarify: fstab-supported monting works if done manually after reboot is complete and I can log in.
/Per
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz wrote:
On Tuesday May 12 2009, Per Jessen wrote:
Randall R Schulz wrote:
Hi,
It seems like a routine thing, but I can't find any information.
Given an NFS share (server-side) and an fstab entry (client-side) that can be successfully mounted manually, what must be done on the cliet side to get that share mounted during reboot?
From my /etc/fstab:
fileserver:/some/where /else/where nfs rsize=8192,wsize=8192 0 0
I don't think this is about the obvious. Naurally, I have a suitable entry in /etc/fstab.
Perhaps I should clarify: fstab-supported monting works if done manually after reboot is complete and I can log in.
And /etc/init.d/nfs is automatically called, i.e. has the right symlinks? /Per -- Per Jessen, Zürich (19.6°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday May 12 2009, Per Jessen wrote:
...
And /etc/init.d/nfs is automatically called, i.e. has the right symlinks?
Yes, run-levels 3 and 5. I usually boot directly into runlevel 5.
/Per
RRS -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2009-05-12 at 07:15 -0700, Randall R Schulz wrote:
Yes, run-levels 3 and 5. I usually boot directly into runlevel 5.
Then you'd need to learn if it actually runs and whether it reports something. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoJiAUACgkQtTMYHG2NR9UHNgCfc7N9ctd46AgG9BkuTT+FERBa nHoAn3SaVDnRKuxbrHKBqiLHyDJcxlkW =X20c -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2009-05-12 at 16:11 +0200, Per Jessen wrote:
And /etc/init.d/nfs is automatically called, i.e. has the right symlinks?
Having the symlink is not enough in openSUSE. The service has also to be properly listed in the "makefile". - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoJhw0ACgkQtTMYHG2NR9WqRACfTbIC6z0Q/vrolWvNzHev3rmu RuIAnROrUV0bFaerPbCHrQdeMhqjEaLS =nRVu -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday May 12 2009, Carlos E. R. wrote:
On Tuesday, 2009-05-12 at 16:11 +0200, Per Jessen wrote:
And /etc/init.d/nfs is automatically called, i.e. has the right symlinks?
Having the symlink is not enough in openSUSE. The service has also to be properly listed in the "makefile".
I didn't play with the symlinks myself. The nfs service shows up as enabled in runlevels 3 and 5 in YaST. Chkconfig says: # chkconfig nfs nfs on # runlevel N 5
-- Cheers, Carlos E. R.
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2009-05-12 at 16:11 +0200, Per Jessen wrote:
And /etc/init.d/nfs is automatically called, i.e. has the right symlinks?
Having the symlink is not enough in openSUSE. The service has also to be properly listed in the "makefile".
Where is that? I have always just been inserting/removing service using 'insserv' - that seems to work pretty well. /Per -- Per Jessen, Zürich (18.0°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, May 12, 2009 at 05:11:26PM +0200, Per Jessen wrote:
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2009-05-12 at 16:11 +0200, Per Jessen wrote:
And /etc/init.d/nfs is automatically called, i.e. has the right symlinks?
Having the symlink is not enough in openSUSE. The service has also to be properly listed in the "makefile".
Where is that? I have always just been inserting/removing service using 'insserv' - that seems to work pretty well.
As the author of insserv: *please* use insserv(8) of chkconfig(8) ... if you do not like this, then set RUN_PARALLEL to "no" in /etc/sysconfig/boot ... then you're able to set the symbolic links by hand. But remember that any start links requires a stop links in the same runlevel directory ... compare with init.d(7). Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2009-05-12 at 17:11 +0200, Per Jessen wrote:
And /etc/init.d/nfs is automatically called, i.e. has the right symlinks?
Having the symlink is not enough in openSUSE. The service has also to be properly listed in the "makefile".
Where is that? I have always just been inserting/removing service using 'insserv' - that seems to work pretty well.
Exactly; because insserv mantains the makefile. If you would create the symlinks manually, with "ln", that would not work in some cases, like the default RUN_PARALLEL yes. Which makefiles? .depend.boot, .depend.start, .depend.stop in /etc/init.d/. See man insserv: /etc/init.d/.depend.boot, /etc/init.d/.depend.start, /etc/init.d/.depend.stop The make(1) like dependency files produced by insserv for booting, starting, and stopping with the help of startpar(8). - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoJyIUACgkQtTMYHG2NR9UIRwCdHN5JRG1h+RmytLS4hbF/1JDO 9IkAoIFfGsTLO7LSf/CbwPqJOzqepTq+ =4ZFY -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday May 12 2009, Carlos E. R. wrote:
...
Which makefiles? .depend.boot, .depend.start, .depend.stop in /etc/init.d/. See man insserv:
/etc/init.d/.depend.boot, /etc/init.d/.depend.start, /etc/init.d/.depend.stop The make(1) like dependency files produced by insserv for booting, starting, and stopping with the help of startpar(8).
Note the phrasing: "... make(1) _like_ dependency files ..." For many of us the term "makefile" means something fairly specific and it excludes these "make-like" files.
-- Cheers, Carlos E. R.
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz wrote:
On Tuesday May 12 2009, Per Jessen wrote:
Randall R Schulz wrote:
Hi,
It seems like a routine thing, but I can't find any information.
Given an NFS share (server-side) and an fstab entry (client-side) that can be successfully mounted manually, what must be done on the cliet side to get that share mounted during reboot?
From my /etc/fstab:
fileserver:/some/where /else/where nfs rsize=8192,wsize=8192 0 0
I don't think this is about the obvious. Naurally, I have a suitable entry in /etc/fstab.
Perhaps I should clarify: fstab-supported monting works if done manually after reboot is complete and I can log in.
You could always add the mount command to /etc/init.d/after.local. You may have to create that file though. -- Use OpenOffice.org http://www.openoffice.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
It seems like a routine thing, but I can't find any information.
Given an NFS share (server-side) and an fstab entry (client-side) that can be successfully mounted manually, what must be done on the cliet side to get that share mounted during reboot?
Have you installed the NFS YaST components? With YaST, it's a simple matter fo a few clicks and your NFS shares will be set to mount on boot. I have 2 small LANs that I've done this with... works quite well. C. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday May 12 2009, Clayton wrote:
It seems like a routine thing, but I can't find any information.
Given an NFS share (server-side) and an fstab entry (client-side) that can be successfully mounted manually, what must be done on the cliet side to get that share mounted during reboot?
Have you installed the NFS YaST components? With YaST, it's a simple matter fo a few clicks and your NFS shares will be set to mount on boot.
Of course. That's how I set it up originally.
I have 2 small LANs that I've done this with... works quite well.
C.
RRS -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2009-05-12 at 06:43 -0700, Randall R Schulz wrote:
It seems like a routine thing, but I can't find any information.
Given an NFS share (server-side) and an fstab entry (client-side) that can be successfully mounted manually, what must be done on the cliet side to get that share mounted during reboot?
Is the nfs client service enabled to run at boot? Check with "chkconfig nfs" (config is /etc/sysconfig/nfs). I thought that the fstab entry should be enough, but perhaps not, so try that... - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoJhLMACgkQtTMYHG2NR9XdWgCeL8gYQVuEPDWLLHKxVbkIgQ2y l5kAnj2N8SLJ8pwTyB0CP8dnWbpThgTI =0tSg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday May 12 2009, Carlos E. R. wrote:
On Tuesday, 2009-05-12 at 06:43 -0700, Randall R Schulz wrote:
It seems like a routine thing, but I can't find any information.
Given an NFS share (server-side) and an fstab entry (client-side) that can be successfully mounted manually, what must be done on the cliet side to get that share mounted during reboot?
Is the nfs client service enabled to run at boot? Check with "chkconfig nfs" (config is /etc/sysconfig/nfs).
Yes, see my previous answer to Per. Well, there's no need. I just said "yes, in runlevels 3 and 5."
I thought that the fstab entry should be enough, but perhaps not, so try that...
-- Cheers, Carlos E. R.
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, 12 May 2009, 16:23:09 +0200, Randall R Schulz wrote:
On Tuesday May 12 2009, Carlos E. R. wrote:
On Tuesday, 2009-05-12 at 06:43 -0700, Randall R Schulz wrote:
It seems like a routine thing, but I can't find any information.
Given an NFS share (server-side) and an fstab entry (client-side) that can be successfully mounted manually, what must be done on the cliet side to get that share mounted during reboot?
Is the nfs client service enabled to run at boot? Check with "chkconfig nfs" (config is /etc/sysconfig/nfs).
Yes, see my previous answer to Per. Well, there's no need. I just said "yes, in runlevels 3 and 5."
It may as well have to do with which kind of NFS server you're trying to mount from. I recently had troubles with some ancient True64 NFS server, which could be solved by adding mountproto=udp to the mount options. Perhaps you should describe details about the server, too. Also, can the directories be mounted if you're running "/etc/init.d/nfs start" manually later on? HTH, cheers. l8er manfred -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday May 12 2009, Manfred Hollstein wrote:
On Tue, 12 May 2009, 16:23:09 +0200, Randall R Schulz wrote:
On Tuesday May 12 2009, Carlos E. R. wrote:
On Tuesday, 2009-05-12 at 06:43 -0700, Randall R Schulz wrote:
It seems like a routine thing, but I can't find any information.
Given an NFS share (server-side) and an fstab entry (client-side) that can be successfully mounted manually, what must be done on the cliet side to get that share mounted during reboot?
Is the nfs client service enabled to run at boot? Check with "chkconfig nfs" (config is /etc/sysconfig/nfs).
Yes, see my previous answer to Per. Well, there's no need. I just said "yes, in runlevels 3 and 5."
It may as well have to do with which kind of NFS server you're trying to mount from. I recently had troubles with some ancient True64 NFS server, which could be solved by adding mountproto=udp to the mount options. Perhaps you should describe details about the server, too. Also, can the directories be mounted if you're running "/etc/init.d/nfs start" manually later on?
It's another openSUSE 11.1 system configured using YaST, as well. Both are using v4 NFS. To reiterate, it's only boot-time mounting that's not working. (I've stated this a few times, now, including in the quote you included above...)
HTH, cheers.
l8er manfred
Randall Schluz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz wrote:
To reiterate, it's only boot-time mounting that's not working. (I've stated this a few times, now, including in the quote you included above...)
Then it almost has to be a timing issue - network, portmapper? Firewall perhaps? /Per -- Per Jessen, Zürich (18.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, 12 May 2009, 18:04:53 +0200, Per Jessen wrote:
Randall R Schulz wrote:
To reiterate, it's only boot-time mounting that's not working. (I've stated this a few times, now, including in the quote you included above...)
Then it almost has to be a timing issue - network, portmapper? Firewall perhaps?
Randall, if you're using RUN_PARALLEL=yes in /etc/sysconfig/boot, can you please try to set it to "no", reboot and watch if it'll work then? If so, please bugzilla it. BTW, are you NICs set to receive their addresses from a DHCP server? If so, which manufacturer are they from? Broadcom... ? Cheers. l8er manfred -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday May 12 2009, Manfred Hollstein wrote:
On Tue, 12 May 2009, 18:04:53 +0200, Per Jessen wrote:
Randall R Schulz wrote:
To reiterate, it's only boot-time mounting that's not working. (I've stated this a few times, now, including in the quote you included above...)
Then it almost has to be a timing issue - network, portmapper? Firewall perhaps?
No firewall.
Randall, if you're using RUN_PARALLEL=yes in /etc/sysconfig/boot, can you please try to set it to "no", reboot and watch if it'll work then? If so, please bugzilla it. BTW, are you NICs set to receive their addresses from a DHCP server? If so, which manufacturer are they from? Broadcom... ?
- RUN_PARALLEL: Yes, of course, as is set by the openSUSE installer - Rebooting for experiments: Not high on my list, since its very time-consuming and disruptive. - DHCP: No; Both hosts are statically addressed - NIC: Marvell 88E001, driver "skge" Why would the particulars at the device level matter?
Cheers.
l8er manfred
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, 12 May 2009, 18:47:15 +0200, Randall R Schulz wrote:
On Tuesday May 12 2009, Manfred Hollstein wrote:
[...] Randall, if you're using RUN_PARALLEL=yes in /etc/sysconfig/boot, can you please try to set it to "no", reboot and watch if it'll work then? If so, please bugzilla it. BTW, are you NICs set to receive their addresses from a DHCP server? If so, which manufacturer are they from? Broadcom... ?
- RUN_PARALLEL: Yes, of course, as is set by the openSUSE installer
- Rebooting for experiments: Not high on my list, since its very time-consuming and disruptive.
- DHCP: No; Both hosts are statically addressed
- NIC: Marvell 88E001, driver "skge"
Why would the particulars at the device level matter?
Some of the broadcom devices are known to not be functional when the driver is loaded; they can take up to 60 seconds until they can be really used. DHCP in addition can cause additional delay, that combined with RUN_PARALLEL sometimes results in some services not working properly after a (re)boot, simply because the script potentially starts earlier than it does in the RUN_PARALLEL=no case. HTH, cheers. l8er manfred -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday May 12 2009, Manfred Hollstein wrote:
On Tue, 12 May 2009, 18:47:15 +0200, Randall R Schulz wrote:
...
Why would the particulars at the device level matter?
Some of the broadcom devices are known to not be functional when the driver is loaded; they can take up to 60 seconds until they can be really used. DHCP in addition can cause additional delay, that combined with RUN_PARALLEL sometimes results in some services not working properly after a (re)boot, simply because the script potentially starts earlier than it does in the RUN_PARALLEL=no case.
It's always something isn't it? The next time it's convenient to reboot, I'll try with RUN_PARALLEL off.
HTH, cheers.
l8er manfred
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, 2009-05-12 at 18:24 +0200, Manfred Hollstein wrote:
On Tue, 12 May 2009, 18:04:53 +0200, Per Jessen wrote:
Randall R Schulz wrote:
To reiterate, it's only boot-time mounting that's not working. (I've stated this a few times, now, including in the quote you included above...)
Just a suggestion... Does your nfs-client gets ip address via DHCP? I found out that i had to increase the dhcp-timeout to 120 seconds. (Normally dhcp-client continues in the background afyter waiting for an address after 20 seconds (WAIT_FOR_INTERFACES="20"), and the rest of the init.d-chain continues, eventhough it is pointless without an ip-address) If that's not the case, you can always do a "mount -a -f nfs" in /etc/rc.d/after.local (it Q&D, but works) hw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday May 12 2009, Hans Witvliet wrote:
On Tue, 2009-05-12 at 18:24 +0200, Manfred Hollstein wrote:
On Tue, 12 May 2009, 18:04:53 +0200, Per Jessen wrote:
Randall R Schulz wrote:
To reiterate, it's only boot-time mounting that's not working. (I've stated this a few times, now, including in the quote you included above...)
Just a suggestion... Does your nfs-client gets ip address via DHCP?
Again, no.
...
hw
RRS -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz wrote:
On Tuesday May 12 2009, Manfred Hollstein wrote:
On Tue, 12 May 2009, 16:23:09 +0200, Randall R Schulz wrote:
Given an NFS share (server-side) and an fstab entry (client-side) that can be successfully mounted manually, what must be done on the cliet side to get that share mounted during reboot?
Also, can the directories be mounted if you're running "/etc/init.d/nfs start" manually later on?
To reiterate, it's only boot-time mounting that's not working. (I've stated this a few times, now, including in the quote you included above...)
I think Manfred's question was more nuanced. How do you mount manually later after boot? By calling "mount -a -t nfs" or even mounting the shares one by one? Or by calling "/etc/init.d/nfs start"? (That script does much more than just calling mount, so it could go wrong in other places.) That information was not given yet by you, AFAICS. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday May 13 2009, Joachim Schrod wrote:
Randall R Schulz wrote:
On Tuesday May 12 2009, Manfred Hollstein wrote:
On Tue, 12 May 2009, 16:23:09 +0200, Randall R Schulz wrote:
Given an NFS share (server-side) and an fstab entry (client-side) that can be successfully mounted manually, what must be done on the cliet side to get that share mounted during reboot?
Also, can the directories be mounted if you're running "/etc/init.d/nfs start" manually later on?
To reiterate, it's only boot-time mounting that's not working. (I've stated this a few times, now, including in the quote you included above...)
I think Manfred's question was more nuanced. How do you mount manually later after boot? By calling "mount -a -t nfs" or even mounting the shares one by one? Or by calling "/etc/init.d/nfs start"? (That script does much more than just calling mount, so it could go wrong in other places.)
There's only one mount in question. I mount it by specifying the mount-point directory to the "mount" command: # mount /twain/repo/library The nfs (client) daemon / service is already running by the time I can log in. It's enabled in run levels 3 and 5. I did mention that.
That information was not given yet by you, AFAICS.
Joachim
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz wrote:
The nfs (client) daemon / service is already running by the time I can log in. It's enabled in run levels 3 and 5. I did mention that.
Yep - and you've probably/perhaps also verified that the scripts are in fact run during a boot-up? If not, check /var/log/boot.msg /Per -- Per Jessen, Zürich (21.8°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday May 13 2009, Per Jessen wrote:
Randall R Schulz wrote:
The nfs (client) daemon / service is already running by the time I can log in. It's enabled in run levels 3 and 5. I did mention that.
Yep - and you've probably/perhaps also verified that the scripts are in fact run during a boot-up? If not, check /var/log/boot.msg
I did. Here are all the lines mentioning NFS in boot.msg: -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- Starting kernel based NFS server: idmapd mountd statd nfsd sm-notifydone Starting NFS client services: sm-notify idmapdmount: rpc_pipefs already mounted or /var/lib/nfs/rpc_pipefs busy mount: according to mtab, rpc_pipefs is already mounted on /var/lib/nfs/rpc_pipefs -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-
/Per
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz wrote:
On Wednesday May 13 2009, Per Jessen wrote:
Randall R Schulz wrote:
The nfs (client) daemon / service is already running by the time I can log in. It's enabled in run levels 3 and 5. I did mention that.
Yep - and you've probably/perhaps also verified that the scripts are in fact run during a boot-up? If not, check /var/log/boot.msg
I did. Here are all the lines mentioning NFS in boot.msg:
-==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- Starting kernel based NFS server: idmapd mountd statd nfsd sm-notifydone Starting NFS client services: sm-notify idmapdmount: rpc_pipefs already mounted or /var/lib/nfs/rpc_pipefs busy mount: according to mtab, rpc_pipefs is already mounted on /var/lib/nfs/rpc_pipefs -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-
I'm not certain, but could this be a conflict between an nfs server and an nfs client? It looks like you're starting an nfs server first, and then the nfs client complains about something being already mounted - I'm wondering if that causes the nfs client script to stop at that point (sm_notify). If you don't need the nfsserver, perhaps it's worth disabling it and see what happens on the next boot? /Per -- Per Jessen, Zürich (18.3°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, 2009-05-13 at 06:44 -0700, Randall R Schulz wrote:
On Wednesday May 13 2009, Per Jessen wrote:
Randall R Schulz wrote:
The nfs (client) daemon / service is already running by the time I can log in. It's enabled in run levels 3 and 5. I did mention that.
Yep - and you've probably/perhaps also verified that the scripts are in fact run during a boot-up? If not, check /var/log/boot.msg
I did. Here are all the lines mentioning NFS in boot.msg:
-==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- Starting kernel based NFS server: idmapd mountd statd nfsd sm-notifydone Starting NFS client services: sm-notify idmapdmount: rpc_pipefs already mounted or /var/lib/nfs/rpc_pipefs busy mount: according to mtab, rpc_pipefs is already mounted on /var/lib/nfs/rpc_pipefs -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-
Still waiting for the results when you add bg,intr to the flags in /etc/fstab. It is not an idle suggestion... -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 8-615 60 20 Mobile: Int +46 70-815 1696 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday May 13 2009, Roger Oberholtzer wrote:
...
Still waiting for the results when you add bg,intr to the flags in /etc/fstab. It is not an idle suggestion...
I added it to the fstab entry. But I don't reboot this system on a whim— it's an ordeal. When the time is right, I will.
-- Roger Oberholtzer
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thu, 2009-05-14 at 05:50 -0700, Randall R Schulz wrote:
On Wednesday May 13 2009, Roger Oberholtzer wrote:
...
Still waiting for the results when you add bg,intr to the flags in /etc/fstab. It is not an idle suggestion...
I added it to the fstab entry. But I don't reboot this system on a whim— it's an ordeal. When the time is right, I will.
Understood. I look forward to the result. If this still fails, I am guessing that automount is the way to go. Are you using anything on the NFS mounted volume during boot? Or is it stuff that will be used later? -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 8-615 60 20 Mobile: Int +46 70-815 1696 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday May 14 2009, Roger Oberholtzer wrote:
On Thu, 2009-05-14 at 05:50 -0700, Randall R Schulz wrote:
On Wednesday May 13 2009, Roger Oberholtzer wrote:
...
Still waiting for the results when you add bg,intr to the flags in /etc/fstab. It is not an idle suggestion...
I added it to the fstab entry. But I don't reboot this system on a whim— it's an ordeal. When the time is right, I will.
Understood. I look forward to the result.
If this still fails, I am guessing that automount is the way to go. Are you using anything on the NFS mounted volume during boot? Or is it stuff that will be used later?
No. The export is my library (mostly PDF and PostScript documents, some HTML page collections, the odd MS Office or OOo document, etc. and software). It's by definition only used by me and only interactively.
-- Roger Oberholtzer
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, 2009-05-13 at 06:06 -0700, Randall R Schulz wrote: Just to summarize what works (for me:): In my /etc/fstab, I mount NFS volumes at boot. My entries are like this: source:/vol1 /source/vol1 nfs defaults,rsize=8192,wsize=8192,bg,soft,intr,noatime 0 0 Do you have NFSv4 enabled? I do, but not for these two. The NFS server is running openSUSE 11.0 I know you have written it before, but exactly what is in your /etc/fstab on the client? Is the system: name /etc/fstab resolvable at boot? Or does it require access to a DNS? -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 8-615 60 20 Mobile: Int +46 70-815 1696 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday May 13 2009, Roger Oberholtzer wrote:
On Wed, 2009-05-13 at 06:06 -0700, Randall R Schulz wrote:
Just to summarize what works (for me:):
In my /etc/fstab, I mount NFS volumes at boot. My entries are like this:
source:/vol1 /source/vol1 nfs defaults,rsize=8192,wsize=8192,bg,soft,intr,noatime 0 0
Do you have NFSv4 enabled? ...
Yes.
I know you have written it before, but exactly what is in your /etc/fstab on the client?
###.###.###.###:/repo/library /twain/repo/library nfs rw,soft,intr,rsize=8192,wsize=8192 0 0 [ # == digit ]
Is the system: name /etc/fstab resolvable at boot? Or does it require access to a DNS?
As you can see, it does not.
-- Roger Oberholtzer
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, 2009-05-13 at 06:59 -0700, Randall R Schulz wrote:
On Wednesday May 13 2009, Roger Oberholtzer wrote:
On Wed, 2009-05-13 at 06:06 -0700, Randall R Schulz wrote:
Just to summarize what works (for me:):
In my /etc/fstab, I mount NFS volumes at boot. My entries are like this:
source:/vol1 /source/vol1 nfs defaults,rsize=8192,wsize=8192,bg,soft,intr,noatime 0 0
Do you have NFSv4 enabled? ...
Yes.
You do not have the bg and intr flags. I would have them in a mount that happens during boot. As the lack of these has, in the past, make system not complete booting, perhaps there is a check by the mount command to see that any mounts without these are skipped so they do not hang the boot process. It surely could not hurt to add them. Sorry if this has already been asked, but in /etc/rcd.d/nfs, there is a bit of code like: if test "$nfs" = yes ; then mount -at nfs,nfs4 > /dev/null 2>&1 fi What happens if you add two lines, like: if test "$nfs" = yes ; then mount -at nfs,nfs4 > /dev/null 2>&1 stat=$? echo "RRS test: NFS mount returned $stat" >>/tmp/rrs_nfs.log fi What is in /tmp/rrs_nfs.log ? Is the file even created? -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 8-615 60 20 Mobile: Int +46 70-815 1696 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday May 13 2009, Roger Oberholtzer wrote:
...
You do not have the bg and intr flags. I would have them in a mount that happens during boot. As the lack of these has, in the past, make system not complete booting, perhaps there is a check by the mount command to see that any mounts without these are skipped so they do not hang the boot process. It surely could not hurt to add them.
I'll try that.
Sorry if this has already been asked, but in /etc/rcd.d/nfs, there is a bit of code like:
It's better to refer to the real directory name, /etc/init.d, not the symlink that's there for (presumably) some kind backward or sideways compatibility.
if test "$nfs" = yes ; then mount -at nfs,nfs4 > /dev/null 2>&1 fi
Lines 211-222 of /etc/init.d/nfs: -==--==--==--==--==--==--==--==--==--==--==--==--==--==- # Mount all auto NFS devices (-> nfs(5) and mount(8) ) # NFS-Server sometime not reachable during boot phase. # It's sometime usefull to mount NFS devices in # background with an ampersand (&) and a sleep time of # two or more seconds, e.g: # # sleep 2 && mount -at nfs,nfs4 & # sleep 2 # if test "$nfs" = yes ; then mount -at nfs,nfs4 > /dev/null 2>&1 fi -==--==--==--==--==--==--==--==--==--==--==--==--==--==-
...
What is in /tmp/rrs_nfs.log ? Is the file even created?
What is it? Why would it be created? What would create it?
-- Roger Oberholtzer
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, 2009-05-13 at 07:48 -0700, Randall R Schulz wrote:
On Wednesday May 13 2009, Roger Oberholtzer wrote:
...
You do not have the bg and intr flags. I would have them in a mount that happens during boot. As the lack of these has, in the past, make system not complete booting, perhaps there is a check by the mount command to see that any mounts without these are skipped so they do not hang the boot process. It surely could not hurt to add them.
I'll try that.
Sorry if this has already been asked, but in /etc/rcd.d/nfs, there is a bit of code like:
It's better to refer to the real directory name, /etc/init.d, not the symlink that's there for (presumably) some kind backward or sideways compatibility.
On openSUSE, is there a different nfs startup script that you would be running?
if test "$nfs" = yes ; then mount -at nfs,nfs4 > /dev/null 2>&1 fi
Lines 211-222 of /etc/init.d/nfs:
-==--==--==--==--==--==--==--==--==--==--==--==--==--==- # Mount all auto NFS devices (-> nfs(5) and mount(8) ) # NFS-Server sometime not reachable during boot phase. # It's sometime usefull to mount NFS devices in # background with an ampersand (&) and a sleep time of # two or more seconds, e.g: # # sleep 2 && mount -at nfs,nfs4 & # sleep 2 # if test "$nfs" = yes ; then mount -at nfs,nfs4 > /dev/null 2>&1 fi -==--==--==--==--==--==--==--==--==--==--==--==--==--==-
...
What is in /tmp/rrs_nfs.log ? Is the file even created?
What is it? Why would it be created? What would create it?
Re-read my post. I suggested adding two lines in the startup script. Those lines added it. As well as the return status from the mount command. NOT just what the mount command prints. But the return code. That also tells something.
-- Roger Oberholtzer
Randall Schulz
-- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 8-615 60 20 Mobile: Int +46 70-815 1696 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday May 13 2009, Roger Oberholtzer wrote:
On Wed, 2009-05-13 at 07:48 -0700, Randall R Schulz wrote:
On Wednesday May 13 2009, Roger Oberholtzer wrote:
...
Sorry if this has already been asked, but in /etc/rcd.d/nfs, there is a bit of code like:
It's better to refer to the real directory name, /etc/init.d, not the symlink that's there for (presumably) some kind backward or sideways compatibility.
On openSUSE, is there a different nfs startup script that you would be running?
No. Why would there be? I surely would have mentioned changing a key start-up script.
...
-- Roger Oberholtzer
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, 2009-05-13 at 08:38 -0700, Randall R Schulz wrote:
On Wednesday May 13 2009, Roger Oberholtzer wrote:
On Wed, 2009-05-13 at 07:48 -0700, Randall R Schulz wrote:
On Wednesday May 13 2009, Roger Oberholtzer wrote:
...
Sorry if this has already been asked, but in /etc/rcd.d/nfs, there is a bit of code like:
It's better to refer to the real directory name, /etc/init.d, not the symlink that's there for (presumably) some kind backward or sideways compatibility.
On openSUSE, is there a different nfs startup script that you would be running?
No. Why would there be? I surely would have mentioned changing a key start-up script.
This is all aside of your problem - but to explain: You said I should be more careful and not tell you the name of a file when it was a symlink. I should tell you the file it points to. (I said /etc/rcd.d/nfs, and you suggested I use the name /etc/init.d/nfs). So I was asking you if this was a different file on your system. I did not expect them to be different (which you verified), so I did not think the specific file name I used was really an issue. It was all referring to the same thing. No matter. It was a side comment. Sorry if it caused confusion. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 8-615 60 20 Mobile: Int +46 70-815 1696 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2009-05-13 at 16:30 +0200, Roger Oberholtzer wrote:
What happens if you add two lines, like:
if test "$nfs" = yes ; then mount -at nfs,nfs4 > /dev/null 2>&1
stat=$? echo "RRS test: NFS mount returned $stat" >>/tmp/rrs_nfs.log fi
What is in /tmp/rrs_nfs.log ? Is the file even created?
Why not: mount -at nfs,nfs4 > /tmp/rrs_nfs.log 2>&1 - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoK3yAACgkQtTMYHG2NR9WvsQCdF5AtpHo5rc/Fz0WGxkW4/Jln bf4AoJN/t2JHkiW25mHUqAiBolWLOrzp =3qwm -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
On Wed, 2009-05-13 at 06:06 -0700, Randall R Schulz wrote:
Just to summarize what works (for me:):
In my /etc/fstab, I mount NFS volumes at boot. My entries are like this:
source:/vol1 /source/vol1 nfs defaults,rsize=8192,wsize=8192,bg,soft,intr,noatime 0 0
Do you have NFSv4 enabled? I do, but not for these two. The NFS server is running openSUSE 11.0
I know you have written it before, but exactly what is in your /etc/fstab on the client?
Is the system: name /etc/fstab resolvable at boot? Or does it require access to a DNS?
Isn't, the last 2 "0" at the end of your line means do not mount the drive at boot? -- Joseph Loo jloo@acm.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday May 13 2009, Joseph Loo wrote:
...
Isn't, the last 2 "0" at the end of your line means do not mount the drive at boot?
Not at all. To wit (from the output of "man 5 fstab"): The sixth field, (fs_passno), is used by the fsck(8) program to deter- mine the order in which filesystem checks are done at reboot time. The root filesystem should be specified with a fs_passno of 1, and other filesystems should have a fs_passno of 2. Filesystems within a drive will be checked sequentially, but filesystems on different drives will be checked at the same time to utilize parallelism available in the hardware. If the sixth field is not present or zero, a value of zero is returned and fsck will assume that the filesystem does not need to be checked.
--
Joseph Loo
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz wrote:
On Wednesday May 13 2009, Joseph Loo wrote:
...
Isn't, the last 2 "0" at the end of your line means do not mount the drive at boot?
Not at all. To wit (from the output of "man 5 fstab"):
The sixth field, (fs_passno), is used by the fsck(8) program to deter- mine the order in which filesystem checks are done at reboot time. The root filesystem should be specified with a fs_passno of 1, and other filesystems should have a fs_passno of 2. Filesystems within a drive will be checked sequentially, but filesystems on different drives will be checked at the same time to utilize parallelism available in the hardware. If the sixth field is not present or zero, a value of zero is returned and fsck will assume that the filesystem does not need to be checked.
--
Joseph Loo
Randall Schulz
One more thing, was it mention that he had the nfs daemon running not the nfsserver on the client machine. -- Joseph Loo jloo@acm.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On May 12, 2009, at 3:43 PM, Randall R Schulz wrote:
Hi,
It seems like a routine thing, but I can't find any information.
Given an NFS share (server-side) and an fstab entry (client-side) that can be successfully mounted manually, what must be done on the cliet side to get that share mounted during reboot?
Is the NFS server booting at the same time as the NFS client? If so, you cannot do this. It is a known issue. The problem is that the NFS server that is also booting will, when it's networking starts, and before its NFS server starts, reply to the client's nfs request in such a way that the client stops trying to mount. The client does not try again. I fought with this a year or so ago. What is needed is that the server network does NOT reply to NFS requests before its own NFS is up. But that is not what happens. I have checked what the client is told. So, I must mount the things later. Another option suggested at the time was to use automount so they will be mounted when accessed. That is probably the proper solution anyway. OTOH, if the server is already up, then this should work fine. It does for me on an OpenSUSE box with no customization and just standard entries in the /etc/fstab. Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Office: Int +46 8-615 60 20 Mobile: Int +46 70-815 1696 And remember: It is RSofT and there is always something under construction. It is like talking about large city with all constructions finished. Not impossible, but very unlikely. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday May 12 2009, Roger Oberholtzer wrote:
On May 12, 2009, at 3:43 PM, Randall R Schulz wrote:
Hi,
It seems like a routine thing, but I can't find any information.
Given an NFS share (server-side) and an fstab entry (client-side) that can be successfully mounted manually, what must be done on the cliet side to get that share mounted during reboot?
Is the NFS server booting at the same time as the NFS client? ...
No.
Roger Oberholtzer
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
I apologise if this has already been suggested, but have you tried using the 'bg' option for the nfs mount. If the server is not present during the client boot, or the mount fails, then the process continues in background. Peter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday May 12 2009, Peter Bloomfield wrote:
I apologise if this has already been suggested, but have you tried using the 'bg' option for the nfs mount.
If the server is not present during the client boot, or the mount fails, then the process continues in background.
I never boot these machines simultaneously.
Peter
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz wrote:
On Tuesday May 12 2009, Peter Bloomfield wrote:
I apologise if this has already been suggested, but have you tried using the 'bg' option for the nfs mount.
If the server is not present during the client boot, or the mount fails, then the process continues in background.
I never boot these machines simultaneously.
But it might also take care of a delayed activation of network cards as described by Manfred.... Pit -- Dr. Peter "Pit" Suetterlin http://www.astro.su.se/~pit Institute for Solar Physics Tel.: +34 922 405 590 (Spain) P.Suetterlin@royac.iac.es +46 8 5537 8534 (Sweden) Peter.Suetterlin@astro.su.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday May 13 2009, Pit Suetterlin wrote:
Randall R Schulz wrote:
On Tuesday May 12 2009, Peter Bloomfield wrote:
I apologise if this has already been suggested, but have you tried using the 'bg' option for the nfs mount.
If the server is not present during the client boot, or the mount fails, then the process continues in background.
I never boot these machines simultaneously.
But it might also take care of a delayed activation of network cards as described by Manfred....
What might? No other network-related symptoms are evident.
Pit
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz pecked at the keyboard and wrote:
On Wednesday May 13 2009, Pit Suetterlin wrote:
Randall R Schulz wrote:
On Tuesday May 12 2009, Peter Bloomfield wrote:
I apologise if this has already been suggested, but have you tried using the 'bg' option for the nfs mount.
If the server is not present during the client boot, or the mount fails, then the process continues in background. I never boot these machines simultaneously. But it might also take care of a delayed activation of network cards as described by Manfred....
What might? No other network-related symptoms are evident.
Pit
Randall Schulz
Using the bg option. This will cause the system to try to mount the nfs volume for a much longer time. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday May 12 2009, Randall R Schulz wrote:
Hi,
...
Given an NFS share (server-side) and an fstab entry (client-side) that can be successfully mounted manually, what must be done on the cliet side to get that share mounted during reboot?
An update: 1) Adding the "bg" option to the fstab entry did not fix the problem. 2) Running /etc/init.d/nfs start manually after boot was complete resulted in the export being mounted. I'm still booting with RUN_PARALLEL set to "yes". What does that imply? What's the solution? Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz pecked at the keyboard and wrote:
On Tuesday May 12 2009, Randall R Schulz wrote:
Hi,
...
Given an NFS share (server-side) and an fstab entry (client-side) that can be successfully mounted manually, what must be done on the cliet side to get that share mounted during reboot?
An update:
1) Adding the "bg" option to the fstab entry did not fix the problem. 2) Running /etc/init.d/nfs start manually after boot was complete resulted in the export being mounted.
I'm still booting with RUN_PARALLEL set to "yes".
What does that imply? What's the solution?
Randall Schulz
My best guess would be that /etc/init.d/nfs is running _before_ networking has completely started. If you look at /var/log/boot.msg it will show the order and status of the run scripts at boot time. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday May 16 2009, Ken Schneider - openSUSE wrote:
Randall R Schulz pecked at the keyboard and wrote:
...
An update:
1) Adding the "bg" option to the fstab entry did not fix the problem. 2) Running /etc/init.d/nfs start manually after boot was complete resulted in the export being mounted.
I'm still booting with RUN_PARALLEL set to "yes".
What does that imply? What's the solution?
...
My best guess would be that /etc/init.d/nfs is running _before_ networking has completely started. If you look at /var/log/boot.msg it will show the order and status of the run scripts at boot time.
From the header of /etc/init.d/nfs: ### BEGIN INIT INFO # Provides: nfs # Required-Start: $network $portmap # Required-Stop: $network $portmap # Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Short-Description: NFS client services # Description: All necessary services for NFS clients ### END INIT INFO I believe that's meant to keep nfs from running until the network and the port mapper are initialized.
Ken Schneider
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 16 May 2009 16:29:42 Randall R Schulz wrote:
From the header of /etc/init.d/nfs:
### BEGIN INIT INFO # Provides: nfs # Required-Start: $network $portmap # Required-Stop: $network $portmap # Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Short-Description: NFS client services # Description: All necessary services for NFS clients ### END INIT INFO
I believe that's meant to keep nfs from running until the network and the port mapper are initialized.
The portmapper (or in 11.1 rpcbind) listens to "all available interfaces". This means it can start even if only localhost is up. Unless you added your network interface to MANDATORY_DEVICES in /etc/sysconfig/network/config, either by editing the config file directly or by setting the interface as mandatory in YaST, the startup script is not going to wait for it, it will allow it to initialize in the background. Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday May 16 2009, Anders Johansson wrote:
On Saturday 16 May 2009 16:29:42 Randall R Schulz wrote:
From the header of /etc/init.d/nfs:
### BEGIN INIT INFO # Provides: nfs # Required-Start: $network $portmap # Required-Stop: $network $portmap # Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Short-Description: NFS client services # Description: All necessary services for NFS clients ### END INIT INFO
I believe that's meant to keep nfs from running until the network and the port mapper are initialized.
The portmapper (or in 11.1 rpcbind) listens to "all available interfaces". This means it can start even if only localhost is up.
Unless you added your network interface to MANDATORY_DEVICES in /etc/sysconfig/network/config, either by editing the config file directly or by setting the interface as mandatory in YaST, the startup script is not going to wait for it, it will allow it to initialize in the background.
That could be it. The hint in /etc/sysconfig/network/config: # /etc/init.d/rc5.d/S*network start -o debug fake | grep MANDAT shows three lines of output including MANDATORY_DEVICES, all of them empty. [ By the way, if you're in a position to do something about this, the recipe shown there should be fixed, since all the output from /etc/init.d/network, at least with the invocation given, goes to standard error. Hence a 2>&1 redirection is needed so grep gets the output. ]
Anders
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2009-05-16 at 16:45 +0200, Anders Johansson wrote:
On Saturday 16 May 2009 16:29:42 Randall R Schulz wrote:
From the header of /etc/init.d/nfs:
### BEGIN INIT INFO # Provides: nfs # Required-Start: $network $portmap # Required-Stop: $network $portmap # Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Short-Description: NFS client services # Description: All necessary services for NFS clients ### END INIT INFO
I believe that's meant to keep nfs from running until the network and the port mapper are initialized.
The portmapper (or in 11.1 rpcbind) listens to "all available interfaces". This means it can start even if only localhost is up.
Unless you added your network interface to MANDATORY_DEVICES in /etc/sysconfig/network/config, either by editing the config file directly or by setting the interface as mandatory in YaST, the startup script is not going to wait for it, it will allow it to initialize in the background.
1) hence my previous suggestion to raise WAIT_FOR_INTERFACES="20" to 120 in/etc/sysconfig/network/config. Then it will bg after 120 seconds, instead of 20. 2) It might also be educational to make a little command that does a ping command, just before the nfs-client is started. If icmp fails, no point in trying anything else 3) Perhaps also trying to use the ip-address instead of the name... (problems at that early moment with name-resolving?) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 16 May 2009 18:19:08 Hans Witvliet wrote:
1) hence my previous suggestion to raise WAIT_FOR_INTERFACES="20" to 120 in/etc/sysconfig/network/config. Then it will bg after 120 seconds, instead of 20.
Sure, but unless the interface is considered mandatory, it still won't wait even one second for it. Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Anders Johansson pecked at the keyboard and wrote:
On Saturday 16 May 2009 18:19:08 Hans Witvliet wrote:
1) hence my previous suggestion to raise WAIT_FOR_INTERFACES="20" to 120 in/etc/sysconfig/network/config. Then it will bg after 120 seconds, instead of 20.
Sure, but unless the interface is considered mandatory, it still won't wait even one second for it.
Anders
If the init.d scripts had a "WAIT_FINISHED" parameter then you would be more apt to have the nfs script run _after_ the network was up and running. As it is now the "WAIT_START" scripts only to need start to satisfy the requirement which is where the confusion comes into play. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 16 May 2009 19:08:54 Ken Schneider - openSUSE wrote:
Anders Johansson pecked at the keyboard and wrote:
On Saturday 16 May 2009 18:19:08 Hans Witvliet wrote:
1) hence my previous suggestion to raise WAIT_FOR_INTERFACES="20" to 120 in/etc/sysconfig/network/config. Then it will bg after 120 seconds, instead of 20.
Sure, but unless the interface is considered mandatory, it still won't wait even one second for it.
Anders
If the init.d scripts had a "WAIT_FINISHED" parameter then you would be more apt to have the nfs script run _after_ the network was up and running. As it is now the "WAIT_START" scripts only to need start to satisfy the requirement which is where the confusion comes into play.
Not as far as I'm aware. I'm not even aware of any WAIT_FINISHED or WAIT_START variables at all The problem here is that unless you have a MANDATORY interface, the network script will finish almost instantly, leaving everything to run in the background. If it is MANDATORY, the network script won't finish until it's initialized, and everything that depends on $network will wait for it Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday May 16 2009, Anders Johansson wrote:
On Saturday 16 May 2009 16:29:42 Randall R Schulz wrote:
From the header of /etc/init.d/nfs:
### BEGIN INIT INFO # Provides: nfs # Required-Start: $network $portmap # Required-Stop: $network $portmap # Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Short-Description: NFS client services # Description: All necessary services for NFS clients ### END INIT INFO
I believe that's meant to keep nfs from running until the network and the port mapper are initialized.
The portmapper (or in 11.1 rpcbind) listens to "all available interfaces". This means it can start even if only localhost is up.
Unless you added your network interface to MANDATORY_DEVICES in /etc/sysconfig/network/config, either by editing the config file directly or by setting the interface as mandatory in YaST, the startup script is not going to wait for it, it will allow it to initialize in the background.
I added eth1 (the device in question and the only one of two Ethernet ports on the mainboard that's in use) to the MANDATORY_DEVICES list. Unfortunately, this did not correct the problem. What's the next step, I wonder? Additionally, and I'm not sure what to make of this, after booting with eth1 in MANDATORY_DEVICES, it still doesn't show up here: # /etc/init.d/network start -o debug fake 2>&1 |egrep MANDAT MANDATORY_DEVICES = MANDATORY_DEVICES= MANDATORY_DEVICES= The full output is: # /etc/init.d/network start -o debug fake CONFIG = INTERFACE = AVAILABLE_IFACES = eth0 eth1 PHYSICAL_IFACES = eth0 eth1 BONDING_IFACES = VLAN_IFACES = DIALUP_IFACES = TUNNEL_IFACES = BRIDGE_IFACES = SLAVE_IFACES = MANDATORY_DEVICES = VIRTUAL_IFACES = SKIP = start order : eth0 eth1 ; ; ... still waiting for hotplug devices: SUCCESS_IFACES= eth0 eth1 MANDATORY_DEVICES= ... final SUCCESS_IFACES= eth0 eth1 MANDATORY_DEVICES= FAILED=0
Anders
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 16 May 2009 21:14:22 Randall R Schulz wrote:
SUCCESS_IFACES= eth0 eth1
Interesting. It seems ifup reports success for it. What exactly do you get in your boot messages regarding networking? Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 16 May 2009 21:14:22 Randall R Schulz wrote:
SUCCESS_IFACES= eth0 eth1
Incidentally, since ifup reports success, it may well be that you have the switch problem I mentioned earlier. I'm not sure if your switch model supports the relevant protocols that cause these delays, but if your boot messages indicate that you do get a network address immediately, you may want to add a sleep statement to /etc/init.d/nfs in the start) section Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday May 16 2009, Anders Johansson wrote:
On Saturday 16 May 2009 21:14:22 Randall R Schulz wrote:
SUCCESS_IFACES= eth0 eth1
Incidentally, since ifup reports success, it may well be that you have the switch problem I mentioned earlier. I'm not sure if your switch model supports the relevant protocols that cause these delays, but if your boot messages indicate that you do get a network address immediately, you may want to add a sleep statement to /etc/init.d/nfs in the start) section
"Get an address?" Are you thinking this is DHCP? 'Cause it's statically addressed.
Anders
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 16 May 2009 22:05:35 Randall R Schulz wrote:
On Saturday May 16 2009, Anders Johansson wrote:
On Saturday 16 May 2009 21:14:22 Randall R Schulz wrote:
SUCCESS_IFACES= eth0 eth1
Incidentally, since ifup reports success, it may well be that you have the switch problem I mentioned earlier. I'm not sure if your switch model supports the relevant protocols that cause these delays, but if your boot messages indicate that you do get a network address immediately, you may want to add a sleep statement to /etc/init.d/nfs in the start) section
"Get an address?" Are you thinking this is DHCP? 'Cause it's statically addressed.
OK, then I am convinced it's the switch. Try adding the sleep statement Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2009-05-16 at 21:37 +0200, Anders Johansson wrote:
On Saturday 16 May 2009 21:14:22 Randall R Schulz wrote:
SUCCESS_IFACES= eth0 eth1
Incidentally, since ifup reports success, it may well be that you have the switch problem I mentioned earlier. I'm not sure if your switch model supports the relevant protocols that cause these delays, but if your boot messages indicate that you do get a network address immediately, you may want to add a sleep statement to /etc/init.d/nfs in the start) section
Just another hunge.. Do you perhaps use VLAN's over a cisco switch? (was one situation causing grey hairs a year ago...) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday May 16 2009, Hans Witvliet wrote:
On Sat, 2009-05-16 at 21:37 +0200, Anders Johansson wrote:
On Saturday 16 May 2009 21:14:22 Randall R Schulz wrote:
SUCCESS_IFACES= eth0 eth1
Incidentally, since ifup reports success, it may well be that you have the switch problem I mentioned earlier. I'm not sure if your switch model supports the relevant protocols that cause these delays, but if your boot messages indicate that you do get a network address immediately, you may want to add a sleep statement to /etc/init.d/nfs in the start) section
Just another hunch.. Do you perhaps use VLAN's over a cisco switch? (was one situation causing grey hairs a year ago...)
No VLAN. There's a LinkSys (Cisco) wireless access point / hub connected to the DLink switch, but it's not in the path between the NFS server and the client whose boot-time NFS mounting fails. Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday May 16 2009, Anders Johansson wrote:
...
The portmapper (or in 11.1 rpcbind) listens to "all available interfaces". This means it can start even if only localhost is up.
Unless you added your network interface to MANDATORY_DEVICES in /etc/sysconfig/network/config, either by editing the config file directly or by setting the interface as mandatory in YaST, the startup script is not going to wait for it, it will allow it to initialize in the background.
I found this comment in "/etc/init.d/network": # mandatory interfaces may be specified in /etc/sysconfig/network/config # If $MANDATORY_DEVICES is empty we take all PHYSICAL_IFACES, which are # configured with STARMODE=auto, as mandatory If this is accurate, does it not contradict what you wrote? I also confirmed that eth1's STARTMODE (note the typo in the comment above) is "auto". For some reason, lo's STARTMODE is the deprecated "onboot".
Anders
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 16 May 2009 21:37:22 Randall R Schulz wrote:
On Saturday May 16 2009, Anders Johansson wrote:
...
The portmapper (or in 11.1 rpcbind) listens to "all available interfaces". This means it can start even if only localhost is up.
Unless you added your network interface to MANDATORY_DEVICES in /etc/sysconfig/network/config, either by editing the config file directly or by setting the interface as mandatory in YaST, the startup script is not going to wait for it, it will allow it to initialize in the background.
I found this comment in "/etc/init.d/network":
# mandatory interfaces may be specified in /etc/sysconfig/network/config # If $MANDATORY_DEVICES is empty we take all PHYSICAL_IFACES, which are # configured with STARMODE=auto, as mandatory
If this is accurate, does it not contradict what you wrote?
Yes, I noticed that later. Your problem must be something else Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 16 May 2009 15:21:28 Randall R Schulz wrote:
1) Adding the "bg" option to the fstab entry did not fix the problem. 2) Running /etc/init.d/nfs start manually after boot was complete resulted in the export being mounted.
Are you doing this at home, or is this in an enterprise setting? The reason I ask is that some higher end switches take quite some time to fully register that a port is in use, to allow traffic through. On such switches, it's usually necessary to either reconfigure the switch to not perform things like routing protocol management stuff, or - if the enterprise type protocols are actually used - to add a sleep statement to the nfs startup script If it's in a home setting with a low end switch or hub, then I'm not sure why it's happening Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday May 16 2009, Anders Johansson wrote:
On Saturday 16 May 2009 15:21:28 Randall R Schulz wrote:
1) Adding the "bg" option to the fstab entry did not fix the problem. 2) Running /etc/init.d/nfs start manually after boot was complete resulted in the export being mounted.
Are you doing this at home, or is this in an enterprise setting?
The reason I ask is that some higher end switches take quite some time to fully register that a port is in use, to allow traffic through. On such switches, it's usually necessary to either reconfigure the switch to not perform things like routing protocol management stuff, or - if the enterprise type protocols are actually used - to add a sleep statement to the nfs startup script
If it's in a home setting with a low end switch or hub, then I'm not sure why it's happening
Interesting. It's SOHO (we deserve our own classification, don't we?). The switch is a DLink DGS-2208 eight-port, 10/100/1000 Mbps switch and is definitely a consumer design. It claims to be an adaptive, low-power design that scales some aspecdts of its functions to match demand (analogously to how CPU frequency scaling works, I guess). Perhaps that has something to do with it? From [1]: "Power Savings by Number of Connected Ports and Link Status "Computers do not require Internet access all the time; neither do switches utilize all ports at all times. When a computer or network equipment is shut down, switches often remain on and continue to consume considerable amounts of power. With D-Link Green Technology, D-Link switches can automatically detect link status and reduce power usage of ports that are idle. Computers or any connecting parties set to standby mode (not power off), however, will not provide significant power savings." I glanced at some reviews (only a few so far) on Amazon.com [2] and NewEgg.com [3], but the only thing that jumps out is that it throttles all the ports to the speed of the slowest attached device. As with one reviewer, I wish I'd known that when I bought it... [1] http://www.dlink.com/products/?pid=495 [2] http://www.amazon.com/D-Link-DGS-2208-8-Port-Desktop-Switch/dp/B000FITKK8 [3] http://www.newegg.com/Product/Product.aspx?Item=N82E16833127082
Anders
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (15)
-
Anders Johansson -
Carlos E. R. -
Clayton -
Dr. Werner Fink -
Hans Witvliet -
James Knott -
Joachim Schrod -
Joseph Loo -
Ken Schneider - openSUSE -
Manfred Hollstein -
Per Jessen -
Peter Bloomfield -
Pit Suetterlin -
Randall R Schulz -
Roger Oberholtzer