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
*) 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
*) 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-188.8.131.52_1,1 ruby18-bdb44-0.6.2 db44-184.108.40.206
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
*) 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 ->
*) 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
*) 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.
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
email@example.com mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"