From owner-freebsd-questions@FreeBSD.ORG Sat Aug 16 07:49:14 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B12F1DED for ; Sat, 16 Aug 2014 07:49:14 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 41ACB2A16 for ; Sat, 16 Aug 2014 07:49:13 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XIYjN-0006wj-3C for freebsd-questions@freebsd.org; Sat, 16 Aug 2014 09:48:53 +0200 Received: from pool-173-79-82-127.washdc.fios.verizon.net ([173.79.82.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Aug 2014 09:48:53 +0200 Received: from nightrecon by pool-173-79-82-127.washdc.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Aug 2014 09:48:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-questions@freebsd.org From: Michael Powell Subject: Re: buildworld and next kernel compilation Date: Sat, 16 Aug 2014 03:48:31 -0400 Lines: 72 Message-ID: References: <1408172733.5441.9.camel@debian> Reply-To: nightrecon@hotmail.com Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: pool-173-79-82-127.washdc.fios.verizon.net X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 07:49:14 -0000 Mohsen Pahlevanzadeh wrote: > Dear BSD man, > > Suppose i compile my kernel via: > > /////////////////////////////////////////////////////// > svn co svn://svn.freebsd.org/base/stable/10 /usr/src > svn up /usr/src > cd /usr/src > make buildworld > ### edit my MYKERNELCONF > make kernel KERNELCONF=MYKERNELCONF > shutdown -r now > ### boot via single user and use the following commands: > mount -u / > mount -a -t ufs #my fs is ufs > swapon -a > adjkerntz -i > mergemaster -p > cd /usr/src > make installworld > mergemaster -iF > make delete-old > reboot > make delete-old-libs > /////////////////////////////////// > > My question: suppose i need to again compile my kernel and add fooobar, > What do you suggesst procedure for compilation according to i compile > once? > > First, I cd to /usr/obj and rm -rf usr and rm -rf lib32 so there is no cruft left over from any previous build. In other words, blow away everything under /usr/obj. I believe there is a target for doing this but haven't tried that approach in a very long time. I think it's something like doing a make clean in /usr/src which accomplishes the same thing. IIRC doing make kernel combines both make buildkernel and make installkernel into one operation; I just prefer to do one at a time as a purely personal quirk. The choice depends on whether any source code has changed, e.g. if you have done another svn up /usr/src then you will want to do the whole make buildworld/installword thing again or your kernel and userland will become out of sync with each other. If there has been no update, the source tree is the same as before with no change (other than an edit to a kernelconf file) then you can simply just do a make buildkernel, make installkernel, and reboot (or combine with make kernel). What you don't want to have happen is a kernel that has been built from sources that differ from what world was built from. As long as the source is the same you can just build new kernel(s) and install without having to do anything else. Couple of hints here too: each time you build a new kernel the current running kernel will be moved to kernel.old. This allows for to boot to kernel.old should you somehow install a defective kernel. Note that if you were to somehow get into the situation where you somehow built two kernels in a row that were bad you will have lost the first kernel.old that was a working kernel. It's kind of an odd situation to get into and isn't really very likely, but the possibility is there. The make delete-old-libs (last line above) is something you need to be careful with. It isn't really needed in a minor revision update such as upgrading from 9.2 to 9.3 because the ABI has not changed and all your installed ports are still linked against the same library versions. However, this situation is different when a major update takes place, e.g. an upgrade from 9.x to 10.x will require you to rebuild all the ports so they link against the new library version bumps. Do NOT run the make delete-old-libs until AFTER successfully rebuilding all installed applications. -Mike