upgrading form 4.2 to 5.x

Matthew Seaman m.seaman at infracaninophile.co.uk
Sun Jul 18 05:36:53 PDT 2004


On Sun, Jul 18, 2004 at 01:15:21PM +0200, Wojciech Puchar wrote:
> > Brent Bailey writes:
> >
> > >  The customer is running a file server samba also running apache
> > >  running FBSD 4.2, he wants to upgrade using cvsup & the make
> > >  buildworld procedure to upgrade to 5.x.
> 
> why they want an upgrade as 4.2 works fine?
> 
> smells like windows.

True.  Upgrading just for the sake of it is not sensible.  However
there are plenty of valid reasons for wanting to upgrade:

   - Security Advisories: often these will be backported to earlier
     versions, but the only versions where patches will definitely be
     provided are the versions listed as 'supported' on

        http://www.freebsd.org/releng/index.html

     Generally any release will be supported for a year from release,
     but there are exceptions.  For instance, 4.8-RELEASE was recently
     announced to have an extended support period which means that it
     will be covered for longer than 4.9-RELEASE and about as long as
     4.10-RELEASE, and the earlier developer preview 5.x-RELEASEs
     weren't supported beyond the next DP release.

   - Ports: These are only really guaranteed to work on the latest 4.x
     or 5.x release, as limited resources mean that those are the only
     OS versions where packages can be built en mass.  While porters
     will not gratuitously break compatability with earlier system
     versions, sometimes this will happen.  New features and bug fixes
     in the compiler tool chain, make(1), the pkg_foo tools and so
     forth can also break compatability with earlier versions.

   - Hardware support: 4.2-RELEASE came out in November 2000.  The
     rate of change in computer hardware since then has been very
     large.  Should one of those servers bite the dust, it's quite
     possible that 4.2-RELEASE wouldn't support the hardware available
     on a replacement system.  Better to do an upgrade calmly and
     carefully and without undue pressure rather than having to rush
     it through to get a replacement system back into production as
     soon as possible.

Now, the question of having to upgrade all the way to 5.x, and
requiring that the upgrade is done "in place" by the usual
{build,install}{world,kernel} mechanism is a different matter.  My
advice would be to avoid that as likely to cause more trouble than it
really warrants.  The best mechanism for doing this sort of thing is
to start with a spare system, do a clean install of whatever OS
version is chosen (sizing all of the partitions etc. according to the
experience gained with the older systems) and build and configure all
of the required software from scratch.  This will allow you to run the
new system in parallel with the old for testing purposes, and gives
you an easy route to back out the upgrade should it cause problems.

The procedure would be to upgrade each system this manner, and use
each old set of hardware as the spare to build the replacement for the
next system in turn.  

	Cheers,

	Matthew     


-- 
Dr Matthew J Seaman MA, D.Phil.                       26 The Paddocks
                                                      Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey         Marlow
Tel: +44 1628 476614                                  Bucks., SL7 1TH UK
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20040718/36180fd3/attachment.bin


More information about the freebsd-questions mailing list