Compile the mainline Linux kernel for Ubuntu

This article will describe how you can compile the latest kernel from the official git repository in a Ubuntu way. As you can tell I’m not referring to any kernel version because this will work for any kernel version you can pull from the official repository, but for the better readability I’ll be compiling version 3.3.


I’ll be using git to get the latest kernel version. This is my favorite way to get the sources and it is in my opinion the fastest way to make changes later on when you want to update your own kernel to the latest version.
I suggest adding my Launchpad repository to your system. The repository holds the latest version of git and is usually updated within a day of a new release of git, follow the instructions on the page Git Packages for Ubuntu to add my repository.

I am compiling the amd64 which basically is the version used for all 64 bit versions, if you want to compile for i386 you need replace amd64 for i386 throughout this article.

I choose the name i7 as the flavor name as I’ll be building a kernel geared towards my laptop which has a i7 processor. Besides the change of processor type in the configuration I also have some other changes but that’s beyond this article.


Let’s get started by preparing our machine for compiling the Linux kernel.
Open a terminal.

sudo su -
apt-get install fakeroot build-essential devscripts
apt-get install crash kexec-tools makedumpfile kernel-wedge
apt-get build-dep linux-image-$(uname -r)
apt-get install git libncurses5 libncurses5-dev libnewt-dev

Create a directory where you would like to build your kernel, this directory will hold the kernel source in a sub directory and all the deb files will end up in this folder. I choose /d1/development/kernel/vanilla/

Getting the source

The mainline repository is big, so cloning the repository will take a while, depending on your Internet speed.

cd /d1/development/kernel/vanilla
git clone git:// source
cd source

The source code of the kernel is installed in the directory source.

We’ll check the tags set by Linus to determine which version we want to compile

git tag|sort -V

In our case we will use version v3.3

In order to compile in the Ubuntu way we will add a Ubuntu remote repository to our local repository. For this article we will use the Ubuntu 12.04 (Precise) repository.

git remote add precise git://
git fetch precise
git checkout -f precise/master

Creating a branch
We will create a branch in which we will be doing our modifications. That way the master branch will stay in tact, which will make it a whole lot easier when we want to update our own Ubuntu kernel with a newer mainline version at a later time.

As determined earlier we will checkout v3.3 of the mainline kernel.

git checkout -b i7 v3.3 --

This will create a branch called i7.

Ubuntunize the branch

We will pull in the needed Ubuntu files to compile like we already do in the other series I posted on the site here.

git checkout precise/master -- debian
git checkout precise/master -- debian.master

Create our own Changelog
In order to set the right version during the compilation, we need to change the changelog which is located in debian.master/changelog
First of all we need to determine which version of the mainline kernel we are compiling.

head -5 Makefile

This will display something like this

NAME = Saber-toothed Squirrel

The version numbering we will be using is VERSION.PATCHLEVEL.SUBLEVEL, which makes the version in our case 3.3.0 but for the changelog we need to expand this.
I use the following format: 3.3.0-999.201203231943
The 999 is used so whenever Ubuntu comes out with a 3.3.0 kernel for the Ubuntu version we’re running, our version will seem to be the newer. The 201203231943 is just the date + timestamp. The timestamp is used when we want to recompile the 3.3.0 version after we make some config changes, just update the time stamp and you have a newer kernel version.
It’s highly recommend to follow the version dash number dot number format.

The changelog needs a name and email address, if you want your own name and email change the DEBEMAIL and DEBFULLNAME.
To recreate the changelog

rm debian.master/changelog
DEBEMAIL=""; DEBFULLNAME="Peter van der Does"; dch -v 3.3.0-999.201203231943 --distribution precise --package linux --create -c debian.master/changelog Mainline build: v3.3.0

This will create the changelog in debian.master as follows

linux (3.3.0-999.201203231943) precise; urgency=low

  * Mainline build: v3.3.0

 -- Peter van der Does   Fri, 23 Mar 2012 19:44:07 -0400

Modify check files
During modification of configuration files and during the compilation process, Ubuntu does some checks to see if it all looks good but as we are not compiling a kernel with Ubuntu patches these checks might fail. Therefor we will be modifying these files and instead of doing it manually we’ll use a small script to accomplish the needed changes.

