Lesson 1: Building and running a new Linux kernel

Printer-friendly versionPrinter-friendly version

What's this all about then?

Quite simply, this is a tutorial on how to download, configure, build, install and reboot a new Linux kernel. It's also the first lesson in what will be a multi-lesson course on introductory Linux kernel programming, but I don't need to get into that at the moment. Instead, I'd rather just get down to business since there will be plenty of time later to take the long view, and lay out the plan and so on.

And, yes, I know this is supposed to be a course on Linux kernel programming for beginners, but we definitely need to establish the fundamentals first. So the first few lessons will concentrate on kernel configuration and build issues, and we should get around to having you write and run your first kernel module by lesson four. So be patient -- it will all be happening in due course.

And on that note, let me make a brief disclaimer. This first lesson will be a bit more terse than what I normally write since I simply want to get this done and published and let readers start playing. I'll come back over the next day or two, add a few more thoughts, clarify anything that needs clarifying -- you know, that sort of thing. But for me, it's time to stop talking and start writing so you folks can start experimenting.

Most importantly, there's a comments section at the bottom of this piece, so I encourage you to ask questions, make observations, demand clarification, whatever you want. This is meant to be interactive, so by all means, interact. And there is one more point to be made.

This is the first of four free kernel programming lessons that will lead into my proposed online kernel programming course that you can read about here. In short, after this and the next three lessons, you'll know whether you want to enroll for the rest of the course. All I can say is, I will do my best to make it worth your time. And if you want to keep up with breaking developments, feel free to follow me on Twitter.

Why would you want to build your own kernel?

Good question and, later, I'll come back and fill this in. For now, I'll simply answer -- because you can. And for a lot of people, that's a good enough reason right there.

What should you be running before you get started?

Ah, an excellent question, given the variety of Linux distros out there. Building and booting to a new kernel should really be distro-agnostic -- the process should be (with subtle differences) pretty much the same from distro to distro and I'll try to document the differences you need to care about. But to maximize your chance of success, I'm going to pick a particular distro and version and demonstrate the process based on that. Which means that if you're running the same combination, what follows should just work. And I don't make that claim lightly. Let me explain.

Perhaps the most frustrating aspect of a lot of documentation is the occasional waffling, when the author writes something like, "And if that doesn't work, try ...". Yes, that can be annoying because, if you're trying to follow along, it can be disheartening to realize that the instructions you're reading aren't guaranteed to work. And that's where this lesson (and all others to follow) are going to try to be different.

If you're using the same distro I am, and you install the same packages, and you follow the instructions to the letter, then what you're doing should just work. With no exceptions. Guaranteed. If it doesn't, and you've done everything correctly, then I'm the one who screwed up. Let me know, and I'll fix it. Because this shouldn't end up being guesswork or trial-and-error on your part.

And on that note, the distro I've settled on for this is Ubuntu 10.04, for no particular reason. I've written the same material for Fedora and all of this should work equally well for Fedora, but I wanted to give readers the opportunity to match my working environment exactly. So if you have the freedom, install Ubuntu 10.04 on your favourite system, and bring it up to date. And we'll take it from there.

What packages do you need?

I'm going to assume that you at least have the background to
install the standard development environment on your system. You know, gcc, make and so on. If you're missing an essential package, you'll know quickly enough. In addition, you'll want to install the git utility for version control and checkout. On Ubuntu, it's:

$ sudo apt-get install git-core

In addition, to use any of the kernel configuration targets you'll see in the next lesson, you'll need the Curses development library:

$ sudo apt-get install libncurses5-dev

Beyond that, I can't think of anything else that won't already be on a standard Ubuntu install, but feel free to correct me in the comments section.

Taking a look around the system at the existing kernel bits and pieces

Before we go any further, let me introduce you to the existing kernel components on your system so you can see what goes into the bootable kernel bits, and also so you can see what's going to change after you build and boot your new kernel, because it's immensely valuable to appreciate the differences before and after you do certain steps, so let's check out the parts one by one.


The uname command tells you about your running kernel. It has various options, but the one I normally care about is just -a, for all information. My system:

