So How Hard Is Moving From 6.3 To 7.0?

[Matthew Seaman]

Tim Daneliuk wrote:
> I have a stable 6.3 production server.  If I buildworld/kernel for 7.0,
> install them, and reboot, will everything pretty much work the same as
> it did under 6.3, or have file locations, userland configuration, etc.
> changed?  Will my 6.3 binaries run unchanged on 7.0 as well? 

I've been doing a bunch of 6.x -> 7.0 upgrades recently.  Here's a
few hints I've picked up along the way:

   *) The base system update from 6.x to 7.0 can be done by following
      the usual 'make buildworld buildkernel ; make installkernel ... '
      procedure as shown in the handbook and also described in
      /usr/src/UPDATING.  Because you're doing a major version number
      update, following the strict procedure is even more important
      than usual.  If you have servers in a remote facility, going
      on-site or having remote console access is strongly advisable.

   *) The mergemaster steps are important. You will definitely need
      to run 'mergemaster -p' before doing the buildworld part as
      there's a new standard 'ftp' group.

      The mergemaster step after installation is going to prompt you
      to delete, merge or replace quite a large number of files -- 
      certainly affecting most of the contents of /etc/mtree, /etc/periodic/
      and /etc/rc.d/ plus lots of bluetooth and openbsm bits.  This is
      kind of tedious, and usually it requires bouncing on the 'i' key
      to replace the old default version of the file with the new one,
      but you do need to take care with this step as mistakes here can
      have a horribly negative impact on your machine.

   *) Be careful of the last step in the OS upgrade procedure.
      'make delete-old-libs' will render all of your 6.x compiled
      software inoperable.  I find it best to simply delay that
      step until after all of the ported software has been recompiled
      under 7.0.  Alternatively, you can install the misc/compat6x
      port, but you will still need to 'make delete-old-libs' and 
      restart everything (for which the simplest method is to reboot
      once more).

   *) It may seem like an enormous burden, but you really do need to
      recompile every port you have installed once you're running 7.0
      In general, software compiled under 6.x will run perfectly fine
      under 7.0 (so long as libc.so.6 etc. are present and visible to
      ld-elf.so.1) -- but you will not be able to update it or install
      anything that depends on dynamic loading into another application
      without a great deal of grief. (Eg. any php5 modules have to be
      linked against the same shlibs as the core php binary, and also
      if you're using mod_php5, against the same shlibs as the apache
      process that is loaded into).  Not doing this is to trade off
      a few hours of watching compiler output scrolling up your screen
      for days of stress and frustration at some indeterminate future
      point.

   *) The point about not mixing software loadable objects compiled
      against different versions of libc.so et al also applies *while*
      you are updating all your ports.  Certain software packages will
      cease to operate during this procedure.  Others will carry on
      just fine.  If you're upgrading a system where avoiding service
      downtime is critical, then, if you can swing it, doing a practice
      run on a similarly configured scratch box is a good idea.  Also
      good is to build offline or otherwise obtain pkgs of all the
      software you need to update on the critical server.

   *) Unfortunately, one of the software packages affected by the above
      considerations is portupgrade(1) -- it is quite likely to blow up
      in your face if you just naively run 'portupgrade -fa'.  The best
      way of getting round this is to first delete portupgrade and critical
      dependencies using the OS supplied tools (pkg_delete) and then
      re-install from scratch. eg, something like this:

          # pkg_info -rx portupgrade  (to see what portupgrade depends on)
          # pkg_delete -f  ruby-1.8.6.111_1,1 ruby18-bdb44-0.6.2 db44-4.4.20.4 portupgrade-devel-2.4.3 openssl-0.9.8g perl-5.8.8_1
          # cd /usr/ports/ports-mgmt/portupgrade-devel
          # make install

      (you may or may not depend on the ports version of OpenSSL, and the
      version numbers of other packages are likely to be different.  Also,
      I'm using portupgrade-devel here -- plain portupgrade is also likely
      to be seen in the wild)

      Once you've done that, you will be able to proceed with 'portupgrade -fa'
      for the rest of your software base and it should run smoothly.

      Of course, users of portmaster(1) have a much easier time here --
      it's a shell script and only depends on facilities provided by the
      core OS.

   *) If your upgrade doesn't run entirely smoothly or you have to restart
      it for some other reason, then you can use a command line like this
      to avoid re-recompiling anything you've already dealt with:

          # portupgrade -fa -x '>=2008-03-02'

      where '2008-03-02' should be replaced by the date you did the 6.x -> 
      7.0 upgrade.

   *) perl modules installed from CPAN (ie anything whose package name
      matches bsdpan-\*) also need to be reinstalled [well, technically,
      if it's pure perl code, it doesn't: if it uses perlxs at all, then
      it does].  As does any software installed outside the ports system
      if it links against any of the system shlibs -- although binary-only
      packages will probably have to be kept viable by adroit use of the
      misc/compat6x port.

   *) Once all your ports are recompiled, do the 'make delete-old-libs'
      step.  Then reboot the system to ensure all the running software is
      the updated version you've just put all that effort into compiling.
      Also good at this point is to clear out /usr/local/lib/compat/pkg.

      Anything you haven't managed to update properly is quite likely to
      fail to restart at this point.

   *) and relax...

Now, that may all seem a bit intimidating, but it isn't really.  Mostly
it's waiting for stuff to compile and doing fairly routine operations --
fairly (and somehow reassuringly) tedious stuff for the most part.

	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