From owner-freebsd-stable@freebsd.org Tue Dec 13 09:51:34 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6BD56C701A2 for ; Tue, 13 Dec 2016 09:51:34 +0000 (UTC) (envelope-from herbert@mailbox.org) Received: from mx1.mailbox.org (mx1.mailbox.org [80.241.60.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.mailbox.org", Issuer "SwissSign Server Silver CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B9851A29 for ; Tue, 13 Dec 2016 09:51:33 +0000 (UTC) (envelope-from herbert@mailbox.org) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id D771D43D0C for ; Tue, 13 Dec 2016 10:51:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailbox.org; h= content-type:content-type:mime-version:references:in-reply-to :subject:subject:from:from:message-id:date:date:received; s= mail20150812; t=1481622651; bh=OUzGMD1UikPddyn3JTrHsc3kMEIlCFGv4 6Z7Xxe+wM8=; b=nJva8SU8H5MUVAKsEu6SbPvovVUVwIYHVaTc2lYRsWDdAb80C HVj0aZ5lvBNHu1lTDkP02fDXbf/2UzqxLcC02/5QtxRReaMMcgcOzT8ASaBD0y84 7/IIM56d1rdayxtSlwGT1fdhnn/FX65H32+18DyjLOWSBzPH/GuMTrgu/Wv/3Xsx snMdZou+Ebc8jPHp0dTT+MLaMOTyWdWrp6LnGb1v88ZpQ0NQyCFaH3tdHhO4cfIr RjFDHF7IDz3hYcU4bdyNDmqW61jzGgxiTzVe0WmVQXZurvlOGBsJm2arBaL1hOuZ p1h9DM3ffu7X/PT5j4zZQ7vWVEpGYeDmX1pTQ== X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id vQFwu-YeiVW2 for ; Tue, 13 Dec 2016 10:50:51 +0100 (CET) Date: Tue, 13 Dec 2016 10:50:50 +0100 Message-ID: <867f74cg3p.wl-herbert@mailbox.org> From: "Herbert J. Skuhra" To: freebsd-stable@freebsd.org Subject: Re: make buildkernel does not respect KERNCONF or JOBS in /etc/make.conf In-Reply-To: References: <201612120138.uBC1cA59025994@sdf.org> <86r35dd46x.wl-herbert@mailbox.org> <9B.7B.16304.3F86E485@dnvrco-omsmta02> <15672f53-1a34-3120-0aa8-03aa6401be54@zyxst.net> <86pokwptmd.wl-herbert@mailbox.org> MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 09:51:34 -0000 Kevin Oberman skrev: > > On Mon, Dec 12, 2016 at 4:20 PM, Herbert J. Skuhra > wrote: > >> Kevin Oberman skrev: >> > >> > Clearly the documentation is a bit behind the times. For some time people >> > have used KERNCONF to build multiple kernels, but that was a lucky things >> > that was not officially supported. It just happened to work. Then, with >> > 11.0, it no longer did in many cases sue to changes in the kernel build >> > system. When people complained, there did not seem to be a way to fix >> this >> > without blocking future goals in speeding up and enhancinghte standard >> > kernel build. >> > >> > The result was BUILDKERNELS. It was specifically designed to allow the >> > building of multiple kernels and the appropriate modules. This would >> always >> > take longer and use more disk space, but it would work reliably. Now, bit >> > building a single, local kernel, KERNCONF is the best way, though I >> suspect >> > that it make only a small difference until new capabilities are added >> later >> > in the life of 11. >> > >> > So, while it seems the man pages need to catch up, building multiple >> > kernels should be done with KERNCONF in either make.conf or src.conf and >> > multiple kernels with BUILDKERNELS. >> > >> > This is from my recollection of the discussion thread. I'll admit to >> being >> > too lazy to go find and read all of it. I suspect it was on current@, >> but >> > I'm not even sure of that. >> >> ??? >> >> From /usr/src/Makefile.inc1: >> >> 1137 .if ${TARGET_ARCH} == "powerpc64" >> 1138 KERNCONF?= GENERIC64 >> 1139 .else >> 1140 KERNCONF?= GENERIC >> 1141 .endif >> [...] >> 1149 BUILDKERNELS= >> 1150 INSTALLKERNEL= >> 1151 .if defined(NO_INSTALLKERNEL) >> 1152 # All of the BUILDKERNELS loops start at index 1. >> 1153 BUILDKERNELS+= dummy >> 1154 .endif >> 1155 .for _kernel in ${KERNCONF} >> 1156 .if exists(${KERNCONFDIR}/${_kernel}) >> 1157 BUILDKERNELS+= ${_kernel} >> 1158 .if empty(INSTALLKERNEL) && !defined(NO_INSTALLKERNEL) >> 1159 INSTALLKERNEL= ${_kernel} >> 1160 .endif >> 1161 .endif >> 1162 .endfor >> >> So setting BUILDKERNELS has no effect. >> >> -- >> Herbert >> > > I think you miss the significance. BUILDKERNELS only is used to build the > kernels. It is not used by installkernel as installing two kernels does not > make sense. It is ONLY used to build multiple kernels. KERNCONF is still > used to specify the kernel, with attendant modules, to be installed. > > I should also mention that, if you want to install a new kernel without > overwriting the old kernel and modules (/boot/kernel.old/), "make > reinstallkernel". It replaces the existing kernel instead of renaming the > kernel directory to kernel.old. I find this very handy, but it is poorly > documented. So, if you want to install GENERIC and not lose your last > working kernel, "make reinstallkernel KERNCONF=GENERIC". That will blow > away the bad kernel and modules and install GENERIC. Note that it does not > touch the /usr/obj directory that PUMPKIN is built in, so PUMPKIN and > similarly be reinstalled. > > The man page for src.conf is automatically generated and only lists those > values which are specific to src.conf (WITH_ and WITHOUT_) and describes > its use. It is used as input for system builds and installs but should not > be accessed for any other purpose. make.conf is always read by make with no > regard to what is being made. (N.B. I believe that some people have ignored > this in some ports stuff.) Anything that is put into make.conf may be > placed in src,conf if you only want to have it used when > building/installing the kernel and world. > > I'm probably forgetting something, but I hope this explains it a bit. Sorry, but why are you telling (me) all this? :) Can we return to the OP's issue? How does setting BUILDKERNELS (as suggested by Scott B.) resolves (t)his issue? His problem is obviously PORTS_MODULES (see my previous message). -- Herbert