From owner-freebsd-current@FreeBSD.ORG Sun Aug 14 19:38:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01823106564A; Sun, 14 Aug 2011 19:38:02 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9B37E8FC08; Sun, 14 Aug 2011 19:38:01 +0000 (UTC) Received: by vxh11 with SMTP id 11so4620799vxh.13 for ; Sun, 14 Aug 2011 12:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pH1JwNZaiIVbcvJCfLf9aVm9ZDzJ4iHD09lFkF4KbUY=; b=wvwFnpNU451OEVhDoASEso5dMeWuqjdvPL+OPcT3lBdtM5Qm+0TNyD4v2k4FAyz0aA t8S5z7iY6qSDGQtM8ntw7Fgc+hWc9nLAUutyHHYRwpbnM9otPcqEWHsgOpHWImMTtZLj pB5cCzJE5RrwHQ1IwxsmiJMLwNmrKXMV/EJjg= MIME-Version: 1.0 Received: by 10.220.100.69 with SMTP id x5mr937607vcn.19.1313350680904; Sun, 14 Aug 2011 12:38:00 -0700 (PDT) Received: by 10.220.186.134 with HTTP; Sun, 14 Aug 2011 12:38:00 -0700 (PDT) In-Reply-To: References: <20110813195127.GA34295@freebsd.org> Date: Sun, 14 Aug 2011 12:38:00 -0700 Message-ID: From: Freddie Cash To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Alexander Best , freebsd-current@freebsd.org Subject: Re: [rfc] replacing /boot/kernel.old with a unique directory name X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 19:38:02 -0000 On Sun, Aug 14, 2011 at 11:35 AM, Garrett Cooper wrote: > On Sun, Aug 14, 2011 at 10:56 AM, Freddie Cash wrote: > > On Sat, Aug 13, 2011 at 12:51 PM, Alexander Best >wrote: > > > >> hi there, > >> > >> i just had the following idea: how about instead of copying the current > >> kernel > >> to /boot/kernel.old and then installing the new one under /boot/kernel > as > >> the > >> results of target installkernel, we create a unique directory name for > the > >> old > >> kernel? > >> > >> something like /boot/kernel-r${revision}-${/dev/random}? > >> > >> that would let people not only boot the previous kernel, but all kernels > >> that > >> have been replaced by target installkernel. this would make tracking > >> issues, > >> which have been introduced by a certain commit much easier, imho. > >> > >> i don't think implementing this logic would be that difficult. the only > >> problem > >> i see is with ${/dev/random} in the case where people are running a > kernel > >> without /dev/{u}random support. > >> > > > > A better method may be to use KODIR to install the *new* kernel to a > unique > > directory via installkernel (make KERNCONF=SOMEKERNEL > > KODIR=/boot/SOMEKERNEL-rev-whatever installkernel) and then using > "nextboot > > -k SOMEKERNEL-rev-whatever" to set that kernel as bootable on the next > boot. > > > > You reboot, make sure everything works with SOMEKERNEL-rev-whatever, and > > then make that the default kernel (rm -rf /boot/kernel; cp -Rvp > > /boot/SOMEKERNEL-rev-whatever /boot/kernel; shutdown -r now). > > > > Sure, it's not automated yet, but the building blocks are there. > > > > This way, you never disturb the currently working kernel until you know > the > > new kernel works. And if things go south with the new kernel, a simple > > reboot is all that's needed to revert back to the working /boot/kernel. > > > > All that's needed is to automate things a bit (pick KODIR, set nextboot, > > create a post-install target of some kind to run after booting the new > > kernel). > > > > And, this leaves all of your kernels around if you want to play with > > different ones. > > Again, why build more complexity into the system when it does what > you want in a more generic manner? Just to illustrate what I do on a > weekly basis, here's my script and example invocation (I have other > instances where I have more KERNCONFs and things are more > complicated). You shouldn't have to do much more than what I did below > when dealing with your specific case of interest -- especially > because, as you and others have identified elsewhere it may not work, > it might fill up whatever partition /boot is on, etc. > Unless I'mmissing something, we're saying essentially the same thing (install new kernel to unique directory) , but you've done the work to actually automate it. :) -- Freddie Cash fjwcash@gmail.com