Saltar al contenido

Tecnología

Tecnología en General

How To Compile A Kernel – The Fedora Way

FUENTE: http://www.howtoforge.com/kernel_compilation_fedora

Each distribution has some specific tools to build a custom kernel from the sources. This article is about compiling a kernel on Fedora systems. It describes how to build a custom kernel using the latest unmodified kernel sources fromwww.kernel.org (vanilla kernel) so that you are independent from the kernels supplied by your distribution. It also shows how to patch the kernel sources if you need features that are not in there.

I have tested this on Fedora Core 6.

I want to say first that this is not the only way of setting up such a system. There are many ways of achieving this goal but this is the way I take. I do not issue any guarantee that this will work for you!

 

1 Preliminary Note

In this article I will describe two ways of building a kernel for Fedora systems. The first one is Fedora-specific, and in the end you will have a kernel rpm package that you can install or share with others. The second way is the same for all Linux distributions, but you don’t end up with an rpm package.

I prefer to do all the steps here as the root user. However, it’s possible to run most commands as a non-privileged user (e.g. user tom). Some commands such as yum orrpm still require root privileges, so you should add tom (or whatever your username is) to /etc/sudoers by running

visudo

Add this line:

tom  ALL=(ALL) ALL

Now whenever you run a command that requires root privileges, such as

yum install fedora-rpmdevtools unifdef

the command will tell you so, and you must run

sudo yum install fedora-rpmdevtools unifdef

instead. Remember: you can forget about sudo if you run all commands as root. It’s up to you which way you prefer.

 

2 Building A Kernel rpm Package

This chapter shows how to build a kernel and end up with an rpm package that you can install and share with others.

 

2.1 Create Your rpmbuild Directory

Create your rpmbuild directory as follows:

cd ~
cp -a /usr/src/redhat/ rpmbuild
echo ‘%_topdir %(echo $HOME)/rpmbuild’ >> .rpmmacros

Then install the required packages for building rpm packages

yum install fedora-rpmdevtools unifdef

and run

fedora-buildrpmtree

 

2.2 Download And Install A Fedora Kernel src.rpm

Next we download the latest kernel src.rpm for our Fedora version. For Fedora Core 6, the src.rpm packages are located inhttp://download.fedora.redhat.com/pub/fedora/linux/core/6/source/SRPMS/, for Fedora Core 5 it’shttp://download.fedora.redhat.com/pub/fedora/linux/core/5/source/SRPMS/, and so on.

The latest Fedora Core 6 kernel src.rpm is kernel-2.6.18-1.2798.fc6.src.rpm, so we download and install it now:

cd /usr/src
wget http://download.fedora.redhat.com/pub/fedora/linux/core/6/source/SRPMS/kernel-2.6.18-1.2798.fc6.src.rpm
rpm -ivh kernel-2.6.18-1.2798.fc6.src.rpm

If you see these warnings:

warning: user brewbuilder does not exist – using root
warning: group brewbuilder does not exist – using root

you can ignore them.

We have just installed the kernel sources for the 2.6.18 kernel together with lots of Fedora patches and a patch for kernel 2.6.18.1, so if we continued to build a kernel from this src.rpm we’d end up with kernel 2.6.18.1.

 

2.3 Patch The Kernel

Instead of kernel 2.6.18.1 I want to install kernel 2.6.18.2. The src.rpm we installed came with kernel 2.6.18 plus a patch for kernel 2.6.18.1. We will now replace that patch with the patch for kernel 2.6.18.2.

cd ~/rpmbuild/SOURCES/
wget http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.18.2.bz2

You could also use the http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.19-rc5.bz2 prepatch if you want to end up with kernel 2.6.19-rc5. Please note that this works only for prepatches, i.e. patches for kernels that aren’t available in a final version yet, such as the 2.6.19 kernel. You can apply that patch to the 2.6.18 kernel sources, but not to kernel 2.6.18.1 or 2.6.18.2, etc. This is explained on http://kernel.org/patchtypes/pre.html:

Prepatches are the equivalent to alpha releases for Linux; they live in the testing directories in the archives. They should be applied using the patch(1) utility to the source code of the previous full release with a 3-part version number (for example, the 2.6.12-rc4 prepatch should be applied to the 2.6.11 kernel sources, not, for example, 2.6.11.10.)

Now we must modify the kernel-2.6.spec file so that it knows about our new kernel patch:

cd ~/rpmbuild/SPECS/

vi kernel-2.6.spec

Search for the line

Patch1: patch-2.6.18.1.bz2

and replace it with this one:

Patch1: patch-2.6.18.2.bz2

(or whatever patch you downloaded before).

Then run

rpmbuild -bp kernel-2.6.spec

(If you want to build the kernel for a specific architecture such as i386, i586, i686, or x86_64, you can do it like this:

rpmbuild -bp –target=i686 kernel-2.6.spec

I don’t specify it in this example and end up with a i386 kernel here. Your system might build a kernel for a different architecture instead if you don’t specify it, so keep this in mind when you follow this tutorial.)

Now comes the tricky part. The src.rpm comes with a lot of Fedora-specific patches. Some of them don’t work with our 2.6.18.2 patch, so if you see something like this in the rpmbuild output:

