Date: Sun, 17 Sep 2006 06:28:30 +0200 From: "pobox@verysmall.org" <pobox@verysmall.org> To: Matthew Seaman <m.seaman@infracaninophile.co.uk>, freebsd-questions@freebsd.org Subject: Re: rebooting into single user mode on a remote server Message-ID: <450CCEEE.7010202@verysmall.org> In-Reply-To: <450C652C.7040700@infracaninophile.co.uk> References: <450C46A8.3080908@verysmall.org> <450C652C.7040700@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Seaman wrote: > pobox@verysmall.org wrote: >> Hello, >> >> could somebody help me to understand the best way to enter into a single >> user mode on a remote server. >> >> I need it for the moment, during rebuilding world, when I have to reboot >> into single user mode before 'mergemaster -p'. >> >> The only solution I found so far is to do 'shutdown -r now' and when the >> server boots to login with ssh and do 'shutdown now' - which should drop >> it to single user mode. >> >> I can ask the support at the hosting location to reboot in single user >> mode, but I do not know if I will have ssh then? >> >> Alternatively I can ask them to do the last few steps. > > Yep. You've become the latest person to realise this perennial problem. > In order to follow the upgrade instructions in the Handbook or > /usr/src/UPDATING to the letter, you need console access to the machine > being updated. > > That is no problem when the machine is on your desk, or probably not if > it's just down the hall. But when it's in a hosting centre umpty dozen > miles away and you can't actually get to it? > > There are essentially three possibilities. > > i) You've thought of this approach already: get someone local to the machine > to do the bits requiring the console access. That works if the people at > the other site are competent and trustworthy, and you can afford to pay > for their time. > > ii) The next solution, and on the whole, probably the best solution > available, is to arrange to get remote console access. That can be > expensive if you go down the route of buying a dedicated console server. > Or it can be very cheap indeed if you have another FreeBSD box close by > the machine you're trying to update and you can string null modem cables > between their serial ports. Then you configure your FreeBSD box requiring > update to use ttya as its console and use tip(1) to get into it from the > other machine. (Actually, you could probably make that approach work from > any other unixoid OS or even from Windows so long as you can find the right > serial console emulation software). If you're really lucky, you're > running flashy new hardware with IPMI or similar "lights out" management > capability and can get into the machine through that. It doesn't work in > anything like the same way as a serial console, but the end result is > just as good. > > iii) Finally, and not to be dismissed without due consideration, is the > really quite simple approach of /not/ taking the machine down to single > user mode. Most of the time, you can quite happily run 'make installworld' > or 'make installkernel' or 'mergemaster' while the system is in multiuser > mode. You should shutdown all active services except what you need to > get in remotely and you should kick any other users off the machine as well > as generally taking steps to ensure the machine is as quiescent as possible > before trying that. You should also have a 'back to square one' plan for > dealing with the eventuality that the machine does not come back after > attempting to reboot into the new kernel -- you really absolutely will > require someone quite FreeBSD savvy to get onto the console to unfuck > things if so, and that illustrates the big drawback to this approach: if > it goes wrong, you are truly left up a gum tree without a paddle. > > Don't try approach (iii) for an upgrade over too many version numbers at > once. Jumping from, say 6.1-RELEASE to 6.1-RELEASE-p6 should be feasible, > as should jumping from 6.0-RELEASE to 6.1-RELEASE. Going from say > 5.5-RELEASE to 6.1-RELEASE is only for the brave or the most highly > skilled, and anything more than that is only for the foolhardy. Neither is > it a good idea to do method (iii) if you're making any major changes to the > hardware on the system. Nor does approach (iii) mix at all well with the > use of raised secure levels. > > Cheers, > > Matthew Matthew, thanks (and all others) for the detailed reply. The possibilities are now kind of clear to me and I'll have to work out which one I can implement best. Thanks a lot again, Iv
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?450CCEEE.7010202>