for i in debian/scripts/*-check debian.master/scripts/*-check
	if [ -f "$i" ]; then
		cat - <"$i"
exit 0
		chmod 755 "$i"

The above script is available for download.

At this time we will commit our changes with git so we don’t lose them.

git commit -a -m "Our own kernel"

Creating a new config

I’ll be using the method of creating a new flavor, this adds a bit more work but this allows you to always compile the original kernel, if you wanted to.

We’ll use the flavor you are currently running as the base for our own flavor being i7. Please note that, as discovered by one of the readers of this blog, the extension needs to be in small caps.

cp /boot/config-`uname -r` debian.master/config/amd64/config.flavour.i7
fakeroot debian/rules clean defaultconfigs

To make changes to the configuration file we need to edit the configuration file. The kernel developers have created a script to edit kernel configurations which has to be called through the debian/rules makefile, unfortunately we will have to go through all the flavors for this script to work properly.

debian/rules editconfigs

The script will ask us if we want to edit the particular configuration. We should not make changes to any of the configurations until we see the i7 configuration.

Do you want to edit config: amd64/config.flavour.i7? [Y/n]

We make our changes, save the configuration and then keep answering no to any other questions until the script ends.

When we’re done, we will commit the changes into the git repository.

git add debian.master/config/amd64/config.flavour.i7 
git commit -a --amend

Now we need to clean up the git tree in order to get ready for compilation.

git reset --hard
git clean -xdf

Getting ready for compilation

Because we are going to be creating a new flavor based on a existing flavor (generic in my case) we need to create some extra files. During compilation the process checks the previous release for some settings, as we’re creating a local flavor it doesn’t exist in the source, so we’re creating it.

To see the previous release we use:

ls debian.master/abi

The previous release in this case is 3.2.0-19.31

cp debian.master/abi/3.2.0-19.31/amd64/generic debian.master/abi/3.2.0-19.31/amd64/i7
cp debian.master/abi/3.2.0-19.31/amd64/generic.modules debian.master/abi/3.2.0-19.31/amd64/i7.modules

We need to edit some files:

File: debian.master/etc/getabis

Search for the line:

getall amd64 generic virtual

Change it in:

getall amd64 generic virtual i7


File: debian.master/rules.d/

Search for the line:

flavours        = generic virtual

Change it in:

flavours        = generic virtual i7


File: debian.master/control.d/vars.i7

This files does not exist and in order to make the compilation process aware of our own flavor we want to compile we need to create it.

cp debian.master/control.d/vars.generic debian.master/control.d/vars.i7

You can edit the file and make it your own.

arch="i386 amd64"
supported="I7 Processor"
target="Geared toward I7 desktop systems."
desc="=HUMAN= SMP"
bootloader="grub-pc | grub-efi-amd64 | grub-efi-ia32 | grub | lilo (>= 19.1)"
provides="kvm-api-4, redhat-cluster-modules, ivtv-modules, ndiswrapper-modules-1.9"

We need to commit our changes in the git repository.

git add .
git commit -a --amend


It’s finally time for compiling, to keep our newly created branch in pristine condition we will do the compilation in a separate branch. We keep our branch clean as this will help later on when we want to update our new branch to a newer kernel.

git checkout -b work
fakeroot debian/rules clean

All the packages will be created in the directory /d1/development/kernel/vanilla
Create independent packages:

fakeroot debian/rules binary-indep

The above statement will create the following deb files:


Create the tools package:

fakeroot debian/rules binary-perarch

The above statement will create the following deb file:


Create the flavour depended files:

fakeroot debian/rules binary-i7

The above statement will create the following deb files:


Install the new Kernel

After the compilation is finished we’ll have the above packages in the parent directory.

To install the files

cd ..
sudo dpkg -i linux-headers-3.3.0-999-i7_3.3.0-999.201203231943_amd64.deb linux-headers-3.3.0-999_3.3.0-999.201203231943_all.deb linux-image-3.3.0-999-i7_3.3.0-999.201203231943_amd64.deb

Check the bootloader if the newly installed Ubuntu kernel is the default one, for grub check the file /boot/grub/menu.lst or if we run grub2 check /boot/grub/grub.cfg

Reboot and enjoy our newly installed Linux 3.3 kernel.

This article is filed under the categories Ubuntu » Compile a kernel and has the following tags associated with it: , , , , .

For more of the same articles see the page Compile a kernel for Ubuntu overview
  • matt

    Nice job, Peter! Quick question for you about 3rd party modules: I’ve only been able to boot a 3.3 kernel where no 3rd party modules are necessary — in my case, my broadcom card is now supported ootb without dkms, modprobe, etc., but my desktop with an nvidia card seems to need some help provided by the 3.2/ubuntu method. Don’t even have a tty1 to try and reload the module.

    It looks like this method, using the ABI and the precise repository (brilliant – no overlay!), that my nvidia video module will be brought along. Do you think using the precise repository in this new method would work?

    Usually I’d just try it, but I was actually just about to clone the 3.2 and thought I’d save some bandwidth and cycles. Thanks again for the great write-ups!

    • Peter

      It could be that Ubuntu supplies a patch on top of the kernel for the nVidia driver. The method in the article doesn’t inject that patch. It only pulls in the files needed for compiling a kernel the Ubuntu way.
      My experience with nVidia is that I used to download the Linux driver from nVidia itself and use that, what you have to do in order to make that work is disable the Nouveau driver in the kernel. Located at
      -> Device Drivers -> Staging drivers because the 2 can not co-exist.

      • matt

        Ahh…I hadn’t gotten to the nouveau issue because the .run from Nvidia won’t run in X, and I’m without other ttys (at least on the dvi cable). Hmm…maybe it’ll work with another kernel, but then I suspect it won’t inject into the 3.3.0.

        Before doing that hacking, and maybe instead of it, I’ll go ahead and roll 3.2. The generic is almost as fast as my custom 3.0, anyway, and the card works out of the box, so just rolling precise should be quite an upgrade. Luckily I think I have a guide for that….

        • Peter

          Yeah the driver needs to be compiled in the kernel version you are running. I even had to rerun the driver when upgrading to a 3.3.x version sometimes.

          Here’s a crazy idea, compile the kernel without the Nouveau drivers, and who knows you might have the more TTYs. You need to compile the kernel without the Nouveau drivers anyway for the proprietary driver to work, Just make sure you download the latest version (295.33 or higher) as previous versions were not compatible with the 3.3 kernel.

          • matt

            I’m gonna do it. Thanks for the push!

            One more question (and thanks again for your feedback thus far) – debian/rules binary-indep, etc. are just doing gcc, right? I ask because I’d like to use distcc and ccache. On the mainline build, I issued the following command:

            MAKEFLAGS=”HOSTCC=/usr/bin/gcc CCACHE_PREFIX=distcc” fakeroot make-kpkg –initrd –append-to-version=-ofc –overlay-dir=/home/matt/kernel/330ofc/ubuntu-package kernel-image kernel-headers kernel-source

            (and after deb installation a lib/modules initrd update)

            ….so, do you think I could instead issue

            MAKEFLAGS=”HOSTCC=/usr/bin/gcc CCACHE_PREFIX=distcc” fakeroot debian/rules binary-indep?

          • matt

            Those makeflags are confirmed working.

          • matt

            IT WORKED! You were right about disabling the modules and getting to a tty (in recovery mode) to run the *.run. I’m golden – supposedly with opengl too. THANKS PETER!

      • matt

        it also complained about riva drivers. those are in devices->graphics support->framebuffer devices

    • matt

      Peter, devscripts was a necessary dependency for my oneiric box to create a new changelog.

      • matt 12: Syntax error: end of file unexpected (expecting “fi”

        • Peter

          Hmmm, I don’t have that file on my computer. When do you get that error message?

          • I’m taking a stab at this. He created a file called which is your script for modifying the check files. Your code above doesn’t reach the “fi” that you have in the code, which bash needs?

        • matt,

          One thing that I found out is in the line cat – <“$i” there needs to be a space between the and the “$i”

          So, it should look like cat – < “$i” instead. I found this by copying the code into a text editor, and changing the formatting to “sh”. It didn’t look like what Peter had, so I tried putting a space there. Now the formatting looks correct (not saying it will work, but at least it looks right).

          have a great day:)

          • I’ll try this again with code tags, so you can see what I’m talking about… Darn HTML anyhow. 😛

            Original (what is above)

            for i in debian/scripts/*-check debian.master/scripts/*-check
                if [ -f "$i" ]; then
                    cat - < "$i"
            exit 0
                    chmod 755 "$i"

            What it needs to look like:

            for i in debian/scripts/*-check debian.master/scripts/*-check
                if [ -f "$i" ]; then
                    cat - <  "$i"
            exit 0
                    chmod 755 "$i"

            note the space between


            and “$i”

            have a great day:)

          • Peter

            I added a download option for the script, that way it should always work.

          • matt

            You guys are awesome.

      • Peter

        I added the dependency in the preparation. Thanks for letting me know.

  • Awesome, I’ve been waiting for this. I have a few questions for you.

    1. My CPU is an AMD Athalon XP 64 2800 +. So, should I use the amd64 version, generic (to *hopefully* make it processor neutral), or would I want to create my own anyhow (where you have i7)?

    2. Currently my interest is to create/fix drivers for the v4l-dvb project. So, at what point would I have to add in their branch, and would I have to do anything differently? I’m not planning on installing the development kernel–just compile it (well at some point, I may want to install it).

    Thanks, and have a great day:)

    • Peter

      Yes you should use the amd64 version, and personally, if you are going to make changes to the kernel, I would create my own flavor, the name i7 is just a name, you can make it patricksversion if you like. Just keep it all lowercase and if I remember from the top of my head no special characters either.

      If you are going to add your patches I would add them right before the Compilation process. In short it would be like this:

      Do patchwork
      git add .
      git commit -a -m "My v4l-dvb patches"

      Do the compilation process, if the compilation fails, or you want to do more patches

      git reset --HARD
      git clean -df
      git checkout i7
      Do patchwork
      git add .
      git commit -a -m "More v41-dvd patches"
      git branch -D work

      This would stack the commits on top of each other, but I’m guessing you know a bit about git to do this work. If you don’t know git all that well, I would really encourage you to read up on it because it will help you in your development speed.

      • matt

        great tip – this is much more elegant than just editing the source after cleanng.

      • Thank you. As for changes to the kernel, all I’ll be doing is adding the modules from the v4l-dvb project (, and maybe updating some of the files for my PCTV-80e tuner.

        One more question (especially applicable to me in using the 3.4 version). If/when Linus releases updates to the kernel, would we esentially do this:

        git pull from linus
        git reset –HARD
        git clean df
        git checkout i7

        Or would the steps be different, as we already have the source (non updated, of course and the .deb files. I’m assuming that Ubuntu will never be as up to date as Linus’ repository, so we would want to get security/fixes from him.

        Have a great day:)

        P.S. I’ll have to read a lot more on git. Right now, i’m just trying to get things to make.

        • Peter

          If Linus pushes a new version these would be steps, lets assume he released version 3.4-rc1

          git checkout master
          git pull
          git checkout i7
          git rebase v3.4-rc1
          git branch -D work

          Start at the Compilation section of the article again.

          Line 4 will merge the new version into your i7 branch and reapplies the commits you did previously. Now this could fail of course as upstream files change and the patch doesn’t work anymore. That’s when you need to be ready with a bit more git knowledge. I suggest reading up on rebase before you do this.

          Whenever you make source changes, whether it’s a patch or a configuration change, do that in the i7 branch, commit your change, remove the work branch (line 5) and you are ready to continue with the Compilation.

          • Thanks for the quick reply. And as for what branch I’m on, it’s the 3.3-rc7 branch, as 3.4 won’t be “officially” started until he releases 3.3 (which should be soon, I think).

            Thanks for the help with this. And I do know a little about rebasing, since I’ve had to do it a few times to get my patches staged.

            Have a great day:)

          • matt

            Thanks Peter, good to know. Rebasing and exiting the work branch are what i could never figure out. The git documentation is, ahem, not the greatest….

            Patrick, dude, 3.3 is released! “Check it out” and create a branch per the guide. Compile your wiimote module and kill your low memory Android-style!

          • matt

            changing the changelog is also necessary to change the version number

  • One more question. What exactly are we supposed to do with the script

    for i in debian/scripts/*-check debian.master/scripts/*-check
    if [ -f “$i” ]; then
    cat – <“$i”
    exit 0
    chmod 755 “$i”

    Are we supposed to manually add that to the check files, or are we supposed to run it in the console? I tried running it directly in the console, and it wouldn’t do anything (except prompt me with a >).

    Have a great day:)

    • Peter

      You run it, it will put the 2 lines below the cat in the files. The files that are being edited are the *-check files in debian/scripts and debian.master/scripts. You can check if it worked by looking at the file debian/scripts/config-check if should only have those two lines.

      If it ended with a > there must have been a typo somewhere. You can do it manually of course, juts edit the above files to only have those two lines.

      • So, in abi-check, config-check, and module-check (debian/scripts), each file should only have

        chmod 755

        Right now, my config-check has 1214 lines of code in it. I’ll try the code snippet again, and manually type it in. Since I may have “lost” something in the copy/paste (as evidenced above).

        Have a great day:)

    • An update…. I tried the same thing that matt did (I believe). I put the code from my comment above into a script, inside of the branch, and ran it (the script is called

      The error that I got is this:

      ./ line 11: warning: here-document at line 4 delimited by end-of-file (wanted `eom’)
      ./ line 12: syntax error: unexpected end of file

      I’ll have to check back when I wake up to find out what to do from this point on, since nothing seems to work with the snippet of code. Unless we’re supposed to add it to the check files. Also at least on my directory list, I don’t have a debian.master/scripts directory.

      Have a great day:)

      • One last comment on this before I go to bed. Here is what I get when I do ls on debian and debian.master (after doing the git checkout precise/master –debian and git checkout precise/master –debian.master commands)

        patrickdickey@dcky-ubuntu64:~/Programming/v4l-dvb/source$ls debian
        commit-templates  control-scripts  docs   rules.d  source  tests
        compat            debian.env       rules  scripts  stamps  tools
        patrickdickey@dcky-ubuntu64:~/Programming/v4l-dvb/source$ls debian.master
        abi        changelog.historical  control.d        copyright       d-i  NOTES
        changelog  config        deviations.txt  etc  rules.d

        So, as I mentioned earlier, I don’t have a debian.master/scripts directory (and never have, to my knowledge).

        Have a great day:)

      • Peter

        Yeah sometimes there is a debian.master, sometimes there isn’t so just in case it’s added.

        Can you download the script and run that one please.

        • I’m trying the downloaded version of the script now. Actually, I’m recreating the entire process (using a script that I created out of your code). When it’s done running the script, I’ll check config-check, and report back about whether it works or not.

          Update: After running the script, I checked config-check, and it worked. I haven’t checked the other files, but I’d imagine it worked there too.

          I’m creating a “” script to do all of this. Would there be any issues with adding a wget command to download your script right before the modify files portion? Also, would there be any issues using sudo apt-get -y in the needed dependencies, instead of sudo su – and all of the apt-get commands (I ask because I don’t know how to pass the commands into the new login, and they all expect a y/n answer).

          Have a great day:)

        • The script worked. However, it still failed. At least on my system, the build calls debian.master/config/enforce, which looks to be the same as the config-check file. I failed on the security checks.

          So, I wonder if the script should change that to exit(0) also.

          Other than that, it appears to have worked overall. I may change that file, and redo the compilation steps.

          Have a great day:)

          • Peter

            The debian.master/config/enforce file is not a shell script.
            If your script ran into the security check, the script to clean up the *-check files didn’t do it’s job
            The contents of the debian/scripts/config-check file after running the script should be:

            exit 0
  • Well everything seems to have worked (I copied the config-check file to the enforce file just to make sure it worked). When it came to changing the .config file, I didn’t know what changes to make, so I didn’t do anything to it.

    Now, the problem that I’m running into is this. When I do the dpkg -i command, it hangs. I cancelled it, and ran sudo dpkg –configure -a to restart it. That was six hours ago, and here’s what my console shows me

    Setting up linux-image-3.3.0-999-testing (3.3.0-999.201203271943) ...
    Running depmod.
    update-initramfs: deferring update (hook will be called later)
    Examining /etc/kernel/postinst.d.
    run-parts: executing /etc/kernel/postinst.d/dkms 3.3.0-999-testing /boot/vmlinuz-3.3.0-999-testing
    run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.3.0-999-testing /boot/vmlinuz-3.3.0-999-testing
    update-initramfs: Generating /boot/initrd.img-3.3.0-999-testing
    run-parts: executing /etc/kernel/postinst.d/pm-utils 3.3.0-999-testing /boot/vmlinuz-3.3.0-999-testing
    run-parts: executing /etc/kernel/postinst.d/update-notifier 3.3.0-999-testing /boot/vmlinuz-3.3.0-999-testing
    run-parts: executing /etc/kernel/postinst.d/zz-update-grub 3.3.0-999-testing /boot/vmlinuz-3.3.0-999-testing

    When I cancelled it the last time (CTRL+C), I got an error on line 2010 in the postinst.d script.

    So, I’m not sure what I did wrong, or whether I can fix it.

    Have a great day:)

    • Sorry, that should have been line 1010 in /var/lib/dpkg/info/linux-image-3.3.0-999-testing.postinst. It’s failing on the update-grub portion of the installation. I tried sudo update-grub, and that hung also. In fact, I had to close the terminal window in order to kill that one.

      Luckily, when I look at my /boot/grub/grub.cfg file, it’s intact. So at least I have a bootable system, even though I probably can’t update it now. At least until I roll-back the updates that I made here, or finish them somehow.

      So, any advice is appreciated. I really have no idea where I went wrong (aside from not editing my .config file and replacing the enforce file).

      Have a great day:)

      • matt

        Patrick, try this to finish the installation:

        (*)get the name of the module directory with: ls /lib/modules
        sudo update-initramfs -ck [module directory]
        sudo update-grub

        If it’s still glitching, try

        sudo apt-get -f install
        sudo dpkg –configure -a
        GOTO (*)

  • matt

    Patrick, it looks like the boot image was created and then the grub update hung. try another sudo update-grub

    Boot restore, startupmanager, and/or grub-customer may be useful.

    • matt

      That is, grub-customizer

  • matt

    Peter, for a possible addition to the dependency step, during my build of 3.4-rc1 on 12.04, the perarch compile failed without some apparently-needed dependencies:

    bison flex

    I apt-got, cleaned, and recompiled and it passed those steps (pmu-parser and event-parser), and completed the build.

  • freddy

    Great tip, Thank you !
    However I have done something i get this error when compiling

    fakeroot debian/rules binary-indep
    install -m644 /home/lohengrin/Downloads/Kernel_3.2.15/source/tools/hv/*.8 /home/lohengrin/Downloads/Kernel_3.2.15/source/debian/linux-tools-common/usr/share/man/man8; \
    install: cannot stat `/home/lohengrin/Downloads/Kernel_3.2.15/source/tools/hv/*.8′: No such file or directory
    make: *** [install-tools] Error 1

    Could you please help me ?
    thx in advance

  • sallmann

    @freddy: Have a look at this thread:

    It’s a common problem.

    • alexr1090

      Thnaks sallmann I had same issue

  • Compilation of binary-perarch fails:

    $ fakeroot debian/rules binary-perarch
    Preparing perarch …
    make[1]: warning: -jN forced in submake: disabling jobserver mode.
    Makefile:649: “WARNING: Appending $KCPPFLAGS (-O2 -march=native -mtune=native -w) from environment to kernel $CPPFLAGS”
    Makefile:657: “WARNING: Appending $KCFLAGS (-O2 -march=native -mtune=native -w) from environment to kernel $CFLAGS”
    PERF_VERSION = 3.4.0-rc7
    make[1]: warning: -jN forced in submake: disabling jobserver mode.
    Makefile:649: “WARNING: Appending $KCPPFLAGS (-O2 -march=native -mtune=native -w) from environment to kernel $CPPFLAGS”
    Makefile:657: “WARNING: Appending $KCFLAGS (-O2 -march=native -mtune=native -w) from environment to kernel $CFLAGS”
    * new build flags or prefix
    make[1]: warning: jobserver unavailable: using -j1. Add `+’ to parent make rule.
    make[1]: warning: jobserver unavailable: using -j1. Add `+’ to parent make rule.
    make[1]: warning: jobserver unavailable: using -j1. Add `+’ to parent make rule.
    make[1]: *** No targets specified and no makefile found. Stop.
    make: *** [/home/simon/sources/kernel/mainline/source/debian/stamps/stamp-build-perarch] Error 2

    In addition, why we compile this package if we are not going to install it? Do I really need this step?

    • AlexL

      I have the same problem building the tools package…

  • David E

    Hi I am trying to build a v3.5.3 kernel on Ubuntu 10.04 box. I am able to build everything correctly down until the last line that builds the actual kernel images then I get the error:

    root@localhost:~/git/linux-stable# fakeroot debian/rules binary-dnrc
    make: *** No rule to make target `binary-dnrc’. Stop.

    I tried binary-virtual just to check if I could build another flavour and that one started building fine.

    Any help is much appreciated. Thanks!

    • David E

      Found the problem, I was using amd64 for the architecture when I had forgotten I was on an i386 VM.. changed everything to i386 and its building fine now.

  • masuch

    Thanks for this post.

    I have compiled kernel Ubuntu-3.8.0-4.9 (raring) from git and I still cannot change the naming of the packages. I have got always following:

    (I have ‘i7-avx’ flavour (and native optimization for mtune , march))

    I would like to have names like:

    To get it I modified top-level Makefile like:
    SUBLEVEL = 999
    EXTRAVERSION = martin_1302071551

    But it does not have influence on names of generated packages. Not even on module directory

    Can you please help me what How to achieve it ?

    Thank You,
    kind regards,