From owner-freebsd-stable Fri Oct 11 11: 8:30 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6010937B401 for ; Fri, 11 Oct 2002 11:08:26 -0700 (PDT) Received: from clover.kientzle.com (user-112uh9a.biz.mindspring.com [66.47.69.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD58843E9C for ; Fri, 11 Oct 2002 11:08:25 -0700 (PDT) (envelope-from kientzle@acm.org) Received: from acm.org (c43 [66.47.69.43]) by clover.kientzle.com (8.11.3/8.11.3) with ESMTP id g9BI8ME42742; Fri, 11 Oct 2002 11:08:22 -0700 (PDT) (envelope-from kientzle@acm.org) Message-ID: <3DA71396.6070009@acm.org> Date: Fri, 11 Oct 2002 11:08:22 -0700 From: Tim Kientzle Reply-To: kientzle@acm.org User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.6) Gecko/20011206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stable@FreeBSD.ORG, Jamie Heckford Subject: Re: Compiling a New Kernel References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 > Bizarre.... how could it be different/not work if you have > cvsup'd all of your sources including sys/ tree at exactly > the same time, and compile your kernel just after the > installworld? I only recently figured out the reasons behind the recommended sequence, so maybe I can now explain them to someone else. Problem: You're currently running an old system, consisting of old kernel, old world, and old configuration files. You have source code for a new system and want to compile and install it over the old system. Issues: * The old compiler might not be able to compile the new kernel. (Compiler upgrades do happen.) So, new kernel should be built with new compiler. In particular, new compiler must be built before new kernel is built. * The new world might rely on new kernel features. So, new kernel must be installed before new world is installed. These first two issues are the basis for the core buildworld/buildkernel/installkernel/installworld sequence that I'll describe in a moment. * Old world might not run correctly on new kernel, so installing new world must happen immediately upon installing new kernel. * Some configuration changes must be done before new world is installed, but others might break the old world. Hence, two different configuration upgrade steps are needed. Hence, the recommended sequence: 1) make buildworld This first compiles the new compiler and a few related tools, then uses the new compiler to compile the rest of the new world. Result ends up in /usr/obj 2) make buildkernel Unlike the older config MYKERNEL/make sequence, this uses the _new_ compiler residing in /usr/obj. This protects you against compiler/kernel mismatches. 2a) cp src/sys/${MACHINE_ARCH}/conf/GENERIC.hints /boot/device.hints If transitioning from 4.x to CURRENT, the kernel needs a new 'device.hints' file on disk. Not needed if upgrading to 4.7. 3) make installkernel Place the new kernel onto the disk, along with related modules and a few other tidbits. 4) Reboot to single user mode. Single user mode minimizes problems from updating software that's already running. It also minimizes any problems from running old world on a new kernel. (Curiously, moving from 4.x to CURRENT, you're still running the old kernel here, because the new kernel is in a different place and the boot loader hasn't been updated yet.) 5) mergemaster -p This does some initial configuration file updates in preparation for the new world. 5a) rm -rf /usr/include/g++ If transitioning from 4.x to CURRENT, the old C++ header files don't always get correctly updated. Deleting the old ones addresses this. 6) make installworld Copies the world from /usr/obj You now have a new kernel and new world on disk. 7) mergemaster Now you can update the remaining configuration files, since you have a new world on disk. 8) reboot A full machine reboot is needed now to load the new kernel and new world with new configuration files. Note that if you're upgrading from, say, 4.6.2 to 4.7, then this procedure may not be absolutely necessary, since you're unlikely to run into serious mismatches between compiler/kernel/world/configuration. But, when upgrading across major releases, people who don't follow this procedure should expect some problems. Yes, this procedure has evolved over time as the developers have found it impossible to completely prevent certain kinds of mismatch problems. Hopefully, the current procedure will remain stable for a long time (except for minor details such as steps 2a and 5a above, which may not be necessary by the time 5.0 actually is done.) Note that upgrading from 3.x or earlier is a bit trickier; read UPDATING carefully. Hope this helps, Tim Kientzle To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message