Best practices for remote upgrade?

David Wolfskill david at
Mon May 8 23:18:00 UTC 2006

On Mon, May 08, 2006 at 02:29:23PM +0200, Scott Harrison wrote:
> Hello,
> 	I have some 4.x servers that I would like to upgrade to 5.x, and  
> perhaps 6.x.  However, I do not have any local access to these  
> machines.  I can ssh into them only.  I would like to know whether it  
> is possible for me to upgrade the machines with only ssh access, and  
> what one should do to go about upgrading them.

Short answer: it depends.

One of the ings on which this depends is how those remote systems are
set up.  One thing I like to do, which IMO makes this type of exercise
somewhat more feasible, is to have more than one bootable slice on the
machine.  Typically, I would allocate a relatively small slice 1 (&
slice 2), each of which would have a / and /usr file system on it.  I'd
put everything else -- stuff that I wanted to remain the same regardless
of which slice is the boot slice -- on (say) slice 3.

I then have little shell scripts to use "dump | restore" to "clone" the
file systems from one slice to the other.

One of the nice things this does is allow the machine to be booted form
one slice while moderately major "surgery" is performed on the file
systems on the inactive slice.

There are a few inconveniences -- it does take up disk space; allocating
the root file system for slice 2 is moderately annoying using
sysinstall, because it gets allocated as partition d, and I like to make
it partition "a" -- so use "bsdlabel -e" (or "disklabel -e" on older
systems) and change the partition designator, if that's what you prefer.

I've seen similar setups where the inactive slice gradually become more
and more stale.  I avoid this by using the following approach (which
could undoubtedly be made cleverer, but I stopped when I found an
approach that worked):

* "Clone" the file systems from the active slice to the inactive one.

* Reboot from the "other" slice (the target of the above operation).

* Upgrade in place.

* Reboot (without changing active slice).

For fallback, reboot from the original slice.

This is actaully a variant of an approach that I recall using back on
IBM mainframes running MVS (and MVS/ESA and MVS/XA) (ca. 1982 - 1993).

Note that "boot0cfg" can change the default boot slice if you're using
the FreeBSD boot loader.

In my experience, this works better for smaller deltas between upgrades
-- so it may not be directly applicable to a 4.x -> 5.x? -> 6.x
transition.  There may still be something useful for your situation
there, though.

David H. Wolfskill				david at
Spam received via "opt-out" lists is still spam, and should be treated as such.

See for my public key.

More information about the freebsd-stable mailing list