From owner-freebsd-questions@FreeBSD.ORG Sun Mar 2 13:04:35 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A47951065678 for ; Sun, 2 Mar 2008 13:04:35 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id F0C0E8FC1A for ; Sun, 2 Mar 2008 13:04:34 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost [IPv6:::1]) by smtp.infracaninophile.co.uk (8.14.2/8.14.2) with ESMTP id m22D4S9l077733; Sun, 2 Mar 2008 13:04:29 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.4.4 smtp.infracaninophile.co.uk m22D4S9l077733 Authentication-Results: smtp.infracaninophile.co.uk; dkim=hardfail (SSP) header.i=unknown Message-ID: <47CAA5DC.5050700@infracaninophile.co.uk> Date: Sun, 02 Mar 2008 13:04:28 +0000 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 2.0.0.12 (X11/20080302) MIME-Version: 1.0 To: tundra@tundraware.com References: <47A3C37B.10707@tundraware.com> In-Reply-To: <47A3C37B.10707@tundraware.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtp.infracaninophile.co.uk [IPv6:::1]); Sun, 02 Mar 2008 13:04:29 +0000 (GMT) X-Virus-Scanned: ClamAV 0.92.1/6074/Sat Mar 1 21:59:36 2008 on happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on happy-idiot-talk.infracaninophile.co.uk Cc: FreeBSD Mailing List Subject: Re: So How Hard Is Moving From 6.3 To 7.0? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 13:04:35 -0000 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