LinuxQuestions.org - Learn How To Compile The Linux Kernel

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - Learn How To Compile The Linux Kernel (https://www.linuxquestions.org/questions/linux-newbie-8/learn-how-to-compile-the-linux-kernel-788899/)

Learn How To Compile The Linux Kernel

The Internet is filled with outdated / incorrect / complicated / wrong ways to compile the Linux kernel. It's not difficult to do. I simply cannot account for all the incorrect posts.

Get the kernel source: curl -O http://www.kernel.org/pub/linux/kernel/2.6/linux-<version>.tar.bz2

Will put the kernel source file into the working directory. If you're wondering how one would know what to put for <version>, you go into the kernel archive using a web browser, and you look for the exact <version> you want. If you don't know what version you want, stick with the latest stable version, as listed on this page:

http://kernel.org/

There is a link on that page to the

/pub/linux

directory. When you get to

/pub/linux

click on

kernel

and then

2.6

The kernel source files are

.tar.bz2

OR

.tar.gz.

The other files in the directory are used for verifying the authenticity of the kernel.

** OPTIONAL **

If you wish to verify the kernel source file, download the proper

.sign

file, and get the kernel.org public encryption key here:

http://kernel.org/signature.html

Then install the

gpg

package, and verify the kernel is properly signed.

** END OPTIONAL **

Install the development or lsb package for your distro. Move the kernel source file to:

/usr/src

su
password
mv linux-<version>.tar.bz2 /usr/src

Uncompress the

bz2

archive:

tar jxvf linux-<version>.tar.bz2

The screen will scroll. Remove the:

linux

soft link:

rm linux

Make a new soft link to the new kernel source directory:

ln -s linux-<version> linux

Change directory to linux:

cd linux

Get a config file to start with:

cp /boot/config-`uname -r` .config

Apply and patches:

patch -p 1 < <patch>.diff

Configure the kernel:

make oldconfig

The new kernel will work if you agree with everything the configure program suggests. If you disagree, and change something, it will usually be ok.

make menuconfig

OR

make xconfig

Now, make the changes to the kernel configuration that you desire, and save the

.config

file. Don't worry about ruining the kernel config. If the new kernel doesn't boot, you can boot using the old kernel and repeat the above steps to copy the config file from

/boot/

And configure the kernel again.

Give the kernel a unique name:

nano Makefile

Put something meaningful after

EXTRAVERSION =

AND

NAME =

such as the date, preceded by a hyphen. Name the kernel after an attractive female, using lowercase only. If you need to use numbers in the name of an attractive female ... Ok, Save:

Makefile

Compile the kernel:

make clean
make all
make modules_install
make install

After you do the

make install

step, there is a command line left on the screen, beginning with

sh

You need to:

chmod +x /usr/src/linux-<version>/arch/x86/boot/install.sh

and then type the entire command left by:

make install

and execute it.

Now you should have:

/boot/initrd-<version>
/boot/System.map-<version>
/boot/vmlinuz-<version>

Check

/boot/grub/menu.lst

for a new entry.

nano /boot/grub/menu.lst

Put a

# and a space

in front of

hiddenmenu

and

splashimage

Check for your new entry, which should read

title <something> <version>
root(hdx,y)
kernel /vmlinuz-<version> root=<something>
initrd /initrd-<version>

make

default=0
timeout=5

If the entry for your new kernel is in

/boot/grub/menu.lst

the machine should boot with the new kernel.

The main rule for compiling a new kernel, or a kernel rebuild, is remove unnecessary options, such as unnecessary drivers, from the kernel config. You must know your hardware. But you can reduce the size of the kernel considerably, which is good. Usually a kernel rebuild is due to a patch being applied, requiring recompilation.

Quote:

cp /boot/config* .config

May I suggest you change this to the following:

Code:

cp /boot/config-`uname -r` .config

I'd also like to point out that the method for Debian is quite different from your generic method.

Quote:

The screen will scroll. Make a soft link to the new kernel source directory:

ln -s linux-<version> linux

Maybe insert

PHP Code:




rm linux

prior to creating the symlink. If I fail to remove the old link, creating the new link fails every time.

Quote:

The screen will scroll. Make a soft link to the new kernel source directory:

ln -s linux-<version> linux

Actually, what does that step accomplish? There is a link in /lib/modules to the kernel source for any drivers needing access.

Added:

Oh, and there's no real need for the kernel source to be in /usr/src.

There are differences of opinion as to where to build the kernel: /usr/src or /home/username. I've seen several howtos recommend /usr/src, but on the other hand there's this:

Quote:

This warning is the most important thing to remember while working through the
steps in this book. Everything in this book—downloading the kernel source code,
uncompressing it, configuring the kernel, and building it—should be done as a
normal user on the machine. Only the two or three commands it takes to install a
new kernel should be done as the superuser (root).
There have been bugs in the kernel build process in the past, causing some special
files in the /dev directory to be deleted if the user had superuser permissions while
building the Linux kernel.* There are also issues that can easily arise when uncom-
pressing the Linux kernel with superuser rights, as some of the files in the kernel
source package will not end up with the proper permissions and will cause build
errors later.
The kernel source code should also never be placed in the /usr/src/linux/ direc-
tory, as that is the location of the kernel that the system libraries were built
against, not your new custom kernel. Do not do any kernel development under
the /usr/src/ directory tree at all, but only in a local user directory where nothing
bad can happen to the system.

From "Linux Kernel In A Nutshell" by Greg Kroah-Hartman.

Quote:

Originally Posted by Quakeboy02 (Post 3862569)

It makes life easier and reduces the chance of typos by simplifying linux-2.6.33-rc5 to linux for instance.

Quote:

Originally Posted by damgar (Post 3862575)

It makes life easier and reduces the chance of typos by simplifying linux-2.6.33-rc5 to linux for instance.

I don't understand. Perhaps it's because I've been using the Debian method. I go into the source directory, run make-kpkg, go back one directory and install the .deb. But, if it makes it easier for you, then go for it.

You are correct. After building I manually install all the components for my kernel into /boot which amounts to manually cp'ing files from /usr/src/linux<version> to /boot.

Quote:

Originally Posted by brianL (Post 3862574)

There are differences of opinion as to where to build the kernel: /usr/src or /home/username. I've seen several howtos recommend /usr/src, but on the other hand there's this:

From "Linux Kernel In A Nutshell" by Greg Kroah-Hartman.

Thanks Brian!

Quote:

Originally Posted by Quakeboy02 (Post 3862559)

May I suggest you change this to the following:

Code:

cp /boot/config-`uname -r` .config

I'd also like to point out that the method for Debian is quite different from your generic method.

It's done. Good suggestion.

Quote:

Originally Posted by damgar (Post 3862562)

Maybe insert

PHP Code:




rm linux

prior to creating the symlink. If I fail to remove the old link, creating the new link fails every time.

It's Done

Just following conventions.

Quote:

Originally Posted by Quakeboy02 (Post 3862569)

Many programs search /usr/src/linux for kernel source. Many books also use this convention. Until the standard changes, I'm going to go along with it.

Kernel evangelism ...

Quote:

Originally Posted by brianL (Post 3862574)

If one is working from /usr/src/, he can't do anything, not even uncompress the sources archive, without elevation of privilege. We can do everything from ~/, and make a linux soft link in /usr/src, just so everything is standard, but many people have have separate partitions for /home and /, meaning the soft link would cross partitions.

That's ok, but it can cause problems under certain circumstances. And, most people now know about the soft link /lib/modules/$(uname -r)/build/, so we really don't require /usr/src/linux anymore.

But many instructions on how to build a kernel would seem cryptic and contradictory to this one if I didn't use /usr/src/linux.

What I'm describing in the OP ...

Quote:

Originally Posted by Quakeboy02 (Post 3862596)

Debian, and all distros have tools for building kernels, but the method I have outlined will work with any distro. Sometimes distro specific tools fail if a kernel has been patched, and then the only way to patch the kernel is to use the method described in the OP.

This method is the method the kernel maintainers build into the kernel sources. It's the industrial reference standard kernel compilation method. Although, when I'm working on Debian, I use Debian sources, make-kpkg, update-initramfs, and update-grub.

Quote:

Originally Posted by AwesomeMachine (Post 3862710)

Many programs search /usr/src/linux for kernel source. Many books also use this convention. Until the standard changes, I'm going to go along with it.

I believe it is preferable to use /lib/modules/`uname -r`/build, as it more reliably identifies the running kernel instead of just *some* kernel that was built once upon a time. This is from an NVIDIA run file:

Code:

    echo "  --kernel-source-path=KERNEL-SOURCE-PATH"

    echo "      The directory containing the kernel source files that"

    echo "      should be used when compiling the NVIDIA kernel module. "

    echo "      When not specified, the installer will use"

    echo "      '/lib/modules/\`uname -r\`/build', if that directory exists. "

    echo "      Otherwise, it will use '/usr/src/linux'."

AW, I'm not criticizing you, by the way. You did a good job of pulling this together. I will grant that there are all sorts of ways to do it, but there are best practices.

Quote:

Originally Posted by AwesomeMachine (Post 3862717)

Although, when I'm working on Debian, I use Debian sources, make-kpkg, update-initramfs, and update-grub.

Aren't the update-initramfs and update-grub done for you by dpkg -i?

Eric Hameleers (alien BOB) recommends building it in /usr/src. When a top Slacker and a top kernel developer disagree, what's a poor newbie like me to do? :)

http://alien.slackbook.org/dokuwiki/...kernelbuilding

For what it's worth I follow Bob on this. It's generally a safe method, and doesn't involve removing anything, whereas some guides I have read have people removing the old kernel, before trying to boot the new one.

Also, Bob's remarks regarding using /usr/src/ are qualified by the line

Quote:

I believe this advice is irrelevant for Slackware and the way it has it's kernel headers and glibc package setup.

I can't speak for another distro, but Bob's remarks imply that there may be a distro out there, for which, building in /usr/src/ may not be as safe?

From the above link:

Quote:

There is a debate whether you should build your kernels in the /usr/src tree or somewhere entirely else.
The cause is an old post by Linus Torvalds (from July 2000) where he advises people to build from within their home directory. I believe this advice is irrelevant for Slackware and the way it has it's kernel headers and glibc package setup. So, my advice is to ignore this old post by Linus and install your kernel sources into /usr/src if you want. The kernel building location is purely a matter of personal preference.

Quote:

Originally Posted by damgar (Post 3862739)

For what it's worth I follow Bob on this.

Yeah, definitely. If it wasn't safe, he wouldn't recommend it.