From owner-freebsd-stable Tue Apr 30 10:18: 5 2002 Delivered-To: freebsd-stable@freebsd.org Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by hub.freebsd.org (Postfix) with ESMTP id 004F337B41F for ; Tue, 30 Apr 2002 10:17:57 -0700 (PDT) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP id GQF37091; Tue, 30 Apr 2002 10:17:55 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Postfix) with ESMTP id 2CC015D04; Tue, 30 Apr 2002 10:17:55 -0700 (PDT) To: Mike Meyer Cc: pjklist@ekahuna.com, stable@FreeBSD.ORG Subject: Re: Build sequence (was Re: mergemaster theory (was: Re: /etc/defaults/rc.conf theory) ) In-reply-to: Your message of "Tue, 30 Apr 2002 11:57:44 CDT." <15566.52488.880073.197196@guru.mired.org> Date: Tue, 30 Apr 2002 10:17:55 -0700 From: "Kevin Oberman" Message-Id: <20020430171755.2CC015D04@ptavv.es.net> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Date: Tue, 30 Apr 2002 11:57:44 -0500 > From: Mike Meyer > > In <20020430161355.14FEB5D05@ptavv.es.net>, Kevin Oberman typed: > > > From: "Philip J. Koenig" > [SNIP] > > > So I tried the 'accepted' sequence of installing the kernel before > > > the world yesterday. > > > > > > One thing I have always done prior to running mergemaster is to set > > > the console to 132 columns to make it easier to view long lines and > > > to facilitate merging files. > > > > > > When I was running this new kernel (mismatched to the world) > > > vidcontrol was completely broken, none of its commands would work. > > > (anything I typed got met with something along the lines of "must be > > > on virtual console, inappropriate ioctl for device". This problem > > > went away after installing the world.) > > > > > > So I couldn't do anything with the default screen settings. > > > > > > I'd say it's a good example of the kinds of things that can break > > > when you do it that way. So it appears each method has its pluses > > > and minuses. (Maybe the ideal would be to test the new kernel then > > > revert to the old to build the new system, but that would require a > > > 2nd reboot) > > > > It is true that running a new kernel against an old userland may cause > > several things not essential to installing world or running > > mergemaster to fail. This is not always the case, but is always a > > possibility that increases with the time since sources were previously > > updated. > > What's missed here is that running an old kernel and a new userland is > more likely to screw things up. After all, the new kernel has to > maintain backwards compatability with old binaries to some degree to > keep old packages working, so you can expect most things to work > properly. Doing it the other way means you may have userland utilites > looking for kernel functionality that isn't there yet. Both are > unlikely, but running the new kernel first not only tests it before > doing something hard to back out, but is slightly safer. I completely agree! As I said, doing an installworld before booting the new kernel is an invitation to disaster. But booting the new kernel and then going back to the old to installworld should be safe and provide full system functionality when running mergemaster. I actually liked the other suggestion for using the new vidcontrol (or any other kernel linked program) for mergmaster after booting the new kernel. It's safe and avoids a reboot. The required aliases can also be put into a simple script to make it easier to use them. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message