+ echo ‘Patch #300 (linux-2.6-ppc-dac960-ipr-clash.patch):’
Patch #300 (linux-2.6-ppc-dac960-ipr-clash.patch):
+ patch -p1 -s
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
1 out of 1 hunk ignored — saving rejects to file drivers/block/DAC960.c.rej
error: Bad exit status from /var/tmp/rpm-tmp.46287 (%prep)

RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.46287 (%prep)

you must edit kernel-2.6.spec again and comment out the patch #300:

vi kernel-2.6.spec

[...]
#Patch300: linux-2.6-ppc-dac960-ipr-clash.patch
[...]
#%patch300 -p1
[...]

Then run your rpmbuild command again, e.g.

rpmbuild -bp kernel-2.6.spec

You must repeat this over and over until there are no more patches that fail to be applied.

 

2.4 Specify A Kernel Identification String

Now we should specify a string that allows us to identify our kernel later on. Therefore we do this:

cd ~/rpmbuild/BUILD/kernel-2.6.18/linux-2.6.18.i386
vi Makefile

In the EXTRAVERSION line, you can put the kernel identification. I think it’s good to append the kernel version to that string, so something like this is ok:

EXTRAVERSION = -custom-2.6.18.2

 

2.5 Configure The Kernel

Now we run

make menuconfig

which brings up the kernel configuration menu. Go to Load an Alternate Configuration File and choose .config as the configuration file:

Then browse through the kernel configuration menu and make your choices. When you are finished and select Exit, answer the following question (Do you wish to save your new kernel configuration?) with Yes:

 

2.6 Build The Kernel

Now we build our kernel rpm package by simply running

make rpm

Afterwards you will find a new src.rpm package in the ~/rpmbuild/SRPMS/ directory, e.g. ~/rpmbuild/SRPMS/kernel-2.6.18custom2.6.18.2-1.src.rpm, and the kernel rpm package in ~/rpmbuild/RPMS/i386/ (or ~/rpmbuild/RPMS/i586/, ~/rpmbuild/RPMS/i686/, etc. depending on your architecture), e.g. ~/rpmbuild/RPMS/i386/kernel-2.6.18custom2.6.18.2-1.i386.rpm. As you see your kernel identification has been added to the package name.

 

2.7 Install The New Kernel

Now go the directory where your new kernel rpm package has been created (depending on your architecture, e.g. ~/rpmbuild/RPMS/i386/), and install the rpm package:

cd ~/rpmbuild/RPMS/i386
rpm -ivh kernel-2.6.18custom2.6.18.2-1.i386.rpm

(You can now even transfer the rpm package to other Fedora systems and install them there exactly the same way, which means you don’t have to compile the kernel there again.)

Next we create a ramdisk for our new kernel, because otherwise the system will most likely not boot our new kernel:

mkinitrd /boot/initrd-2.6.18-custom-2.6.18.2.img 2.6.18-custom-2.6.18.2

Then edit /boot/grub/menu.lst. Have a look at your existing (working) kernel stanzas there and take one of them as a sample for your new stanza and replace the kernel and ramdisk, then add the stanza above all other stanzas.

vi /boot/grub/menu.lst

For example, my menu.lst looks like this before I add the new stanza:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
#          initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu

title Fedora Core (2.6.18-1.2798.fc6)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=/dev/VolGroup00/LogVol00
        initrd /initrd-2.6.18-1.2798.fc6.img

and like this afterwards:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
#          initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu

title Fedora Core (2.6.18-custom-2.6.18.2)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-custom-2.6.18.2 ro root=/dev/VolGroup00/LogVol00
        initrd /initrd-2.6.18-custom-2.6.18.2.img

title Fedora Core (2.6.18-1.2798.fc6)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=/dev/VolGroup00/LogVol00
        initrd /initrd-2.6.18-1.2798.fc6.img

(You can find out about the right vmlinuz and initrd files by running

ls -l /boot

)

Now reboot the system:

shutdown -r now

If everything goes well, it should come up with the new kernel. You can check if it’s really using your new kernel by running

uname -r

This should display something like

2.6.18-custom-2.6.18.2

If the system doesn’t start, restart it, and when you see this:

press any key to enter the GRUB menu:

Select your old kernel and start the system. You can now try again to compile a working kernel. Don’t forget to remove the stanza of the not-working kernel from/boot/grub/menu.lst.

3 Building A Kernel The Traditional Way

This chapter describes a different approach that can be used on any Linux system. As there’s nothing Fedora-specific in this, of course you will not end up with a kernel rpm package.

 

3.1 Download The Kernel Sources

