7 messages in org.freebsd.freebsd-hackersNFS server not responding prevents boot| From | Sent On | Attachments |
|---|---|---|
| Steven Hartland | May 19, 2006 12:37 am | |
| Steven Hartland | May 19, 2006 12:47 am | |
| Mike Meyer | May 19, 2006 2:33 am | |
| Sergey Babkin | May 19, 2006 11:30 am | |
| Steven Hartland | May 19, 2006 1:17 pm | |
| Chuck Lever | May 19, 2006 2:04 pm | |
| Kip Macy | May 20, 2006 7:57 pm |
| Subject: | NFS server not responding prevents boot | |
|---|---|---|
| From: | Mike Meyer (mwm-...@mired.org) | |
| Date: | May 19, 2006 2:33:38 am | |
| List: | org.freebsd.freebsd-hackers | |
In <008c01c67adc$590a2a30$b3db...@multiplay.co.uk>, Steven Hartland
<kill...@multiplay.co.uk> typed:
I was doing some kernel patches the other day and rebooted a FreeBSD 5.4 machine to pick them up, unfortunately I didn't notice someone had put in a bad nfs mount in /etc/fstab i.e. to a machine that no longer existed.
This prevented the server coming back onto the network enough to fix the error ( sshd never started ). With the machine being remote I ended up having to send an engineer in to press CTRL + C on the keyboard to enable the machine to boot ( didn't know it would be that simple before he got there ).
Anyway the big question is how can I change all our NFS mounts so that failed mounts dont prevent the machines booting to the point where they can be fixed remotely i.e. have started sshd.
Add -b to the options column for nfs-mounted volumes. That will cause the mount attempt to be done in the background if the first attempt fails.
Of course you should beware of nfs volumes that are required for a system to boot properly. You have to decide whether "hung waiting for the remote file system" is better or worse than the state you get if the system boots without that file system mounted.
<mike
-- Mike Meyer <mw...@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.