From owner-freebsd-stable@FreeBSD.ORG Sat Jan 10 03:45:57 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20775106566C for ; Sat, 10 Jan 2009 03:45:57 +0000 (UTC) (envelope-from mike@vintners.net) Received: from vinifera.vintners.net (vinifera.vintners.net [207.229.65.53]) by mx1.freebsd.org (Postfix) with ESMTP id EE2E98FC0C for ; Sat, 10 Jan 2009 03:45:56 +0000 (UTC) (envelope-from mike@vintners.net) Received: from [127.0.0.1] (brix.vintners.net [209.162.136.18]) by vinifera.vintners.net (8.14.1/8.14.1) with ESMTP id n0A3jkj2008319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jan 2009 19:45:46 -0800 (PST) (envelope-from mike@vintners.net) Message-ID: <496819F0.9@vintners.net> Date: Fri, 09 Jan 2009 19:45:52 -0800 From: Mike Lempriere User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-stable@FreeBSD.ORG, freebsd@byshenk.net, Andrei Kolu , Mike Lempriere References: <200901081047.n08Alg2h000825@lurza.secnetix.de> In-Reply-To: <200901081047.n08Alg2h000825@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.4 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00, RGX_BDY_LOCAL_AREA_CODE,RGX_BDY_SINGLE autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on vinifera.vintners.net Cc: Subject: Re: mergemaster broken -- take 2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 03:45:57 -0000 Thanks everyone for the advice -- I got it working this time just fine. Works much better when one follows the directions accurately instead of by memory -- the bottom line is that this time I remembered to jot down the commands before heading downtown to the machine rack room where there's no browser access... I started over and followed UPDATING: cd /usr/obj rm -R * cd /usr/src rm -R * cvsup -g -L 2 -h cvsup10.freebsd.org |& tee /root/cvsup-090108.out make buildworld |& tee /root/make-buildworld-090108.out make kernel KERNCONF=GENERIC |& tee /root/make-kernel-090108.out users ps ax | more shutdown -r now 4 (single user) fsck -p mount -u / mount -a cd /usr/src mergemaster -p make installworld |& tee /root/make-installworld-090108.out make delete-old (forgot to do tee redirect) mergemaster -i (did not do tee redirect) shutdown -r now Oliver Fromme wrote: > Greg Byshenk wrote: > > Andrei Kolu wrote: > > > Mike Lempriere wrote: > > > > Hi folks -- sorry to be a nag, but my main production system is barely > > > > limping along on an old kernel with mismatched libraries. I have no > > > > idea what else to do -- please help! > > > > --- > > > > I'm upgrading 5-stable (was at 5.5) to 6-stable, in preparation for > > > > 6-stable to 7-stable. > > > > No problems with cvsup, make buildworld, make installworld, make > > > > buildkernel, mergemaster -p. > > > > make installkernel, boot to single user. Then mergemaster -- blammo: > > As others have pointed out, the order is wrong, which caused > the problem Mike is seeing. > > The correct order is listed in /usr/src/UPDATING. > > > The reasons for the other methods being wrong are (as I understand them): > > > > - You should build your new world before building your new kernel, as > > it may be the case that some aspects of the new kernel build are > > dependent upon aspects of the new world build. If you build your > > new kernel before building your new world, you will be building > > your new kernel against the old world. > > In particular, building the kernel uses the new toolchain > (i.e. compiler, linker, make(1) binary and so on) that was > built in /usr/obj during buildworld. That's why you have > to do buildworld first, then "make kernel". > > > - You should install your new kernel before installing your new world, > > as it can be the case that some aspects of the new world will not be > > understood by your old kernel. A new kernel should always be > > compatible with an old userland/world, but an old kernel may not > > always be compatible with a new userland/world. > > That's correct. Note that your kernel config should include > the appropriate "options COMPAT_*" lines if you update across > a major version boundary, e.g. "options_COMPAT_FREEBSD6" when > you update from 6.x to 7.x. The GENERIC kernel already has > those. > > > > NOTE: I do not reboot my system until everything is updated. Why it is > > > necessary to boot new kernel and then upgrade world is beyound me..YMMW > > > > - I suppose that it is not strictly necessary to reboot between > > installing kernel and world, but I always do so. > > It _is_ necessary. If you don't reboot, you're still running > the old kernel which might not be able to support new binaries > and libraries that installworld will install on your system. > > For example, there may be new syscalls that the new binaries > will try to use, but the old kernel doesn't know about them. > It doesn't happen often, so you can get away without rebooting > most of the time. But it's risky, especially when updating > across major versions. So the recommendation is to always > reboot after installing the new kernel and before performing > the "installworld". > > It's also important that "installworld" is the last step > (except for mergemaster), because this is the point of no > return. As long as you still have the old userland (world), > you can still boot the old kernel and everything is fine. > You can start all over froms cratch, if necessary. > But as soon as you have started "installworld", your system > will not be able to work with the old kernel anymore. > > And remember: Always make a backup before you start to > update. And verify that the backup works. Better safe > than sorry. > > Best regards > Oliver > > -- Mike Lempriere- Home: mike@vintners.net Phone: 206-780-2146 Cellphone: 206-200-5902; text pager: mikelemp@tmail.com