$ uname -a
Linux lynx 2.6.35-kwlug+ #1 SMP Mon Jun 7 13:13:50 EDT 2010 x86_64 GNU/Linux

That shows that I'm running some variation of the (unreleased) 2.6.35 kernel, and one I built as a demo for local Linux users group. And it's the command you'll run after you boot your new kernel to verify that, yes, you really are running that new kernel. So that's bit number one. On to the other bits.

The kernel image and initrd and config info

All the good stuff is going to be under your /boot directory. Here's what mine looks like:

$ ls /boot
abi-2.6.32-21-generic         memtest86+.bin
abi-2.6.32-22-generic         System.map-2.6.32-21-generic
config-2.6.32-21-generic      System.map-2.6.32-22-generic
config-2.6.32-22-generic      System.map-2.6.34
config-2.6.34                 System.map-2.6.34-rc7
config-2.6.34-rc7             System.map-2.6.35-kwlug+
config-2.6.35-kwlug+          vmcoreinfo-2.6.32-21-generic
grub                          vmcoreinfo-2.6.32-22-generic
initrd.img-2.6.32-21-generic  vmlinuz-2.6.32-21-generic
initrd.img-2.6.32-22-generic  vmlinuz-2.6.32-22-generic
initrd.img-2.6.34             vmlinuz-2.6.34
initrd.img-2.6.34-rc7         vmlinuz-2.6.34-rc7
initrd.img-2.6.34-rc7.new     vmlinuz-2.6.35-kwlug+

Obviously, I have a number of bootable kernels in there. Some are stock Ubuntu offerings, while others are clearly hand-rolled by me. Each bootable kernel should be represented by a combination of matching files:

  • vmlinuz-2.6.35-kwlug+: The compressed, bootable kernel image
  • initrd.img-2.6.35-kwlug+: The initial ram disk -- an early root filesystem that allows your kernel to bootstrap and get essential device drivers to get to the final, official root filesystem
  • config-2.6.35-kwlug+: The record of the configuration
    parameters for that kernel

And why do you care about all that? Because once you think you've configured and built and installed a new kernel, you're going to check that directory again and make sure that you have new files corresponding to all of the above. Because if you don't, something's gone horribly wrong. So the above is going to act as a sanity check to make sure your build process worked properly before you try to reboot. So far, so good? And finally ...

The kernel-specific loadable modules

Each kernel installed on your system will have a corresponding directory of loadable modules to go with it. This is what it looks like on my system at the moment:

$ ls /lib/modules
2.6.32-21-generic  2.6.32-22-generic  2.6.34  2.6.34-rc7  2.6.35-kwlug+

Not surprisingly, after we build and install a new kernel, we should expect to see a whole new directory of modules there.

The GRUB configuration file

The last essential bit to booting to a new kernel is that you need to add an entry for your new kernel into the GRUB bootloader configuration file on your system. On Ubuntu, that file is here:

$ cat /boot/grub/grub.cfg

Don't worry if it looks like gibberish at the moment. The only thing to remember is that once you've built and installed all your new kernel bits and pieces, you have to run the appropriate utility to add entries for it to your GRUB config file; otherwise, GRUB will never know about it and you'll never be able to boot it. Don't worry -- you'll be doing that later.

Getting the kernel source

You can get a kernel source tree in a number of ways but let me make this easy -- let's live out on the edge and use the contents of the working Git repository, so you can brag to your friends that you're tracking the bleeding-edge developments. It's more fun that way.

Assuming you've installed whatever package gives you the fundamental git command, simply pick a location somewhere in your normal user home directory or underneath it and:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6

and let me emphasize something about the process so far.

You do not need root/superuser access to download a kernel source tree, or to configure it, or to build it. You will need root privilege only to install the final product(s) in /boot and to upgrade the GRUB configuration file. But until then, you have no need for root privilege.

In any event, pick a location, start that git command running and, depending on your bandwidth, go for coffee.

The configuration process

Now that you have your kernel source tree, you need to configure it, which involves selecting which features you want built into the eventual kernel image, which features you want built as loadable module, and which features you want to omit entirely.

