public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Albert Hopkins <marduk@gentoo.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] OT ( was : Cannot boot 2.6.21-gentoo-r4)
Date: Tue, 17 Jul 2007 23:59:36 -0500	[thread overview]
Message-ID: <1184734776.24546.36.camel@blackwidow.nbk> (raw)
In-Reply-To: <469D1788.3030603@gmail.com>

On Tue, 2007-07-17 at 14:24 -0500, Billy Wayne McCann wrote:
> My purpose for pasting this into this discussion is three-fold: to
> show
> why I said what I did, to hopefully dispel the notion that I merely
> made
> this all up, and to discuss the relevance of the pasted text itself.
> 
> I apologize for being off-topic and hope that Mick finds himself a
> working kernel config soon.  :) 

I hope he does as well.

Completely on a tangent from the OP, but I would like to argue *for* the
use of oldconfig when upgrading kernels. I read the relevant part of the
document and I'm not going to contest it, it does not seem to indicate
that "oldconfig" when upgrading kernels doesn't work, but that
"oldconfig" might somehow confuse the user into not selecting a kernel
option that they need.  OTOH if said person is using an "old config"
that worked then most, if not all, of the "needed" options are already
selected.  But what are the alternatives?  The document does not cite
any. I can think of four choices:

     1. "make menuconfig" and create a new .config from scratch.  From
        my own personal experience I know I'm *much* more likely to
        forget a needed kernel option starting from scratch than from an
        old config.
     2. Copy old .config and "make".  In this case you miss any new
        kernel options.
     3. copy old .config and "make menuconfig".  In this case you're
        much more likely to miss the *new* kernel options because they
        don't stand out from the old ones.
     4. Copy old .config and "make oldconfig".  Here you get prompted
        for any new kernel options, plus you keep all your old ones when
        feasible.

Or, if you're lucky enough to be using Gentoo, you could run genkernel.
However browsing the genkernel sources it seems to do 2, 3 or 4
depending on what options it is given. 2 seems relevant only if you want
to upgrade your kernel but not take advantage of any new features.  3 is
prone to overlooking the aforementioned features.  So that leaves 1
which is ridiculous and 4 which just about every other document found on
the net about upgrading kernels recommends, including the Greg
Kroah-Hartman's _Linux Kernel in a Nutshell_ (Greg being both a Kernel
and Gentoo developer).

I think that in general, and when used correctly, oldconfig is in fact a
very useful tool when performing kernel upgrades, but of course YMMV.


--
Albert W. Hopkins

-- 
gentoo-user@gentoo.org mailing list



  parent reply	other threads:[~2007-07-18  5:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-17 11:40 [gentoo-user] Cannot boot 2.6.21-gentoo-r4 Mick
2007-07-17 12:20 ` Billy McCann
2007-07-17 12:45   ` Mick
2007-07-17 13:19     ` Alan McKinnon
2007-07-17 14:02       ` Albert Hopkins
2007-07-17 15:35         ` Dale
2007-07-17 19:24         ` [gentoo-user] OT ( was : Cannot boot 2.6.21-gentoo-r4) Billy Wayne McCann
2007-07-17 20:11           ` [gentoo-user] Using oldconfig and kernel revisions " Billy Wayne McCann
2007-07-17 21:19             ` Stroller
2007-07-18  4:59           ` Albert Hopkins [this message]
2007-07-19 20:33             ` [gentoo-user] OT " Billy McCann
2007-07-20  6:49               ` Luigi Pinna
2007-07-20  9:02                 ` Ian Hastie
2007-07-20 12:42                 ` Albert Hopkins
2007-07-17 13:22   ` Re[2]: [gentoo-user] Cannot boot 2.6.21-gentoo-r4 Sergey A. Kobzar
2007-07-17 13:30   ` Neil Bothwick
2007-07-17 14:00     ` Mick
2007-07-17 14:46       ` Neil Bothwick
2007-07-17 15:18         ` Mick
2007-07-17 21:02           ` Peter Alfredsen
2007-07-17 22:20             ` Mick

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1184734776.24546.36.camel@blackwidow.nbk \
    --to=marduk@gentoo.org \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox