From: Gene Heskett <gene.heskett@gmail.com>
To: Ken Moffat <zarniwhoop@ntlworld.com>
Cc: Randy Dunlap <randy.dunlap@oracle.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.36, make oldconfig broken
Date: Fri, 22 Oct 2010 22:43:37 -0400 [thread overview]
Message-ID: <201010222243.37890.gene.heskett@gmail.com> (raw)
In-Reply-To: <20101023013943.GB20750@deepthought>
On Friday, October 22, 2010, Ken Moffat wrote:
>On Fri, Oct 22, 2010 at 08:54:51PM -0400, Gene Heskett wrote:
>> It hasn't been edited since I ran it, so I'll attach it. Maybe you can
>> see something I missed.
>
>Hi Gene,
>
> I don't see anything that is immediately wrong (but, it's late and
>I'll be going to bed as soon as webkit has finished compiling on my
>desktop, so my concentration might be lacking), but it does seem
>overly complex. I've long since given up trying to script kernel
>builds, it mostly isn't necessary if you aren't creating a distro.
>
> I appreciate your comment about fingers - mine are mostly ok, but
>prone to operating in the wrong order so that I often generate typos
>such as 'teh'. What works for me is -
>
Damn, and I thought I had a patent on that. Or at least prior art? ;)
>1. build in ~/ : I often have current and "previous, but still
>usable" systems on the same machine, and I share /home between them.
>Arguably, building as a user may prevent some disastrous actions,
>but backups are always useful - I remember your past comments about
>using amanda so I'm sure you've already got that covered.
>
>2. for each kernel version of interest (typically, current and next
>- over time the old one drops out and a new one rolls in) :
> create a first version (untar, or untar and patch).
> I then rename it to 2.6.xx-stable or 2.6.xx-rc.
>
> For the patches I use
>bzcat /path/to/patch-2.6.whatever.bz2 | patch -p1
>(yes, send me tickets for "useless uses of cat" if you wish ;)
Noted. ;) But then I also use another script to drive the make and
install, with everything in it having an ' && \' at the end of the lines so
any error bails out right there leaving the message still on-screen
Its a bit longer as I've hacked around to ensure continuity over the years
of the firmware trees etc. I can post that too if anyone wants it.
>3. When I want to test a new -rc, or a release has come out, cd into
>the tree and
> head Makefile
>to confirm which (-rc) patch was last applied.
>revert that: bzcat /path/to/that-patch.bz2 | patch -p1 -R
>apply the new one
>
>and then just make oldconfig and continue (or, for the first rc of a
>new version, zcat /proc/config.gz >.config && make oldconfig.
>
> To keep track of errant fingers, you can read the commandline
>before hitting <enter>, you can also run 'make modules_install' as a
>user - it won't work, but it will confirm which version it is trying
>to install.
>
> Sorry if this comes across as trying to teach you things you
>already know, but the process should be simple enough to not need
>scripting! Of course, my video hardware doesn't need out-of-tree
>firmware nor other drivers. Perhaps in that situation I might try
>to script it all. From painful experience, the usual problem with
>scripts is a failure to detect errors or unexpected results. Keep
>things simple if you can.
I use the scripts, which of course are subject to internal revision if it
proves I am not doing it right, as a way to get absolute consistency. For
the makeit script, it has only one var, $VER, assigned at the top to be the
2.6.whatever its building. All I have to do if it runs to completion is
construct a new entry in /boot/grub/menu.lst. change the default and
reboot.
Otherwise I'd forget (senor moment ;) some step in the middle and wind up
needing more naproxin sodium to quell the headache I got from beating it on
the wall....
>ken
Ken may have a point, next time I reboot, I'll drag out an install cd and
run the memtest from it for at least 1 full cycle.
Another item I might add is that I have now tried several different number
formats for the kernel command line option vga=, trying std octal, std
0xhex, and plain decimal, but it always hangs like I'd entered vga=ask.
The boot continues normally in the selected 1680x1050x32 screen if I enter
either a 'z' or a '369' at that point. So something seems to be preventing
the vga= from working correctly as a command line argument. Who knows,
maybe there is a bad address line on one of the 4 sticks again and it hits
that exact address at each boot. Murphy again, darn him.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Old soldiers never die. Young ones do.
next prev parent reply other threads:[~2010-10-23 2:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-22 16:29 Re:2.6.36, make oldconfig broken Gene Heskett
2010-10-22 18:40 ` 2.6.36, " Randy Dunlap
2010-10-22 20:08 ` Gene Heskett
2010-10-22 21:20 ` Randy Dunlap
2010-10-23 0:54 ` Gene Heskett
2010-10-23 1:39 ` Ken Moffat
2010-10-23 2:43 ` Gene Heskett [this message]
2010-10-24 1:36 ` Randy Dunlap
2010-10-24 5:13 ` Gene Heskett
2010-10-25 14:23 ` Gene Heskett
2010-10-23 1:07 ` Ken Moffat
2010-10-23 2:18 ` Gene Heskett
2010-10-23 13:41 ` Ingo Molnar
2010-10-23 16:26 ` Gene Heskett
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=201010222243.37890.gene.heskett@gmail.com \
--to=gene.heskett@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=randy.dunlap@oracle.com \
--cc=zarniwhoop@ntlworld.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.