If you are so inclined and you've done this sort of thing before, you can jump right in and run one of the configuration variations like:

$ make menuconfig    [my favourite]

but that assumes you have a pretty good idea of what you want that would be appropriate for your system. If you don't have that kind of background, you'll want to take the safer route. [I may devote a future lesson to nothing but the intricacies of the kernel configuration process. Believe me, there's enough there to fill a lesson. But not right now. Onward.]

NOTE: All of the make commands you see here must be run from the top of the kernel source tree.

The obviously easiest thing to do is to configure your source tree to match as closely as possible the configuration of your running kernel. What could be a safer choice? Build your new kernel to resemble as much as possible your current kernel.

To do that, use the existing configuration file as the basis for your configuration thusly. Move to the top of your new kernel source tree, and copy an appropriate config file:

$ cp /boot/config-2.6.32-22-generic .config

What the above does is copies what should be a reasonable config file for your system into the hidden .config file at the top of your kernel source tree. Since the purpose of the normal configuration process is to take all your choices and generate that .configfile, all you've effectively done is short-circuit the configuration step and grab what you want as the end result, at which point you would run the following command which tweaks that config file to bring it into line with the kernel source:

$ make oldconfig

But wait. There's a bit more to this story.

It's entirely possible that that existing .config you used as the basis for your configuration isn't quite up to date; that is, it may have no entries representing extremely new features that have been added to the kernel. If that's the case, the above config step will stop at each one of those choices and ask you what to do. And if you're new to building a kernel, you may not know the right answer.

One solution is to just keep hitting ENTER and take the default, but that can get tedious. A faster solution is:

$ yes '' | make oldconfig   [two single quotes, no space between]

Why the above works is left as an exercise for the student. In any event, what you end up with is a .config file that is based as closely as possible on one you know that works and has also been adjusted to exactly correspond to your kernel source tree. So, at this point, you have your source and you've configured and recorded the result in that config file. Are you ready to build? Almost.

(As an aside, that .config file I keep talking about is simply a text file, and you're welcome to look at it:

$ less .config

Wasn't that exciting? Onward.)

Naming your new kernel

Not surprisingly, your new kernel needs to be somehow distinguishable from all of the other possible kernels you can boot, and that identification comes from the first few lines of the top-level Makefile in the source tree. Behold, an example:

NAME = Sheep on Meth

If your Makefile contains the above, the resulting kernel will have the "name" 2.6.35-rc2. To give your kernel a unique identifier, simply edit the Makefile and change the value of the EXTRAVERSION variable. For our build, let's go with:


You'll see what effect this has after the build. And constantly changing that EXTRAVERSION variable lets you build as many kernels as you like, if you want to experiment with tweaking them all slightly differently.

Doing the build

Really pretty simple:

$ make

Go for a beer. Come back. And if the universe unfolded as it should have, you have a new kernel and loads of modules ready to be officially installed.

Installing your new kernel and modules

If you've followed along so far, it should be fairly obvious what you need to do to take the results of your build and install all of it to make it bootable. What needs to be done:

  • Install the new (compressed) kernel image into the /boot directory so that GRUB can find it at boot time
  • Create (somehow) a new initrd initial ram disk that goes along with that kernel to support the early part of the boot process
  • Install all of the newly-built modules, which should show up under a new directory under the /lib/modules directory
  • Finally, run whatever command is appropriate to update the GRUB configuration file on your system to add entries for your new kernel so it can be selected from the GRUB menu at system startup
  • Different distributions supply different utilities to make the above more convenient but I'll do all of that manually so you can see the process in action. One step at a time (and, again, this is being done on Ubuntu 10.04 so if you're using a different distro, your instructions will be different), you'll run the following commands and, now, you'll need root privilege since you're copying files into system locations.

    $ sudo make modules_install
    $ sudo make install
    $ sudo update-initramfs -c -k 2.6.35-crash+
    $ sudo update-grub

    (NOTE: I just now noticed that the kernel that is built by the above is given a name with the suffix "crash+", not just "crash." I hadn't noticed this in earlier versions of the kernel build process and I'm guessing that it represents a build based on a checkout from a version control system. I'll verify that shortly; just take the time to check if you have the same result.)

    As I'm sure you can guess, each of those commands will install or update some system file or directory with the result of your build. You can run all of them at once, or one at a time and check the result after each one. (As a reader challenge, I'll let you deduce what change each command produces.)

    Once all of the above is done, you can verify that everything seems to have been installed properly by checking the following:

    • Does your /boot directory have a new kernel, initrd image file and config file corresponding to your build?
    • Is there a new modules directory for your kernel under /lib/modules?
    • Has your GRUB configuration file been updated to include an entry or entries for your new kernel?

    If you can answer "yes" to all of the above, you're probably ready to reboot to your new kernel.

    (Aside: I realize that Ubuntu has a utility called make-kpkg that allows you to take your build results and turn it into a dpkg-installable package, and I'll come back later and document that. But the end result would be exactly the same. So let's just go with the above for now.)

    Take a deep breath and ... reboot!

    If all of the above looks good, you might as well take a shot and try to reboot to your new kernel. That simply involves rebooting your system and holding down the SHIFT key to get the GRUB bootloader's attention, which should dump you into a menu from which you can select the kernel you want to boot. On Ubuntu, you actually get two new choices -- a normal kernel and a recovery kernel. Pick the regular kernel once you get to the menu.

    So ... did that work? Are you up and running under the new kernel? How can you tell?

    $ uname -a
    Linux lynx 2.6.35-crash+ #1 SMP Fri Jun 11 08:17:50 EDT 2010 x86_64 GNU/Linux

    There's your proof. Congratulations. You've arrived.

    And in conclusion ...

    I'll certainly be adding a few more thoughts to this piece based on reader feedback but here are some final notes to keep you busy and experimenting.

    First, what if booting to your new kernel goes horribly wrong and the system simply hangs? No problem -- just power cycle, pop back into the GRUB menu and select an older, reliable kernel. Then roll up your sleeves and try to figure out what went wrong and fix it.

    Next, even if the new kernel boots, that's no guarantee that every single feature that used to work still works. Test everything. Networking still there? Wireless still working? Sound still functioning properly? It's always possible that you'll have 98 per cent of your former functionality but some new kernel feature is causing trouble.

    If you take a look at the loadable modules that were installed and see how much disk space, it's likely that your loadable modules directory is massively larger than the ones that were there before. That's because you neglected to strip them when you installed them. To save disk space:

    $ make INSTALL_MOD_STRIP=1 modules_install

    The difference is noticeable but, eh, disk space is cheap.

    To start all over with a pristine source tree, you can remove every vestige of your build with:

    $ make distclean

    at which point you'll have to start the whole config/build process from scratch.

    Finally, if you want to keep up with current kernel developments, you can constantly:

    $ git pull

    and, if you think it's worth it, build a new kernel. It's entirely up to you.

    Final thoughts

    I'll still come back later and add a few more notes but, at this point, you know enough to give this a shot. Try it and let me know what happens in the comments section.

    And for further reading on kernel configuration and build issues, you really need a copy of Greg Kroah-Hartman's book Linux Kernel in a Nutshell. Seriously. Either read it online or buy it. Just get it somewhere.


Need a lesson on Grub... I

Need a lesson on Grub...
I thoroughly enjoyed the read. I have built and installed kernel but there were a couple of interesting information that i didn't know. I am up for the course. Also i would suggest for a lesson on using the Grub bootloader.

I'm still tackling the

I'm still tackling the intricacies of GRUB version 2. When I get a handle on it, you'll be the second one to know.

Good beginning. :-)

