Date: Thu, 18 May 2006 20:48:10 -0400 From: Mike Meyer <mwm-dated-1148431690.562abd@mired.org> To: "Steven Hartland" <killing@multiplay.co.uk> Cc: freebsd-hackers@freebsd.org Subject: Re: NFS server not responding prevents boot Message-ID: <17517.5578.499715.568791@bhuda.mired.org> In-Reply-To: <008c01c67adc$590a2a30$b3db87d4@multiplay.co.uk> References: <008c01c67adc$590a2a30$b3db87d4@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
In <008c01c67adc$590a2a30$b3db87d4@multiplay.co.uk>, Steven Hartland <killing@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 <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17517.5578.499715.568791>