We download our desired kernel to /usr/src. Go to www.kernel.org and select the kernel you want to install, e.g. linux-2.6.18.2.tar.bz2 (you can find all 2.6 kernels here: http://www.kernel.org/pub/linux/kernel/v2.6/). Then you can download it to /usr/src like this:

cd /usr/src
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.18.2.tar.bz2

Then we unpack the kernel sources and create a symlink linux to the kernel sources directory:

tar xjf linux-2.6.18.2.tar.bz2
ln -s linux-2.6.18.2 linux
cd /usr/src/linux

 

3.2 Apply Patches To The Kernel Sources (Optional)

Sometimes you need drivers for hardware that isn’t supported by the new kernel by default, or you need support for virtualization techniques or some other bleeding-edge technology that hasn’t made it to the kernel yet. In all these cases you have to patch the kernel sources (provided there is a patch available…).

Now let’s assume you have downloaded the needed patch (I call it patch.bz2 in this example) to /usr/src. This is how you apply it to your kernel sources (you must still be in the /usr/src/linux directory):

bzip2 -dc /usr/src/patch.bz2 | patch -p1 –dry-run
bzip2 -dc /usr/src/patch.bz2 | patch -p1

The first command is just a test, it does nothing to your sources. If it doesn’t show errors, you can run the second command which actually applies the patch. Don’t do it if the first command shows errors!

You can also apply kernel prepatches to your kernel sources. For example, if you need a feature that is available only in kernel 2.6.19-rc5, but the full sources haven’t been released yet for this kernel. Instead, a patch-2.6.19-rc5.bz2 is available. You can apply that patch to the 2.6.18 kernel sources, but not to kernel 2.6.18.1 or2.6.18.2, etc. This is explained on http://kernel.org/patchtypes/pre.html:

Prepatches are the equivalent to alpha releases for Linux; they live in the testing directories in the archives. They should be applied using the patch(1) utility to the source code of the previous full release with a 3-part version number (for example, the 2.6.12-rc4 prepatch should be applied to the 2.6.11 kernel sources, not, for example, 2.6.11.10.)

So if you want to compile a 2.6.19-rc5 kernel, you must download the 2.6.18 kernel sources (http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.18.tar.bz2) in step 3.1 instead of kernel 2.6.18.2!

This is how you apply the 2.6.19-rc5 patch to kernel 2.6.18:

cd /usr/src
wget http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.19-rc5.bz2
cd /usr/src/linux
bzip2 -dc /usr/src/patch-2.6.19-rc5.bz2 | patch -p1 –dry-run
bzip2 -dc /usr/src/patch-2.6.19-rc5.bz2 | patch -p1

 

3.3 Configure The Kernel

It’s a good idea to use the configuration of your current working kernel as a basis for your new kernel. Therefore we copy the existing configuration to /usr/src/linux:

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

Then we run

make menuconfig

which brings up the kernel configuration menu. Go to Load an Alternate Configuration File and choose .config (which contains the configuration of your current working kernel) as the configuration file:

Then browse through the kernel configuration menu and make your choices. When you are finished and select Exit, answer the following question (Do you wish to save your new kernel configuration?) with Yes:

 

3.4 Build And Install The Kernel

To build and install the kernel, execute these three commands:

make all
make modules_install
make install

Now be patient, the kernel compilation can take some hours, depending on your kernel configuration and your processor speed. The last command will also automatically create a ramdisk for you as well as configure /boot/grub/menu.lst.

Now edit /boot/grub/menu.lst. You should find a stanza for your new kernel at the top of the list, but to make sure that the new kernel gets booted instead of your old one, you must set the value of default to 0.

vi /boot/grub/menu.lst

My menu.lst looks like this:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
#          initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu

title Fedora Core (2.6.18.2)
        root (hd0,0)
        kernel /vmlinuz-2.6.18.2 ro root=/dev/VolGroup00/LogVol00
        initrd /initrd-2.6.18.2.img

title Fedora Core (2.6.18-1.2798.fc6)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=/dev/VolGroup00/LogVol00
        initrd /initrd-2.6.18-1.2798.fc6.img

Now reboot the system:

shutdown -r now

If everything goes well, it should come up with the new kernel. You can check if it’s really using your new kernel by running

uname -r

This should display something like

2.6.18.2

If the system doesn’t start, restart it, and when you see this:

press any key to enter the GRUB menu:

Select your old kernel and start the system. You can now try again to compile a working kernel. Don’t forget to remove the stanza of the not-working kernel from/boot/grub/menu.lst.

 

4 Links

How To Compile A Kernel – Debian Etch

  • admin 

FUENTE: http://www.howtoforge.com/kernel_compilation_debian_etch

Each distribution has some specific tools to build a custom kernel from the sources. This article is about compiling a kernel on a Debian Etch system. It describes how to build a custom kernel using the latest unmodified kernel sources fromwww.kernel.org (vanilla kernel) so that you are independent from the kernels supplied by your distribution. It also shows how to patch the kernel sources if you need features that are not in there.

I do not issue any guarantee that this will work for you!

1 Preliminary Note

I will describe two ways of compiling a new kernel. Using the first method, you will end up with a kernel .deb package that can be installed on the system, and that you can share with others and install on other Debian Etch systems.

The second method is to compile a kernel the «traditional» way. This way works on any Linux distribution, but of course you don’t end up with a kernel .deb package.

2 Building A Kernel .deb Package

This chapter shows how to build a kernel and end up with a .deb package that you can install and share with others.

2.1 Install Required Packages For Kernel Compilation

First we update our package database:

apt-get update

Then we install all needed packages like this:

apt-get install kernel-package libncurses5-dev fakeroot wget bzip2 build-essential

2.2 Download The Kernel Sources

Next we download our desired kernel to /usr/src. Go to www.kernel.org and select the kernel you want to install, e.g. linux-2.6.21.3.tar.bz2 (you can find all 2.6 kernels here: http://www.kernel.org/pub/linux/kernel/v2.6/). Then you can download it to /usr/src like this:

cd /usr/src
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.21.3.tar.bz2

Then we unpack the kernel sources and create a symlink linux to the kernel sources directory:

tar xjf linux-2.6.21.3.tar.bz2
ln -s linux-2.6.21.3 linux
cd /usr/src/linux

2.3 Apply Patches To The Kernel Sources (Optional)

Sometimes you need drivers for hardware that isn’t supported by the new kernel by default, or you need support for virtualization techniques or some other bleeding-edge technology that hasn’t made it to the kernel yet. In all these cases you have to patch the kernel sources (provided there is a patch available…).

Now let’s assume you have downloaded the needed patch (I call it patch.bz2 in this example) to /usr/src. This is how you apply it to your kernel sources (you must still be in the /usr/src/linux directory):

bzip2 -dc /usr/src/patch.bz2 | patch -p1 –dry-run
bzip2 -dc /usr/src/patch.bz2 | patch -p1

The first command is just a test, it does nothing to your sources. If it doesn’t show errors, you can run the second command which actually applies the patch. Don’t do it if the first command shows errors!

You can also apply kernel prepatches to your kernel sources. For example, if you need a feature that is available only in kernel 2.6.22-rc3, but the full sources haven’t been released yet for this kernel. Instead, a patch-2.6.22-rc3.bz2 is available. You can apply that patch to the 2.6.21 kernel sources, but not to kernel 2.6.21.1 or 2.6.21.2, etc. This is explained on http://kernel.org/patchtypes/pre.html:

Prepatches are the equivalent to alpha releases for Linux; they live in the testing directories in the archives. They should be applied using the patch(1) utility to the source code of the previous full release with a 3-part version number (for example, the 2.6.12-rc4 prepatch should be applied to the 2.6.11 kernel sources, not, for example, 2.6.11.10.)

So if you want to compile a 2.6.22-rc3 kernel, you must download the 2.6.21 kernel sources (http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.21.tar.bz2) in step 3 instead of kernel 2.6.21.3!

This is how you apply the 2.6.22-rc3 patch to kernel 2.6.21:

cd /usr/src
wget http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.22-rc3.bz2
cd /usr/src/linux
bzip2 -dc /usr/src/patch-2.6.22-rc3.bz2 | patch -p1 –dry-run
bzip2 -dc /usr/src/patch-2.6.22-rc3.bz2 | patch -p1

2.4 Configure The Kernel

It’s a good idea to use the configuration of your current working kernel as a basis for your new kernel. Therefore we copy the existing configuration to /usr/src/linux:

make clean && make mrproper
cp /boot/config-`uname -r` ./.config

Then we run

make menuconfig

which brings up the kernel configuration menu. Go to Load an Alternate Configuration File and choose .config (which contains the configuration of your current working kernel) as the configuration file:

Then browse through the kernel configuration menu and make your choices. When you are finished and select Exit, answer the following question (Do you wish to save your new kernel configuration?) with Yes:

2.5 Build The Kernel

To build the kernel, execute these two commands:

make-kpkg clean
fakeroot make-kpkg –initrd –append-to-version=-custom kernel_image kernel_headers

After –append-to-version= you can write any string that helps you identify the kernel, but it must begin with a minus (-) and must not contain whitespace.

Now be patient, the kernel compilation can take some hours, depending on your kernel configuration and your processor speed.

2.6 Install The New Kernel

After the successful kernel build, you can find two .deb packages in the /usr/src directory.

cd /usr/src
ls -l

On my test system they were called linux-image-2.6.21.3-custom_2.6.21.3-custom-10.00.Custom_i386.deb (which contains the actual kernel) and linux-headers-2.6.21.3-custom_2.6.21.3-custom-10.00.Custom_i386.deb (which contains files needed if you want to compile additional kernel modules later on). I install them like this:

dpkg -i linux-image-2.6.21.3-custom_2.6.21.3-custom-10.00.Custom_i386.deb
dpkg -i linux-headers-2.6.21.3-custom_2.6.21.3-custom-10.00.Custom_i386.deb

(You can now even transfer the two .deb files to other Debian Etch systems and install them there exactly the same way, which means you don’t have to compile the kernel there again.)

That’s it. The GRUB bootloader configuration file /boot/grub/menu.lst has been modified automatically, and a ramdisk for the new kernel has been create in /boot.

Now reboot the system:

shutdown -r now

At the boot prompt, select your new kernel (should be selected by default):

If everything goes well, it should come up with the new kernel. You can check if it’s really using your new kernel by running

uname -r

This should display something like

2.6.21.3-custom

If the system doesn’t start, restart it, and select your old kernel at the boot prompt. You can now try again to compile a working kernel. Don’t forget to remove the stanza(s) of the not-working kernel from /boot/grub/menu.lst.

3 Building A Kernel The Traditional Way

This chapter describes a different approach that can be used on any Linux system (apart from details such as creating a ramdisk or updating the bootloader). Of course you will not end up with a kernel .deb package.

3.1 Install Required Packages For Kernel Compilation

First we update our package database:

apt-get update

Then we install all needed packages like this:

apt-get install kernel-package libncurses5-dev fakeroot wget bzip2 build-essential

3.2 Download The Kernel Sources

Next we download our desired kernel to /usr/src. Go to www.kernel.org and select the kernel you want to install, e.g. linux-2.6.21.3.tar.bz2 (you can find all 2.6 kernels here: http://www.kernel.org/pub/linux/kernel/v2.6/). Then you can download it to /usr/src like this:

cd /usr/src
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.21.3.tar.bz2

Then we unpack the kernel sources and create a symlink linux to the kernel sources directory:

tar xjf linux-2.6.21.3.tar.bz2
ln -s linux-2.6.21.3 linux
cd /usr/src/linux

3.3 Apply Patches To The Kernel Sources (Optional)

Sometimes you need drivers for hardware that isn’t supported by the new kernel by default, or you need support for virtualization techniques or some other bleeding-edge technology that hasn’t made it to the kernel yet. In all these cases you have to patch the kernel sources (provided there is a patch available…).

Now let’s assume you have downloaded the needed patch (I call it patch.bz2 in this example) to /usr/src. This is how you apply it to your kernel sources (you must still be in the /usr/src/linux directory):

bzip2 -dc /usr/src/patch.bz2 | patch -p1 –dry-run
bzip2 -dc /usr/src/patch.bz2 | patch -p1

The first command is just a test, it does nothing to your sources. If it doesn’t show errors, you can run the second command which actually applies the patch. Don’t do it if the first command shows errors!

You can also apply kernel prepatches to your kernel sources. For example, if you need a feature that is available only in kernel 2.6.22-rc3, but the full sources haven’t been released yet for this kernel. Instead, a patch-2.6.22-rc3.bz2 is available. You can apply that patch to the 2.6.21 kernel sources, but not to kernel 2.6.21.1 or 2.6.21.2, etc. This is explained on http://kernel.org/patchtypes/pre.html:

Prepatches are the equivalent to alpha releases for Linux; they live in the testing directories in the archives. They should be applied using the patch(1) utility to the source code of the previous full release with a 3-part version number (for example, the 2.6.12-rc4 prepatch should be applied to the 2.6.11 kernel sources, not, for example, 2.6.11.10.)

So if you want to compile a 2.6.22-rc3 kernel, you must download the 2.6.21 kernel sources (http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.21.tar.bz2) in step 3 instead of kernel 2.6.21.3!

This is how you apply the 2.6.22-rc3 patch to kernel 2.6.21:

cd /usr/src
wget http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.22-rc3.bz2
cd /usr/src/linux
bzip2 -dc /usr/src/patch-2.6.22-rc3.bz2 | patch -p1 –dry-run
bzip2 -dc /usr/src/patch-2.6.22-rc3.bz2 | patch -p1

3.4 Configure The Kernel

It’s a good idea to use the configuration of your current working kernel as a basis for your new kernel. Therefore we copy the existing configuration to /usr/src/linux:

make clean && make mrproper
cp /boot/config-`uname -r` ./.config

Then we run

make menuconfig

which brings up the kernel configuration menu. Go to Load an Alternate Configuration File and choose .config (which contains the configuration of your current working kernel) as the configuration file:

Then browse through the kernel configuration menu and make your choices. When you are finished and select Exit, answer the following question (Do you wish to save your new kernel configuration?) with Yes:

3.5 Build And Install The Kernel

To build the kernel, execute these commands:

make all
make modules_install
make install

Now be patient, the kernel compilation can take some hours, depending on your kernel configuration and your processor speed.

3.6 Post-Installation Steps

The new kernel is now installed, but we still need a ramdisk for our new kernel (otherwise the system will most likely not boot!), and we need to tell the GRUB bootloader about our new kernel.

First, we do this:

depmod 2.6.21.3
apt-get install yaird

Then we create a ramdisk with the following command:

mkinitrd.yaird -o /boot/initrd.img-2.6.21.3 2.6.21.3

The GRUB configuration is very easy on Debian Etch. All we have to do is run

update-grub

This will detect the new kernel and ramdisk and update /boot/grub/menu.lst for us.

Now reboot the system:

shutdown -r now

At the boot prompt, select your new kernel (should be selected by default). If everything goes well, it should come up with the new kernel. You can check if it’s really using your new kernel by running

uname -r

This should display something like

2.6.21.3

If the system doesn’t start, restart it, and select your old kernel at the boot prompt. You can now try again to compile a working kernel. Don’t forget to remove the stanza(s) of the not-working kernel from /boot/grub/menu.lst.

4 Links

Linux-Based X Terminals with XDMCP

  • admin 

Fuente: http://www.linuxjournal.com/article/6713

A tutorial for configuring XDMCP on your network so you can use old equipment, cut down on administration duties and cut costs.

Want to get some use out of your early 90s vintage PC, the one barely powerful enough to run Windows 3.1? Need to outfit a group of users with workstations on a budget? Tired of administering a homogeneous workgroup from afar? Want to introduce Linux to a group of Windows or Mac users with the least amount of resistance? Can’t stop tinkering with the oodles of options Linux offers? XDMCP may be for you, even if you answered yes to even one of these questions.The X display manager control protocol (XDMCP for short) provides a means for a user sitting at one (client) computer running X to communicate with another (server) computer running an X display manager. Once a connection is established, the user can log in and run programs as if the user were sitting at the remote computer. The station where the user sits often is referred to as an X terminal, which essentially is a window into the server. All of the software resides on the server, all of the processing is done on the server’s CPU, and all of the files to be accessed reside on the server.So, for those of you trying to reduce administration hassles, this means you have to administer only the servers. The clients’ software remains the same. For those trying to get some use out of old equipment, the speed of the client computers and the size of their hard drives is nearly irrelevant. Even my old Pentium 120 with a CPU upgrade to 180 MHz, 32MB of RAM and a 1GB hard disk provides more than enough muscle to be an X terminal. And, for those trying to outfit a workgroup on a budget, as many as five or six cheap computers can be configured as X terminals for every expensive workstation configured as a server. This would require a fast local network, however. Finally, for those trying to introduce Linux to Windows and Mac users, the only necessary intrusion into their machines is the installation of an X server, and free ones exist.
Basic Configuration

XDMCP is a communication protocol with the power to deliver all the items listed above. A word of caution is in order, however. XDMCP is an inherently insecure protocol. Although technologically nothing is standing in the way of running XDMCP between two computers on the Internet or on an untrusted network, it should never be done. It is too easy for hackers to snoop and grab such critical information as usernames and passwords transmitted over the connection without encryption. XDMCP should be run across only a trusted network. If you need to provide an X terminal across an untrusted network, a slower, slightly less convenient way to do this is mentioned in the security section.

Assuming you have not been scared off, to begin configuring XDMCP, be sure the computer to become the X terminal and the one to become the server are connected over your network. The simplest way to check this is to ping one from the other. If you can ping in both directions, you are ready to begin the configuration.

If you are trying to get some use out of old hardware or trying to outfit a workgroup or lab on a budget, the most powerful machine(s) is your server(s). In the case of bringing the power of Linux to Windows or Mac users, the Linux machine(s) is your server(s). For now, I assume you are configuring only one server. Multiple server set up is discussed later.

The server must be running some display manager, the standard being xdm. Both gdm and kdm, respectively the GNOME and KDE replacements for xdm, are shipped with many distributions and offer preconfigured interfaces that are likely to be sexier than what is offered by xdm. Operationally, they all are capable of providing X terminal services. In fact, if your server boots into a graphical login screen, you already are running a display manager. To find out which one, login and issue the command ps -A | grep dm. The results should be something like

634 ? 00:00:00 cardmgr
857 ? 00:00:00 gdm-binary
889 ? 00:00:00 gdm-binary

which means you are running gdm. If your computer boots into a text login screen, you either can reconfigure it to boot into a graphical login or run a display manager from the command line after logging in as root. This second option is useful only as a temporary solution while you are experimenting, however.

If you intend to use the machine as an XDMCP server, it’s best to configure it to run a display manager upon booting. This is done by modifying /etc/inittab. The default run level is set in the line containing initdefault. It should read

id:5:initdefault:

Once you have made this change, you may reboot or issue the command telinit 5 to get a graphical login. Be sure X is set up with a resolution less than or equal to the resolution to be used on the X terminals.

At this point, the impatient may skip the rest of this section and configure an X terminal. If your distribution shipped with XDMCP enabled and configured to serve fonts and no firewall gets in your way, you should have a fully functional XDMCP server. For the patient, simply continue reading and reconfiguring or verifying that XDMCP is configured correctly.

At this point, I assume you are patient or you’re back here because your attempt to connect an X terminal failed. One likely reason for a failed connection is the firewall on the server or, worse, somewhere else in your network. To temporarily disable the firewall on the server while you attempt to configure XDMCP, issue the commandipchains -F (or iptables -F) on the server. This eliminates the firewall altogether. To be more selective about your firewall policies, you may try the ipchains (or similar iptables) command

ipchains -A input -p udp -i $extint --dport 177 -j ACCEPT

In addition, make the following changes (if necessary) to the following xdm configuration files. In /etc/X11/xdm/xdm-config, change the lineDisplayManager.requestPort: 0 to !DisplayManager.requestPort: 0 (that is, comment it out) so that the server can listen for XDMCP connections. In /etc/X11/xdm/Xaccess, change the line #* # any host can get a login window to * # any host can get a login window so others can access xdm. If you are not using kdm or gdm as your display manager, you are done with this part. However, if you are using kdm, you must edit kdmrc as well. Under Red Hat, this file is located in /etc/X11/xdm. In the [Xdmcp] section, set Enable=true and uncomment the linePort=177. If you are using gdm, you must make the same modifications to gdm.conf, which is located in /etc/X11/gdm under Red Hat.

Configuring an X terminal simply amounts to installing an X server and running an X query. No window manager or desktop environment are necessary. This is why the X terminal’s hardware is relatively unimportant, except perhaps the network interface card. There are at least three ways to configure an X terminal to utilize XDMCP. One way is to setup a dummy terminal to run X with no window manager and no applications and then have the XDMCP server push a login screen onto the terminal. This is covered in this useful mini how-to.

I, however, will stick to configuring a not-quite-so-dumb X terminal. This means the X terminal must have some operating system with a configured X server installed. In case of Linux, Windows or Macintosh, an implementation of XFree86 is available free of charge. For Linux, installing XWindows is an option that should be chosen when the OS is installed. For Windows, consider installing Cygwin with the (optional) XFree86base package and dependencies installed. For Mac, consider installingXDarwin, an implementation of the XFree86 server. X servers are available for many other platforms as well, and any one is sufficient to run an X terminal.

Once you have an X server installed, all you need to do is run it with a query option. Three types of queries are available. If you are running only one XDMCP server, it is best to use a direct query. This is done from a non-X shell, not an xterm. If you are running Linux or UNIX, you should configure the machine to boot to a text login. If this already is the case, you are all set. If not, this is done, under Linux, by modifying the default run level in /etc/inittab. The default run level is set on the line containing initdefault. It should read

id:3:initdefault:

Once you have made this change, you may reboot or issue the command telinit 3 to get a text login. Log in as any user and issue the command X -query my.XDMCP.server, where my.XDMCP.server is either the name or IP address of the XDMCP server. If you are running windows and have installed Cygwin, from the Cygwin bash shell, issue the command XWin.exe -query my.XDMCP.server. If you are running Mac OS and have installed XDarwin, from a terminal issue the same command as used under Linux/UNIX. You should see the graphical login window of your XDMCP server. If you are having font issues, consult this excellent how-toto find the necessary server configurations to resolve the issue.

Customizing the Login Screen

The display manager login screen and chooser interface are fully customizable. If you are running gdm, you may use the graphical setup utility gdmsetup or modify the text file /etc/X11/gdm/gdm.conf. If you are running kdm, modify /etc/X11/xdm/kdmrc. If you are running xdm, start with modifying /etc/X11/xdm/Xresources. If you don’t find everything you want to customize in these files, look at the other files in /etc/X11/xdm/, for example, XSetup_0 or xdm-config. I expect most people choose to use gdm or kdm, so I won’t go into details on xdm customization. Also, because gdm offers a graphical customization tool, I scratch only the surface of customizations, focusing on kdm customization under Red Hat only.

Regardless of which display manager you run, you may want to consider customizing a few things. For example, you may want your own background image and your own welcome message to appear on the login screen, and you definitely want to prevent users from shutting down the server through the login window. For kdm users, the background image is presented on the login screen by an auxiliary program called xsri. Under Red Hat, the script /etc/X11/xdm/XSetup_0 checks for the existence of the program and the associated file /etc/X11/xsrirc. If both exist, xsri is run and the graphic indicated in /etc/X11/xsrirc is displayed on the login screen. So, if you want to change the background image, simply change the graphic file listed in /etc/X11/xsrirc. To change the welcome message, find the GreetString option under the [X-*-Greeter] section of the file kdmrc. You may set this string equal to anything you like, but long messages may not display fully or may distort the appearance of the login window. Macros may be used in the GreetString too. For example, the default greeting is «Welcome to %s at %n» where %s is expanded into the operating system and %n is expanded into the node name (usually the hostname without domain name). Other macros are available and are listed above the GreetString line in kdmrc.

Finally, and most importantly, you need to keep regular users from shutting down the server. Allowing them to shut down is dangerous because they may shut it down while other users are working on the same machine. Again, inside the file kdmrc, find the AllowShutdown option under both the [X-*-Core] section and the [X-:*-Core] section and set them both to Root. This change requires the root password in order to shut down the machine from the login window. Additionally, when a user logs out of a session, the shutdown option does not appear in the ensuing dialog box. However, you may prefer to set these options to None, in which case the shutdown button will not appear at all in the login window.

Multiple Server Setup

Multiple servers may be set up in exactly the manner described in the section on configuring a server, and they can be accessed by X terminals in exactly the manner described in the section on configuring an X terminal. However, this requires the user to pick a server to login to and to know its name or IP address. A more effective method of managing multiple servers is to run a chooser and have users of X terminals submit indirect queries.

To begin, configure each server as described previously. Then, pick one machine to run a chooser. On this machine, modify the file /etc/X11/xdm/Xaccess in one of two ways. The easiest way is to uncomment the line * CHOOSER BROADCAST. When an indirect query is received, the chooser sends out a broadcast query and displays a list of machines that responded to the query. The X terminal user then may select to log in to one of these machines. This setup does not work in all environments, however, and you may not want to give users access to all servers on your network.

To be selective as to which servers are reported by the chooser, comment out the line* CHOOSER BROADCAST by putting a # at the beginning and uncomment the lines#%hostlist host-a host-b and #* CHOOSER %hostlist. Then, replace host-a host-bwith a space-separated list of all hosts that you wish to appear in the chooser. This way, the chooser can send direct queries to each machine in the list and report the results to the chooser.

Finally, to see the chooser from an X terminal, run X with the option -indirect my.XDMCP.chooser, where my.XDMCP.chooser is the name of the machine configured to supply a chooser. Under UNIX, remember the command to run X is X and under Cygwin it is XWin.exe.

Further Information

Advantages: the main advantages of running XDMCP are clear from the goal you wish to meet by running it. However, there are some disadvantages, one big one being the lack of security. Additionally, access to the X terminal’s sound card, floppy drive, CD-ROM drive, scanner and any other local hardware besides the keyboard, mouse and monitor is difficult at best. I do not have a reasonable solution to offer on this issue. Perhaps someone can offer one in a future article.

Security: as stated earlier, XDMCP is an insecure protocol. However, if you require X terminal services over an insecure network, there is at least one option. Instead of setting up your server to run XDMCP, configure it as an SSH (secure shell) server. Then, from the X terminal, start an X session running nothing but an xterm, not even a window manager. From this xterm, issue the command ssh -X loginname@ssh.server, where ssh.server is the name or IP address of the ssh server and loginname is your login on the server. The -X enables X11 forwarding over the secure connection. After logging in, issue startkde to begin a KDE session or gnome-session to begin a GNOME session. Alternatively, you may run a full blown desktop environment on the X terminal, run an xterm there and issue the command ssh -X loginname@ssh.server command where command is the command/program you wish to run. This allows you to run a single program at a time on the remote machine rather than on a desktop environment.

Installing and running an SSH server and client should be straightforward. For example, Red Hat ships with an optional sshd (server) package and the client is installed by default. For Cygwin, an OpenSSH client is an optional package. For more information than you probably care to know about SSH, see www.openssh.org or read the man pages on SSH and sshd.

References

XDMCP How-To by Thomas Chao

XDM-Xterm Mini How-To by Kevin Taylor.

Much of the information for this article was taken from these two documents. Additionally, each how-to contains a list of more reference materials.

Author –> Leon Brin has been a member of the mathematics department at Southern CT State University for three years and a Linux enthusiast for five. He welcomes your comments at brin@southernct.edu.

CWE – Common Weakness Enumeration

Fuente: http://nvd.nist.gov/cwe.cfm#cwes

The Common Weakness Enumeration Specification (CWE) provides a common language of discourse for discussing, finding and dealing with the causes of software security vulnerabilities as they are found in code, design, or system architecture. Each individual CWE represents a single vulnerability type. CWE is currently maintained by the MITRE Corporation with support from the National Cyber Security Division (DHS). A detailed CWE list is currently available at the MITRE website; this list provides a detailed definition for each individual CWE. 

All individual CWEs are held within a hierarchical structure that allows for multiple levels of abstraction. CWEs located at higher levels of the structure (i.e. Configuration) provide a broad overview of a vulnerability type and can have many children CWEs associated with them. CWEs at deeper levels in the structure (i.e.Cross Site Scripting) provide a finer granularity and usually have fewer or no children CWEs. The image to the right represents a portion of the overall CWE structure, the red boxes represent the CWEs being used by NVD. (click to enlarge).

NVD integrates CWE into the scoring of CVE vulnerabilities by providing a cross section of the overall CWE structure. NVD analysts score CVEs using CWEs from different levels of the hierarchical structure. This cross section of CWEs allows analysts to score CVEs at both a fine and coarse granularity, which is necessary due to the varying levels of specificity possessed by different CVEs. The cross section of CWEs used by NVD is listed below; each CWE listed links to a detailed description hosted by MITRE. For a better understanding of how the standards link together please visit: MITRE – Making Security Measurable

CWE is not currently part of the Security Content Automation Protocol (SCAP). NVD is using CWE as a classification mechanism that differentiates CVEs by the type of vulnerability they represent.

Related Activities


CWE Cross Section Mapped into by NVD

Name CWE-ID Description
Authentication Issues CWE-287 Failure to properly authenticate users.
Credentials Management CWE-255 Failure to properly create, store, transmit, or protect passwords and other credentials.
Permissions, Privileges, and Access Control CWE-264 Failure to enforce permissions or other access restrictions for resources, or a privilege management problem.
Buffer Errors CWE-119 Buffer overflows and other buffer boundary errors in which a program attempts to put more data in a buffer than the buffer can hold, or when a program attempts to put data in a memory area outside of the boundaries of the buffer.
Cross-Site Request Forgery (CSRF) CWE-352 Failure to verify that the sender of a web request actually intended to do so. CSRF attacks can be launched by sending a formatted request to a victim, then tricking the victim into loading the request (often automatically), which makes it appear that the request came from the victim. CSRF is often associated with XSS, but it is a distinct issue.
Cross-Site Scripting (XSS) CWE-79 Failure of a site to validate, filter, or encode user input before returning it to another user’s web client.
Cryptographic Issues CWE-310 An insecure algorithm or the inappropriate use of one; an incorrect implementation of an algorithm that reduces security; the lack of encryption (plaintext); also, weak key or certificate management, key disclosure, random number generator problems.
Path Traversal CWE-22 When user-supplied input can contain “..” or similar characters that are passed through to file access APIs, causing access to files outside of an intended subdirectory.
Code Injection CWE-94 Causing a system to read an attacker-controlled file and execute arbitrary code within that file. Includes PHP remote file inclusion, uploading of files with executable extensions, insertion of code into executable files, and others.
Format String Vulnerability CWE-134 The use of attacker-controlled input as the format string parameter in certain functions.
Configuration CWE-16 A general configuration problem that is not associated with passwords or permissions.
Information Leak / Disclosure CWE-200 Exposure of system information, sensitive or private information, fingerprinting, etc.
Input Validation CWE-20 Failure to ensure that input contains well-formed, valid data that conforms to the application’s specifications. Note: this overlaps other categories like XSS, Numeric Errors, and SQL Injection.
Numeric Errors CWE-189 Integer overflow, signedness, truncation, underflow, and other errors that can occur when handling numbers.
OS Command Injections CWE-78 Allowing user-controlled input to be injected into command lines that are created to invoke other programs, using system() or similar functions.
Race Conditions CWE-362 The state of a resource can change between the time the resource is checked to when it is accessed.
Resource Management Errors CWE-399 The software allows attackers to consume excess resources, such as memory exhaustion from memory leaks, CPU consumption from infinite loops, disk space consumption, etc.
SQL Injection CWE-89 When user input can be embedded into SQL statements without proper filtering or quoting, leading to modification of query logic or execution of SQL commands.
Link Following CWE-59 Failure to protect against the use of symbolic or hard links that can point to files that are not intended to be accessed by the application.
Other No Mapping NVD is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset.
Not in CWE No Mapping The weakness type is not covered in the version of CWE that was used for mapping.
Insufficient Information No Mapping There is insufficient information about the issue to classify it; details are unkown or unspecified.
Design Error No Mapping A vulnerability is characterized as a “Design error” if there exists no errors in the implementation or configuration of a system, but the initial design causes a vulnerability to exist.