Good beginning. :-)

VmWare environment

Hi , I had a query , i am using an ubuntu installation on VMWare (win7 host....:( ). So after i build the new kernel , is there anyway i can get the grub screen via the VMware interface to choose to boot from the new kernel . Hope the question makes sense !!!

I have no idea.

The question certainly makes sense, I just don't know the answer. Anyone?

I feel your pain. The grub

I feel your pain. The grub screen passes quick and it is easy to miss, especially if you don't have the keyboard grabbed. A couple of suggestions.

It has been a while since I have worked with VMware workstation. In VMware ESX if you edit the VM settings and go the advanced tab there is an option to force the system into setup at the next boot. If you select that the system will boot into CMOS setup. Once there don't change anything just exit. Then pay attention and be ready to press the spacebar. That should give you the couple of extra seconds you need.

On my RHEL systems I edit the /boot/grub/grub.conf file and bump the timeout to 10 seconds. That usually gives me enough time to grab the system at the grub screen.

VmWare environment (minor update)

well, the new kernel boots, but i cant switch between the kernels at run time. i can ofcourse edit the grub.cfg and switch but not with the grub UI. i will update here if i find a way

Keep us posted.

If you figure out how to do it, yes, by all means, post a note. I may try something like that with VirtualBox later this week when I get the time.

Actually, holding the Shift Key during reboot works

I just compiled and rebooted holding the shift key. I was presented with the Grub menu and selected my new kernel

I'm running VMWare Fusion 3.1 on my Mac, but this should work with workstation as well.

Great one Rob. Really enjoying this and learning a lot so far.

I'm building now and about to run into the same issue

For once, google does not seem to be of help.

If I find something I'll post, but for now, I'm taking a snapshot in VMWare incase I need to roll back.

Great Tutorial on building & running a new kernel

It was easy to follow along and go through the steps. My kernel did exhibit problems with the video but I rebooted, went to the GRUB menu and selected the main kernel. One thing you might mention, in Ubuntu 10.4 it allows an automatic log on and this can block the ability to get to the GRUB menu.

Getting to the GRUB menu in Ubuntu 10.04

Even with the auto-login feature of Ubuntu 10.04, you should still be able to get to the GRUB menu simply by holding down the SHIFT key when booting. Since that takes effect long before the auto-login ever happens, whether or not you've configured auto-login should have no effect, but I'm willing to be corrected.

GRUB Menu in Ubuntu 10.04

I was able to get to the GRUB menu but with the auto login it just seems to go by faster. One additional thing you might want to check is there is no grub.cfg file. From what I can see, the menu.lst file gets updated to display the new kernel and the former menu.lst file is made hidden (menu.lst~).

This is a great beginning and I plan on taking the rest of the free courses and the ones you will be charging to take. I've always wanted to learn more about the Linux kernel.


A few questions, numerous ones

the lessons will always have printer availability?

I need the neccessary lines using Fedora12 to set up the necessary grub to finish lesson one. and go beyond.
Thanks for your help Terry linn

What you need for Fedora

As far as I know, all you need in order to boot to a new kernel under Fedora is, once you build the new kernel, install all that new content with:

# make modules_install
# make install

You can then check if the new content has been installed under /boot and that your GRUB configuration file has been updated by checking the Fedora GRUB file /boot/grub/grub.conf. Then just try to reboot to your new kernel.

I'll definitely be going back at some point and adding the Fedora information to these lessons at some point. For now, though, most of the lessons can be done running under the default kernel that comes with the distribution.

Printer availability?

Not sure what you're asking here -- once you register for the course, you'll have permanent online access to all of the lessons in this course forever and you're welcome to print them off for your personal use.

I *will* ask that you don't simply print them off and hand them to others who haven't registered (except for the first five lessons, which are publicly available and released under a Creative Commons license).

Does that answer your question?


what kind of hardware you recommend for your course?

Recommended hardware

You don't need any kind of powerful system for this course. As long as the machine can run Linux properly, you should be fine.

gconfig error

I copied config from my boot to new place where git created all files

make gconfig
* Unable to find the GTK+ installation. Please make sure that
* the GTK+ 2.0 development package is correctly installed...
* You need gtk+-2.0, glib-2.0 and libglade-2.0.
make[1]: *** No rule to make target `scripts/kconfig/.tmp_gtkcheck', needed by `scripts/kconfig/gconf.o'. Stop.
make: *** [gconfig] Error 2

make xconfig
* Unable to find the QT3 installation. Please make sure that
* the QT3 development package is correctly installed and
* either install pkg-config or set the QTDIR environment
* variable to the correct location.
make[1]: *** No rule to make target `scripts/kconfig/.tmp_qtcheck', needed by `scripts/kconfig/qconf.o'. Stop.
make: *** [xconfig] Error 2

Why I recommend "make menuconfig"

If you want to use the graphical targets "gconfig" or "xconfig", then you'll have to install the appropriate graphical libraries on your system (either GTK or Qt).

That's why I always recommend "menuconfig" instead -- since it has the simplest requirements of just the ncurses development library.

make xconfig issues.

I try to compile a new kernel and received the following error. Please help.

[root@cle2010 linux-2.6.34]# make xconfig
* Unable to find the QT3 installation. Please make sure that
* the QT3 development package is correctly installed and
* either install pkg-config or set the QTDIR environment
* variable to the correct location.
make[1]: *** No rule to make target `scripts/kconfig/.tmp_qtcheck', needed by `scripts/kconfig/qconf.o'. Stop.
make: *** [xconfig] Error 2

See the previous comment.

If you want to use the gconfig or xconfig targets, you'll need to install either the GTK or Qt libraries for your system. That's why I recommend using "make menuconfig" -- it's the simplest form but it lets you do all the configuration of the others. Just use "make menuconfig".

Space issues in VirtualBox

The compile failed when the disk filled up when using an 8GB virtual disk. Was able to complete the compile by removing a lot of the unneeded stuff that comes with a default install. After striping the modules I was left at 98% disk being used.

Seems VirtualBox does not let you increase the size of the virtual disk like Vmware does.

Recreated a new 12 Gb virtual disk, that I hope will be big enough.

Space issues

I ran into the same problem. What I did was to NFS export a directory on my host machine, and mount it from within virtual box. Now I have essentially unlimited space, and I can access the kernel source code from both the virtual box as well as the host machine.

make[3]: ***

make[3]: *** [drivers/mtd/chips/cfi_cmdset_0020.o] Error 1
make[2]: *** [drivers/mtd/chips] Error 2
make[1]: *** [drivers/mtd] Error 2
make: *** [drivers] Error 2

I get this error, after following the steps outlined in the above document. Im using Ubuntu 10.04.


drivers/mtd error

I've typically seen that error if someone has run that shortcut version of "make oldconfig" and used the command "yes ' '" instead of "yes ''". That is, there cannot be a space between those two single quotes.

Can you check again and verify if that's what you did? Thanks.

Bingo!! It was indeed the

It was indeed the problem you mentioned.Thank you very much.
Kernel build is happening now. As I wait, finishing off my Beer!! :-)

