rebooting into single user mode on a remote server

rebooting into single user mode on a remote server
Matthew Seaman m.seaman at infracaninophile.co.uk
Sat Sep 16 13:57:44 PDT 2006

Previous message: rebooting into single user mode on a remote server
Next message: rebooting into single user mode on a remote server
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

--------------------------------------------------------------------------------

pobox at 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

--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW


================================================


iv) (actually a variant of ii, but different enough to warrant
separate mention IMO) Put a "PC Weasel" or similar in any machine
that is going to be located remotely. This card looks like a VGA to
the machine, but allows for remote access. The simple ones support
only text mode via a serial port; some of the fancier ones act as
X11 clients so as to also support graphics modes. This gives you
access not only to the FreeBSD console, but to the BIOS.

And no, I do not work for any manufacturer or supplier of such.

================================================

I had this same issue last week... fortunately, my hosting provider
had a remote KVM solution and hooked it up to my server while I got
the job done. btw, that provider was m5hosting.com. I originally
found them from the freebsd.org community page and have been very
happy with their knowledge and support.

good luck, ke han
================================================
I don't want to persuade you to something that is not officially
supported, but I have never booted into single user mode while
upgrading my FreeBSD boxes and I have never experienced any problems
because of this. Just try to skip the reboot step and go ahead. It
works(tm) for me this way.

If you are paranoid, try to stop all running services except the ssh
deamon.

=================================================
Just to contribute, I also ALWAYS upgrade my systems without single
user mode, for "remote" reasons... ;-)

Same instructions: shut down all services, except inetd/ssh, installworld,
mergemaster and reboot...

I even posted in this list, months ago, a step-by-step to remotely
upgrade from 4.x to 6.x. I agree that this is a very risky task,
but before the first production server, I tried more than 40 times
(not kidding) in my test lab.

=================================================