Re: Building kernel 2.6.8: I get an (uncompressed) vmlinux. Help, please!

From: Alan Mackenzie (
Date: 10/27/05

Date: Thu, 27 Oct 2005 08:32:20 +0000

Pre-script: I've now got my new kernel up and running. :-) It took me
about six hours to work out that I need the kernel parameter
"ide3=0xc400,0xc802,11" to be able to access my root partition. And
another hour reading matroxfb.txt to fix my tty, which had a 12 rows x 40
columns display. ;-) Many thanks to Peter Breuer!

Enrique Perez-Terron <> wrote on Thu, 27 Oct 2005 01:49:35
> On Wed, 26 Oct 2005 20:15:31 +0200, Alan Mackenzie <> wrote:

>> S.Brown <> wrote on Wed, 26 Oct 2005
>> 09:30:09 -0500:

>> Using kernel-package would mean yet another man page to read through
>> and digest, more gotchas to be checked for (will it overwrite my
>> lilo.conf, run lilo and leave me looking for a rescue CD?). I've not
>> read this man page (yet), so I'm assuming that the program builds a
>> kernel then puts in in a Debian package. What do I do with that
>> package? Simply run dpkg -i, and hope that my system will be bootable
>> afterwards? Yikes! No, I'd have somehow to extract the kernel image
>> from the package (more man pages to read) before writing it to disk
>> somewhere where LILO can find it.

>>> All it involves is a "make menuconfig" or equivalent, and then
>>> "make-kpkg" with the appropriate options for your situation, found
>>> via the man page or Google. You get a kernel-image-<your
>>> version>_<your arch>.deb all ready for you to install, modules and
>>> bzImage. The downside is that you still have to play around with
>>> mkinitrd if that is needed in your case.

>> kernel-package sounds like a layer of "user-friendly" fat on top of
>> the muscle of "make". If I had to build lots of different kernels, it
>> would doubtless save me lots of time. Seeing as how I'm only building
>> the kernel once or twice, the time taken to learn it and the
>> disorientation from wondering what the heck it's really doing would
>> wipe out any gains tenfold.

> Save a copy of your current kernel somewhere.
> Do the dpkg thing and let it ruin you machine.
> Pray to god, "just don't let it *reboot* my machine!"
> Supposing you are heard, run lilo yourself afterwards
> with the kernel(s) you want.

Why? The cost of using dpkg here, though not enormous, is non-trivial.
What benefit will it bring me? (That is a real question, not a
rhetorical one.)

> I haven't used Lilo for so long now, that I can't really remember, but
> I think I have seen others having a boot menu, so you can have multiple
> kernels selectable at boot time.

Sort of - The thing you select in Lilo's boot menu is a combination of
kernel and root partition. These are configured in /etc/lilo.conf. You
run lilo to put all the stuff into the boot sector.

> If not, ditch lilo like everybody else, and run grub.

> Grub first loads a standalone interactive program called "stage2",
> and then this "stage 2" is a very handy and flexible boot loader.
> The point is that "stage 2" almost never changes, so you can make
> kernels and copy them around, make all sorts of mistakes, but stage2
> stays put. You don't have to remember to run "grub" or "lilo" after
> you make a new kernel.

That would indeed be a great advantage. Several times yesterday I forgot
to run lilo before trying to fire up the new kernel. :-(

> The only problem is when Windows Xp overwrite sector zero of the boot
> disk. But that is equally problematic when you use lilo.

Windows XP (or 2000 or NT or 98 or 95) is problematic, full stop. I
don't have it and have no intention of ever installing it on any of my
important PCs. If I were ever to be forced to use it (which might well
happen, since the German tax authorities currently require firms and
freelancers to buy MS Software to submit tax returns with), I would buy a
cheap used PC. For security reasons.

> And of course, if you delete stage2 and install a new copy (identical
> or not) you must do the equilvalent of running lilo, because the stage1
> loader uses block lists to load stage2.

Just as lilo uses block lists to load kernels.

> Once stage2 is running, it understands file systems, directories and
> files, so it will find your grub config file and see there what kernels
> to offer, show you a menu, and load the kernel you choose.

Question: If stage2 can do this much, it must contain a fairly full
kernel and command interpreter itself. If so, why not just forget about
loading a "second" kernel and launch X-Windows and so on directly from
stage2's command interpreter? ;-)

> The standard kernel "make install" has code to put a new stanza in
> grub's config file *without removing the old one*. If you find this
> did not happen, or you arranged it so and you forgot to add a kernel
> manually, or you just want to add some other boot options, you just
> press "c" and you get a command line that allows you to enter boot
> commands to your heart's contents.

OK. If I were using grub, I could run dpkg -i on a new kernel without
worry. With lilo, there would be the danger of rendering the machine
unbootable. (I've managed this several times with "user friendly"
installation programs, particularly SuSE's.)

> Or you point to a menu kernel and press "e", and you can edit the
> commands associated with that menu entry, including specifying a
> different kernel altogether. This is handy because you can use an
> existing menu entry as a template, so you get the options and other
> details right.

Ah! So I could have played around with those accursed kernel parameters
much more easily with grub than with lilo. Hey, you've persuaded me!
Just as soon as I've got Sarge moderately well running, I'll get into

> Grub does have it's own small mysteries, though. Disks and partitions
> have names like (hd0) and (hd0,0) respectively. Grub uses Bios, and
> depends on the order in which the BIOS sees the disks (if at all).
> There is no distinction between scsi and ide, everything is (hd<n>),
> where <n> is a number starting with zero for hda. Partitions are
> numbered from zero too, so hda5 is (hd0,4).

My sole hard disk is /dev/hdg. (This is because the two IDE controllers
"on" the motherboard are the old-fashioned slower type, and the UIDE
controllers are bolted on to the motherboard as a sort of after-thought).
How then would I talk to the drive? As (hd3)? Or would it still be

> If you are unsure about what partition contains what, you can do

> > find /etc/fstab

> and grub will search all partitions, and tell you the grub name of
> all partitions that contain the specified path.

> You can then do, e.g.

> > cat (hd1,7)/etc/fstab

> If you can't remember the exact name of the kernel file(s), but know it
> is in the root directory of a partition that is mounted on /boot,
> you can do

> > root (hd0,5) # sets a default partition for subsequent commands
> > kernel /vmlinu<TAB

> and you will get filename completion just like in Bash. For some reason
> there is no "ls *linuz*", sorry.

> -Enrique

Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").