where to find the kernel?

I succeeded in the above task. But now where do i find the kernel? Is this the kernel arch/i386/boot/bzImage

shouldnt i be getting a file starting with the name vmlinuz-2.6.XXXX

where to find the kernel?

The uncompressed kernel is called vmlinux and it's the same directory as .config. vmlinux is an ELF file.

bzImage is the binary extracted from the elf, and wrapped in a decompressor.

behind proxy

actually out collage is having proxy so,

$git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6

this command is not working... it gives error as

$git.kernel.org[0:]: errno=Connection timed out

what to do??

behind proxy


I had the same problem and I solved it by this command:

git clone http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6



Thank you for an awesome course. I'm using Mandriva 2009.1 and the instructions worked. I also resorted to using the sources coming with the system /usr/src to cut on costs; yet the instructions worked. Thank you; now, onward...

If your system has multiple

If your system has multiple cores you can max them out by using "make -jx" where x is the number of cores+1.


Since this uses ubuntu 10.0.4 as the reference system, it would be useful to update the instructions for Grub configuration. I did not find a /boot/grub/grub.conf. Did you mean menu.lst?

Extremely interesting and helpful

I am new to linux, but this lesson was so good that I compiled and run my own linux kernel which is quite something for a newbie like me.
Very well done.

Version info in the source code

Great tutorial, Rob.

Question on the SUBLEVEL designation: is the build's "official value" found in the top directory Makefile? Or is it in a header file somewhere?

Can you tell me a little about how EXTRAVERSION is bumped (I assume -rc3 is 'release candidate 3'). What constitutes a bump of the RC level?

Also, who gets to define the NAME variable (the current value is "Flesh-Eating Bats with Fangs"? Does Linus define that himself? Is there any lore about these names/strings?


The values in the top-level

The values in the top-level Makefile reflect the ongoing, regular versioning of release candidates of the kernel, and they come from Linus. I have no idea of the etymology of these weird names.

Also keep in mind that the EXTRAVERSION value in that Makefile is kind of a moving target. As long as you keep doing a "git pull", you'll get the latest commits but that EXTRAVERSION value (say "-rc3") won't change until the next release candidate.

However, you always have the freedom to change that value to whatever string you want if you want to build a kernel that is clearly a custom kernel with a name that distinguishes it from any of your other kernels.

Error in build

I am using Ubuntu 10.04 LTS. The kernel building is failing showing the following errors
AR lib/lib.a
*** buffer overflow detected ***: ar terminated
4019f000-401bc000 r-xp 00000000 08:07 212583 /lib/libgcc_s.so.1
401bc000-401bd000 r--p 0001c000 08:07 212583 /lib/libgcc_s.so.1
401bd000-401be000 rw-p 0001d000 08:07 212583 /lib/libgcc_s.so.1
bfc29000-bfc3f000 rw-p 00000000 00:00 0 [stack]
make[1]: *** [lib/lib.a] Error 134
make: *** [lib] Error 2
My gcc version is 4.4.3.

If anyone encountered and fixed this problem, please let me know.

I'm fairly sure I've built a

I'm fairly sure I've built a kernel on Ubuntu 10.04. Can you do a "make distclean" and try again? And if you get the same error, post the *entire* build output at pastebin.com.

:( Didn't work

I tried distclean. But still same error. Please see the error in pastebin http://pastebin.com/myKCcZ0X

dont find the new kernel lsited in my grub.cfg

after running sudo update-grub I dont see the new kernel entry in the grub.cfg. hence I have no option to boto into the new kernel. Can you please let me know what could be the possible reason for this?

Simply Amaaazing

This is surely a place where kernel newbies should start .
Thanks Rob for the great work :)

New Kernel works only in Low Graphics Mode

Hey there,

Very good tutorial. I went through all the steps with success. However, when I boot the new kernel i get a message saying ubuntu will work in low-graphics mode.


Low graphics mode

What did you use in terms of configuration for your new kernel? Did your *existing* kernel boot to a proper graphics mode? What video card do you have?

I used the configuration file

I used the configuration file of my existing ubuntu kernel.
Yes, my existing kernel boots to a proper graphics mode.

Anyway, I was able to solve the problem, turns out it is something related the nvidia drivers.

I found the solution here in case someone has a similar problem:


no of kernel

is there any limitation as to how many kernels we can build?

No (theoretical) limit

As far as I know, there is no limit to how many kernels you can build and install. Your only possible limitations are:

1) If you have /boot on a separate partition, you'll eventually fill up that partition.

2) You have to keep editing the Makefile and add a unique identifying string to make sure you can distinguish between all those kernels at boot time.

Other than that, go wild.

P.S. To save space when you install modules, I recommend:

# make INSTALL_MOD_STRIP=1 modules_install

That strips out the symbol table and debugging information in the modules you probably don't need and the difference in size is significant.

kernel header location

Something I find annoying regarding VMware is that I always have to re-install vmware-tools every time I upgrade the kernel. But this isn't what I have a question about (unless someone knows of a way to reconnect vmware-tools to the new kernel without having to re-install the tools all the time).

Part of the vmware installation requires knowledge of where the kernel headers are located. My previous kernel headers were installed under '/usr/src'. The Linux source for the 'crash' kernel is in my home directory which is where the kernel headers are installed. Is there a way to get them installed under '/usr/src' like the others for consistency?

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <p> <br> <pre> <h1> <h2> <h3> <h4>
  • Lines and paragraphs break automatically.

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.