Welcome to Eric Hameleers (Alien BOB)'s Wiki pages.

If you want to support my work, please consider a small donation:

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

linux:kernelbuilding [2009/02/23 15:48]
alien Move "kernel-headers package" to a separate chapter
linux:kernelbuilding [2012/08/20 00:23] (current)
alien [Translations] New URL.
Line 21: Line 21:
 Now that the build environment is set up, let us continue with obtaining the sources. Now that the build environment is set up, let us continue with obtaining the sources.
  
-Download a new kernel, unpack it into ''/usr/src'' and create the "linux" link so that the commands are a little more generic. I will take a kernel version of "2.6.27.7" as an example. If yours is a different version, you'll know where to change the version strings in the rest of the story below. If you want to know how to verify the integrity of the source code archive using the kernel GPG key, read the [[#gpg_signature | last chapter]] below. <code> +Download a new kernel, unpack it into ''/usr/src'' and create the "linux" link so that the commands are a little more generic. I will take a kernel version of "2.6.37.6" as an example. If yours is a different version, you'll know where to change the version strings in the rest of the story below. If you want to know how to verify the integrity of the source code archive using the kernel GPG key, read the [[#gpg_signature | last chapter]] below. <code> 
-wget http://www.us.kernel.org/pub/linux/kernel/v2.6/linux-2.6.27.7.tar.bz2 +wget http://www.us.kernel.org/pub/linux/kernel/v2.6/linux-2.6.37.6.tar.bz2 
-tar -C /usr/src -jxvf linux-2.6.27.7.tar.bz2+tar -C /usr/src -jxvf linux-2.6.37.6.tar.bz2
 cd /usr/src cd /usr/src
 rm linux                     # remove the existing symlink rm linux                     # remove the existing symlink
-ln -s linux-2.6.27.linux   # create a symlink pointing to your new linux source+ln -s linux-2.6.37.linux   # create a symlink pointing to your new linux source
 </code> </code>
  
Line 35: Line 35:
 Now, get a Slackware kernel config file for a headstart during your own configuring. Pat's config files are pretty generic. By the time you read this, there might be a config for a newer 2.6 release available: Now, get a Slackware kernel config file for a headstart during your own configuring. Pat's config files are pretty generic. By the time you read this, there might be a config for a newer 2.6 release available:
 <code> <code>
-wget http://slackware/mirrors.tds.net/pub/slackware/slackware-12.2/source/k/config-generic-smp-2.6.27.7-smp +wget http://slackware.mirrors.tds.net/pub/slackware/slackware-13.37/source/k/config-generic-smp-2.6.37.6-smp 
-cp config-generic-smp-2.6.27.7-smp /usr/src/linux/.config+cp config-generic-smp-2.6.37.6-smp /usr/src/linux/.config
 </code> Alternatively, you can grab the configuration for the kernel which is currently running: <code> </code> Alternatively, you can grab the configuration for the kernel which is currently running: <code>
 zcat /proc/config.gz > /usr/src/linux/.config zcat /proc/config.gz > /usr/src/linux/.config
Line 46: Line 46:
 </code> </code>
  
-You now have configured a pretty generic kernel (that is the reason why Pat calls them "kernel-generic" probably :-) but you will want to change some of the defaults to suit your needs. Run the X based configurator (if you do not run X but are at a text console, just run "make menuconfig" to get the curses-based dialog program instead)+You now have configured a pretty generic kernel (that is the reason why Pat calls them "kernel-generic" probably :-) but you will want to change some of the defaults to suit your needs. Run the X based configurator (if you do not run X but are at a text console, just run "''make menuconfig''" to get the curses-based dialog program instead)
 <code> <code>
 make xconfig make xconfig
Line 53: Line 53:
 Walk through the forest of options. What I usually change are things like: Walk through the forest of options. What I usually change are things like:
  
-  * build the ext3 (needs the jbd driver as well) and reiser/xfs/jfs fileystem drivers into the kernel instead of compiling them as modules - that way I do not need to create an additional "[[#creating_an_initrd|initrd]]"\\ (see under "Filesystems" in the configurator).+  * Build the ext3 (needs the jbd driver as well) and reiser/xfs/jfs fileystem drivers into the kernel instead of compiling them as modules - that way I do not need to create an additional "[[#creating_an_initrd|initrd]]"\\ (see under "Filesystems" in the configurator).
  
-  * enable 64GB of RAM.\\ (under "Processor type and features" > "High Memory Support (64GB)"). Use this if you have a system with 4GB of RAM or more.+  * Enable 64GB of RAM.\\ (under "Processor type and features" > "High Memory Support (64GB)"). Use this if you have a system with 4GB of RAM or more.
  
-  * enable the "low-latency" kernel if you run a desktop/laptop computer - multimedia apps will run much smoother\\ (under "Processor type and features" > "Preemption model" > "Preemptible kernel"). If you run a desktop system with a lot of multimedia applications, then this is an useful option for you because it will keep your system more responsive even under high load.+  * Enable the "low-latency" kernel if you run a desktop/laptop computer - multimedia apps will run much smoother\\ (under "Processor type and features" > "Preemption model" > "Preemptible kernel"). If you run a desktop system with a lot of multimedia applications, then this is an useful option for you because it will keep your system more responsive even under high load.
  
-  * set a 1000 Hz timer (under "Processor type and features" > "Timer Frequency" > "1000 Hz"). A higher tick count can be beneficial to multimedia 'desktop' systems.+  * Set a 1000 Hz timer (under "Processor type and features" > "Timer Frequency" > "1000 Hz"). A higher tick count can be beneficial to multimedia 'desktop' systems.
  
-  * or set a tickless timer (dynamic ticks - under "Processor type and features" > "Tickless System (Dynamic Ticks)").+  * Or set a tickless timer (dynamic ticks - under "Processor type and features" > "Tickless System (Dynamic Ticks)").
  
-  * ... and more I can't think of right now. You can decide to disable a lot of the modules that the default config will build, to cut down on time, if you don't have the hardware in your computer. You could also looka at software suspend and CPU frequency scaling (under "Processor type and features") if you own a laptop.+  * If you are (re-)building a Slackware kernel, you should make sure that installing your new kernel will leave the original kernel modules intact. You do this by changing the //local-version// part of the kernel's release number to an unique string (under "General setup" > "Local version - append to kernel release"). This kernel option corresponds to **CONFIG_LOCALVERSION** in your ''.config'' file. Slackware sets that value to "-smp" for a SMP kernel to give you an idea. \\ The resulting kernel release value (as returned by "''umake -r''") for a kernel version "''2.6.37.6''" with a local-version of "''-alien''" would be "''2.6.37.6-alien''" 
 + 
 +  * ... and more I can't think of right now. You can decide to disable a lot of the modules that the default config will build, to cut down on compilation time, if you don't have the hardware in your computer. You could also look at //software suspend// and //CPU frequency scaling// (under "Processor type and features") if you own a laptop.
  
 And finally save your configuration if you're satisfied. And finally save your configuration if you're satisfied.
Line 75: Line 77:
 make bzImage modules            # compile the kernel and the modules make bzImage modules            # compile the kernel and the modules
 make modules_install            # installs the modules to /lib/modules/<kernelversion> make modules_install            # installs the modules to /lib/modules/<kernelversion>
-cp arch/x86/boot/bzImage /boot/vmlinuz-custom-2.6.27. # copy the new kernel file +cp arch/x86/boot/bzImage /boot/vmlinuz-custom-2.6.37. # copy the new kernel file 
-cp System.map /boot/System.map-custom-2.6.27.7           # copy the System.map (optional) +cp System.map /boot/System.map-custom-2.6.37.6          # copy the System.map (optional) 
-cp .config /boot/config-custom-2.6.27.7                  # backup copy of your kernel config+cp .config /boot/config-custom-2.6.37.6                 # backup copy of your kernel config
 cd /boot cd /boot
-rm System.map                                            # delete the old link +rm System.map                                           # delete the old link 
-ln -s System.map-custom-2.6.27.System.map              # create a new link+ln -s System.map-custom-2.6.37.System.map              # create a new link
 </code> </code>
  
 +With 2.6.x kernels, running "''make''" or "''make all''" instead of "''make bzImage modules''" should be sufficient. This will build the default targets, being //vmlinux// (the uncompressed kernel), //bzImage// (the compressed kernel which we will be using) and //modules// (all of the kernel modules). Since we do not need the uncompressed kernel I usually stick to the "''make bzImage modules''" command. \\ If you want to know more about the available //make// targets, you can run "''make help''" and examine the output. The default build targets are marked by an asterisk (*).
  
 ==== Modifying lilo.conf ==== ==== Modifying lilo.conf ====
  
-Edit ''/etc/lilo.conf'' and add a new section for your new kernel. Remember, your new kernel may not even boot if you made a mistake somewhere, so you will want to leave the sections for your current kernel(s) intact. Your current ''/etc/lilo.conf'' will have a section somewhat like this, near the bottom of the file: <code>+Edit ''/etc/lilo.conf'' and add a new section for your new kernel. Remember, your new kernel may not even boot if you made a mistake somewhere, so you will want to leave the existing sections for your current kernel(s) intact. Your current ''/etc/lilo.conf'' will have a section somewhat like this, near the bottom of the file: <code>
 image = /boot/vmlinuz image = /boot/vmlinuz
-root = /dev/hda1+root = /dev/sda1
 label = linux label = linux
 read-only # Non-UMSDOS filesystems should be mounted read-only for checking read-only # Non-UMSDOS filesystems should be mounted read-only for checking
-</code> Add another section just below (adding it below will guarantee that your current kernel will remain the default to start):+</code> Add another section just below (adding it below will guarantee that your current - working - kernel will stay the default to boot):
 <code> <code>
-image = /boot/vmlinuz-custom-2.6.27.7 +image = /boot/vmlinuz-custom-2.6.37.6 
-root = /dev/hda1+root = /dev/sda1
 label = newkernel label = newkernel
 read-only # Non-UMSDOS filesystems should be mounted read-only for checking read-only # Non-UMSDOS filesystems should be mounted read-only for checking
 </code> </code>
-After adding stanza for your new kernel to ''/etc/lilo.conf'' and saving the file, run lilo to activate your changes: <code>+After you have added section for your new kernel to ''/etc/lilo.conf'' you should save the file, and then run ''lilo'' to activate your changes: <code>
 lilo lilo
 </code> </code>
  
-Now is the time for a reboot, to test the resultsIn the lilo boot screen, select the "''newkernel''" option instead of the default "''linux''" option.\\ +Now is the time for a reboot, and test that new kernelWhen the lilo boot screen appears, select the "''newkernel''" option instead of the default "''linux''" option.\\ 
-If the new kernel boots fine, you can add this line to the top of ''/etc/lilo.conf'' and re-run "lilo": <code>+If your new kernel boots fine, you can make it the default kernel by adding the following line to the top of ''/etc/lilo.conf'' and re-run "lilo": <code>
 default = newkernel default = newkernel
 </code> </code>
Line 112: Line 115:
 You are going to build and use a new kernel. You may wonder what you need to do with the Slackware //kernel-headers// package.\\ The answer is: **do not remove this package!** You are going to build and use a new kernel. You may wonder what you need to do with the Slackware //kernel-headers// package.\\ The answer is: **do not remove this package!**
  
-There are two places where you will find kernel headers; one place is inside the kernel source directory (in our case, the ''/usr/src/linux-2.6.27.7'' directory) and the other place is ''/usr/include/linux''. The //kernel-headers// package usually contains the headers taken from the source of the default Slackware kernel. These particular headers are used when the //glibc// package is built. The fact that the ''kernel-headers'' package installs these files to ''/usr/include/linux'' makes them independent of the header files you find in the kernel source directory.+There are two places where you will find kernel headers; one place is inside the kernel source directory (in our case, the ''/usr/src/linux-2.6.37.6'' directory) and the other place is ''/usr/include/linux''. The //kernel-headers// package usually contains the headers taken from the source of the default Slackware kernel. These particular headers are used when the //glibc// package is built. The fact that the ''kernel-headers'' package installs these files to ''/usr/include/linux'' makes them independent of the header files you find in the kernel source directory.
  
 <note>As long as you do not upgrade your //glibc// package, you should not upgrade or remove the ''kernel-headers'' package.</note> <note>As long as you do not upgrade your //glibc// package, you should not upgrade or remove the ''kernel-headers'' package.</note>
Line 118: Line 121:
   * How do the ''kernel-headers'' and ''glibc'' packages relate?\\ At some point in time you will want to upgrade (recompile!) parts of your system's software. If that software links against glibc (as most core software does), it's successful compilation relies on the presence of the correct kernel headers in ''/usr/include/linux''. It does not matter that you are propably running an entirely different kernel than Slackware's default kernel. The ''kernel-headers'' package reflects the state of the system at the time ''glibc'' was built. If you delete the ''kernel-headers'' package, your running system will in no way be affected, but you will not be able to (re-)compile most software.   * How do the ''kernel-headers'' and ''glibc'' packages relate?\\ At some point in time you will want to upgrade (recompile!) parts of your system's software. If that software links against glibc (as most core software does), it's successful compilation relies on the presence of the correct kernel headers in ''/usr/include/linux''. It does not matter that you are propably running an entirely different kernel than Slackware's default kernel. The ''kernel-headers'' package reflects the state of the system at the time ''glibc'' was built. If you delete the ''kernel-headers'' package, your running system will in no way be affected, but you will not be able to (re-)compile most software.
  
-  * Do the kernel sources still serve a purpose after you have built your new kernel?\\ In the previous bullet point I told you that the compilation of system software uses the headers located in ''/usr/include/linux''. Likewise, the kernel source tree is required any time you want to compile a 3rd-party kernel module (madwifi, linux-uvc, ndiswrapper, ... the list is endless). You are not limited to compiling a driver for your running kernel. You can build drivers for any kernel as long as its modules tree (below ''/lib/modules'') and sources are present.\\ Let's say you are going to build a module for a kernel whose version is specified in an environment variable ''$KVER''. During the driver's compilation you will need to have kernel header files available in the location ''/lib/modules/$KVER/build/include/linux''. The symbolic link ''/lib/modules/$KVER/build'' is created at the time when you install your new kernel and modules.\\ If you delete the kernel sources after you build a kernel, you will not be able to build any "out-of-kernel" (other word for 3rd-party) drivers afterwards.+  * Do the kernel sources still serve a purpose after you have built your new kernel?\\ In the previous bullet point I told you that the compilation of system software uses the headers located in ''/usr/include/linux''. Likewise, the kernel source tree is required any time you want to compile a 3rd-party kernel module (madwifi, linux-uvc, ndiswrapper, ... the list is endless). You are not limited to compiling a driver for your running kernel. You can build drivers for any kernel as long as its modules tree (below ''/lib/modules'') and sources are present.\\ Let's say you are going to build a module for a kernel whose version you have specified in an environment variable ''$KVER''. For instance, by running <code> 
 +export KVER=2.6.38.2 
 +</code> During the driver's compilation you will need to have this particular kernel's header files available in the location ''/lib/modules/$KVER/build/include/linux''. The symbolic link ''/lib/modules/$KVER/build'' is created at the time when you install your new kernel and modules.\\ If you delete the kernel sources after you build a kernel, you will not be able to build any "out-of-kernel" (other word for 3rd-party) drivers afterwards.
  
  
 ===== Other packages that contain kernel modules ===== ===== Other packages that contain kernel modules =====
  
-Most certainly you will have packages installed that contain kernel modules that are not part of the default kernel. Slackware has "alsa-driver" for instance, and if you installed any wireless driver, these are basically kernel modules too.\\ +Most certainly you will have installed one or more packages containing kernel modules that are not part of the default kernel. Slackware installs the "svgalib-helperpackage for instance, and if you installed any wireless driver, these are basically kernel modules too.\\ 
-Now, with the installation of your new kernel, you will lose these modules, and you have to recompile the sources so that the binary modules match the new kernel.\\ +Be aware that by installing and booting into your new kernel, you will no longer have these out-of-kernel modules available. You have to recompile their sources so that the resulting kernel modules match the version of your new kernel.\\ 
-You can get an overview of all packages that have installed a kernel module for your current kernel by running this command (i.e. you must run this command while still running your old kernel): <code>+You can get an overview of all packages that have installed a kernel module for your current kernel by running this command (//note that you must run this command while still running your old kernel//): <code>
 cd /var/log/packages cd /var/log/packages
 grep -l "lib/modules/$(uname -r)" * grep -l "lib/modules/$(uname -r)" *
 </code> </code>
-All the mentioned packages will need a recompile.+All the listed packages will need a recompile if you want to have their modules available for your new kernel as well. 
 + 
 +<note tip>If you rebuild a package containing a kernel module, use **installpkg** rather than **upgradepkg** to install this new package without removing the original version. \\ If you used ''upgradepkg'' this would remove the old kernel module and you may still need this if you ever want to reboot into your old kernel. This trick works under the assumption that the version of the kernel is part of the //VERSION// of your package, like here: ''svgalib_helper-1.9.25_//2.6.37.6//-i486-1.txz'' (I know, lame example since this package no longer exists)</note> 
 + 
 +<note warning>The method described above will leave you **unaware** of any kernel modules that you may have compiled manually instead of creating a package for them. Typically, proprietary graphics drivers such as those from //Nvidia// or //Ati// will cause a few anxious moments if you forget to recompile them for your new kernel before starting X Window... especially when your computer boots into the graphical //runlevel 4// by default. 
 + 
 +In that case, reboot into //runlevel 3//, download the latest version of your graphics driver and compile/install the driver. This will enable you to reboot into your graphical logon. \\ For those who forget, booting into another than the default runlevel is easy: when the LILO screen appears, type the label of your kernel (which was ''newkernel'' in our example above) and after that, type the runlevel number: <key>newkernel</key> <key>Space</key><key>3</key><key>Enter</key></note>
  
-For ALSA you have a choice: either enable the ALSA driver that is part of the kernel you've just downloaded, or leave the kernel configuration like Slackware's: disable all ALSA support in the kernel and instead re-build the alsa-driver package. The 2.6 kernels of Slackware 12.2 have all the ALSA drivers built-in because they will not work with the ALSA driver releases you can install separately. 
  
  
Line 141: Line 151:
 Kernel Panic-not syncing: VFS: unable to mount root fs on unknown block(8,2) Kernel Panic-not syncing: VFS: unable to mount root fs on unknown block(8,2)
 </code> and this means you will have to build an //initrd// or "Initial Ram Disk" containing the required modules. The location of the initrd is then added in the appropriate section of ''/etc/lilo.conf'' so that the kernel can find it when it boots, and is able to load the drivers it needs to access your disks. </code> and this means you will have to build an //initrd// or "Initial Ram Disk" containing the required modules. The location of the initrd is then added in the appropriate section of ''/etc/lilo.conf'' so that the kernel can find it when it boots, and is able to load the drivers it needs to access your disks.
-Creating an initrd is quite simple, and I will show two cases here, one in care you have a Reiser filesystem on your root partition, and the second for the case you have an ext3 filesystem. I assume a 2.6.27.kernel in these example commands, if your new kernel is different, change the version number as appropriate.+Creating an initrd is quite simple, and I will show two cases here, one in care you have a Reiser filesystem on your root partition, and the second for the case you have an ext3 filesystem. I assume a 2.6.37.kernel in these example commands, if your new kernel is different, change the version number as appropriate.
  
   * Change into the /boot directory: <code>   * Change into the /boot directory: <code>
Line 147: Line 157:
  
   * Run "mkinitrd" to create the ''/boot/initrd'' file containing a compressed filesystem with the modules you tell it to add on the commandline: <code>   * Run "mkinitrd" to create the ''/boot/initrd'' file containing a compressed filesystem with the modules you tell it to add on the commandline: <code>
-mkinitrd -c -k 2.6.27.-m reiserfs</code> for a Reiser filesystem, or <code> +mkinitrd -c -k 2.6.37.-m reiserfs</code> for a Reiser filesystem, or <code> 
-mkinitrd -c -k 2.6.27.-m ext3</code> in case you installed an ext3 filesystem on your root partition..+mkinitrd -c -k 2.6.37.-m ext3</code> in case you installed an ext3 filesystem on your root partition..
  
   * Add the line "initrd = /boot/initrd.gz" to the newkernel's section in the file ''/etc/lilo.conf'', save your changes and then re-run lilo; I will use the ''lilo.conf'' example section I already used in a previous paragraph: <file>   * Add the line "initrd = /boot/initrd.gz" to the newkernel's section in the file ''/etc/lilo.conf'', save your changes and then re-run lilo; I will use the ''lilo.conf'' example section I already used in a previous paragraph: <file>
-image = /boot/vmlinuz-custom-2.6.27.7 +image = /boot/vmlinuz-custom-2.6.37.6 
-  root = /dev/hda1+  root = /dev/sda1
   initrd = /boot/initrd.gz   initrd = /boot/initrd.gz
   label = newkernel   label = newkernel
Line 160: Line 170:
   * If you are already using an initrd image with your current kernel, you can choose between two options:   * If you are already using an initrd image with your current kernel, you can choose between two options:
     * Create a second initrd image using the command above but with an explicit name for the resulting initrd file (which should be different from the default in order not to overwrite the old one: <code>     * Create a second initrd image using the command above but with an explicit name for the resulting initrd file (which should be different from the default in order not to overwrite the old one: <code>
-mkinitrd -c -k 2.6.27.-m ext3 -o /boot/initrd-custom-2.6.27.7.gz</code> and then change the ''lilo.conf'' section to look like this: <file> +mkinitrd -c -k 2.6.37.-m ext3 -o /boot/initrd-custom-2.6.37.6.gz</code> and then change the ''lilo.conf'' section to look like this: <file> 
-image = /boot/vmlinuz-custom-2.6.27.7 +image = /boot/vmlinuz-custom-2.6.37.6 
-  root = /dev/hda1 +  root = /dev/sda1 
-  initrd = /boot/initrd-custom-2.6.27.7.gz+  initrd = /boot/initrd-custom-2.6.37.6.gz
   label = newkernel   label = newkernel
   read-only # Non-UMSDOS filesystems should be mounted read-only for checking   read-only # Non-UMSDOS filesystems should be mounted read-only for checking
 </file>  </file> 
     * Add the kernel modules for your new kernel to the existing initrd file. That way, you have a single initrd image containing modules for multiple kernels. All you need to do is leave out the option "''-c''" which is the option to wipe the directory ''/boot/initrd-tree'' and start from scratch:  <code>     * Add the kernel modules for your new kernel to the existing initrd file. That way, you have a single initrd image containing modules for multiple kernels. All you need to do is leave out the option "''-c''" which is the option to wipe the directory ''/boot/initrd-tree'' and start from scratch:  <code>
-mkinitrd -k 2.6.27.-m ext3+mkinitrd -k 2.6.37.-m ext3
 </code>  </code> 
  
 <note tip>I have written a shell script ([[http://www.slackware.com/~alien/tools/mkinitrd_command_generator.sh|mkinitrd_command_generator.sh]]) which examines your running Slackware system and shows you an example ''mkinitrd'' command. If you run that ''mkinitrd'' command, it will produce an initrd image that contains all the kernel modules and support libraries so that your system can boot with the Slackware //generic// kernel.\\ Here is an example of how to run the command with it's output shown as well:<code> <note tip>I have written a shell script ([[http://www.slackware.com/~alien/tools/mkinitrd_command_generator.sh|mkinitrd_command_generator.sh]]) which examines your running Slackware system and shows you an example ''mkinitrd'' command. If you run that ''mkinitrd'' command, it will produce an initrd image that contains all the kernel modules and support libraries so that your system can boot with the Slackware //generic// kernel.\\ Here is an example of how to run the command with it's output shown as well:<code>
-./mkinitrd_command_generator.sh /boot/vmlinuz-generic-smp-2.6.27.7-smp +/usr/share/mkinitrd/mkinitrd_command_generator.sh /boot/vmlinuz-generic-2.6.37.
 # #
-$Id: mkinitrd_command_generator.sh,v 1.11 2008/04/10 23:56:18 root Exp root $+# mkinitrd_command_generator.sh revision 1.45
 # #
- 
 # This script will now make a recommendation about the command to use # This script will now make a recommendation about the command to use
 # in case you require an initrd image to boot a kernel that does not # in case you require an initrd image to boot a kernel that does not
Line 184: Line 192:
 # A suitable 'mkinitrd' command will be: # A suitable 'mkinitrd' command will be:
  
-mkinitrd -c -k 2.6.27.7-smp -m ata_generic:pata_amd:mbcache:jbd:ext3 -f ext3 -r /dev/hda7 +mkinitrd -c -k 2.6.37.-f ext3 -r cryptslack -m mbcache:jbd:ext3 -/dev/sda8 -u -o /boot/initrd.gz 
- +# An entry in 'etc/lilo.conf' for kernel '/boot/vmlinuz-generic-2.6.37.6' would look like this:
- +
-# An entry in 'etc/lilo.conf' for +
-kernel '/boot/vmlinuz-generic-smp-2.6.27.7-smp' would look like this:+
 # Linux bootable partition config begins # Linux bootable partition config begins
-image = /boot/vmlinuz-generic-smp-2.6.27.7-smp+# initrd created with 'mkinitrd -c -k 2.6.37.6 -f ext3 -r cryptslack -m mbcache:jbd:ext3 -C /dev/sda8 -u -o /boot/initrd.gz' 
 +image = /boot/vmlinuz-generic-2.6.37.6
   initrd = /boot/initrd.gz   initrd = /boot/initrd.gz
-  root = /dev/hda7 +  root = /dev/mapper/cryptslack 
-  label = 2.6.27.7-smp+  label = 2.6.37.6
   read-only   read-only
 # Linux bootable partition config ends # Linux bootable partition config ends
-</code></note>+</code> You may notice that it detect my LUKS-encrypted root partition.\\ This script is included in the //mkinitrd// package of the Slackware releases after 12.2. 
 +</note>
  
 ===== Loading modules on boot ===== ===== Loading modules on boot =====
Line 205: Line 212:
   * Else, if ''/etc/rc.d/rc.modules-$(uname -r)'' exists, it will be run   * Else, if ''/etc/rc.d/rc.modules-$(uname -r)'' exists, it will be run
   * Else, if ''/etc/rc.d/rc.modules'' exists, it will be run   * Else, if ''/etc/rc.d/rc.modules'' exists, it will be run
-The **$(uname -r)** is the current kernel release. If your kernel version is ''2.6.27.7-smp'', then Slackware will look for a file ''/etc/rc.d/rc.modules-2.6.27.7-smp'' to run. This way, specific //rc// files for different kernels can be present, allowing an optimal tuning for your system.+The **$(uname -r)** is the current kernel release. If your kernel version is ''2.6.37.6-smp'', then Slackware will look for a file ''/etc/rc.d/rc.modules-2.6.37.6-smp'' to run. This way, specific //rc// files for different kernels can be present, allowing an optimal tuning for your system.
  
-The Slackware 12.package ''/slackware/a/kernel-modules-smp-2.6.27.7_smp-i686-1.tgz'' will install the file ''/etc/rc.d/rc.modules-2.6.27.7-smp''. You can use that as an example if you want to build your own kernel and need explicit ''modprobe'' commands for specific kernel modules.+The Slackware 13.37 package ''/slackware/a/kernel-modules-smp-2.6.37.6_smp-i686-1.txz'' will install the file ''/etc/rc.d/rc.modules-2.6.37.6-smp''. You can use that as an example if you want to build your own kernel and need explicit ''modprobe'' commands for specific kernel modules.
  
-<note>If you decide to build your own 2.6 kernel from source, you might get bitten by the fact that there will not be a file called  ''/etc/rc.d/rc.modules-$(uname -r)'' - you will have to create it yourself. The ''rc.modules'' usually is a symlink to the ''rc.modules-2.6.27.7-smp''. A typical result from the absence of a rc.modules file for your specific kernel is that your mouse will not be working. Take that behaviour as a hint to create the ''rc.modules'' file! You can take a full copy of any existing ''rc.modules-2.6.xx'' file. If your system does not have any rc file for a 2.6 kernel you can take the one on the Slackware CD as an example:\\  +<note>If you decide to build your own 2.6 kernel from source, you might get bitten by the fact that there will not be a file called  ''/etc/rc.d/rc.modules-$(uname -r)'' - you will have to create it yourself. The ''rc.modules'' usually is a symlink to the ''rc.modules-2.6.37.6-smp''. A typical result from the absence of a rc.modules file for your specific kernel is that your mouse will not be working. Take that behaviour as a hint to create the ''rc.modules'' file! You can take a full copy of any existing ''rc.modules-2.6.xx'' file. If your system does not have any rc file for a 2.6 kernel you can take the one on the Slackware CD as an example:\\  
-''/source/k/kernel-modules-smp/rc.modules.new''</note>+''/source/k/kernel-modules-smp/rc.modules.new''. \\ Here's an example in case you would have built a new kernel with version ''2.6.38.2.alien'' and you already had installed a Slackware kernel ''2.6.37.6-smp'': <code> 
 +cp -a /etc/rc.d/rc.modules-2.6.37.6-smp /etc/rc.d/rc.modules-2.6.38.2.alien 
 +</code> The file ''/etc/rc.d/rc.modules-2.6.38.2.alien'' will then be used when your new kernel ''2.6.38.2.alien'' boots.</note>
  
 ===== GPG signature ===== ===== GPG signature =====
Line 225: Line 234:
  
   * Next, get the signature file for the kernel archive you've downloaded: <code>   * Next, get the signature file for the kernel archive you've downloaded: <code>
-wget http://www.us.kernel.org/pub/linux/kernel/v2.6/linux-2.6.27.7.tar.bz2.sign</code> and make sure it is in the same directory as the kernel archive itself.+wget http://www.us.kernel.org/pub/linux/kernel/v2.6/linux-2.6.37.6.tar.bz2.sign</code> and make sure it is in the same directory as the kernel archive itself.
  
   *  The final step is to run gpg on this signature file, and check what it has to report: <code>   *  The final step is to run gpg on this signature file, and check what it has to report: <code>
-gpg --verify linux-2.6.27.7.tar.bz2.sign linux-2.6.27.7.tar.bz2+gpg --verify linux-2.6.37.6.tar.bz2.sign linux-2.6.37.6.tar.bz2
 </code> The output will be like this: <file> </code> The output will be like this: <file>
-gpg: Signature made Fri 21 Nov 2008 12:10:49 AM CET using DSA key ID 517D0F0E+gpg: Signature made Mon Mar 28 01:08:08 2011 CEST using DSA key ID 517D0F0E
 gpg: Good signature from "Linux Kernel Archives Verification Key <ftpadmin@kernel.org>" gpg: Good signature from "Linux Kernel Archives Verification Key <ftpadmin@kernel.org>"
-gpg: checking the trustdb 
-gpg: checking at depth 0 signed=1 ot(-/q/n/m/f/u)=0/0/0/0/0/4 
-gpg: checking at depth 1 signed=0 ot(-/q/n/m/f/u)=0/0/0/0/1/0 
-gpg: next trustdb check due at 2012-12-21 
 gpg: WARNING: This key is not certified with a trusted signature! gpg: WARNING: This key is not certified with a trusted signature!
 gpg:          There is no indication that the signature belongs to the owner. gpg:          There is no indication that the signature belongs to the owner.
Line 241: Line 246:
 </file> If you would have told gnupg to trust this key, the last part would have looked different. To me, adding a trustlevel to this key makes no real sense, except when you've met one of the kernel developers who had the key with him and could present thrustworthy credentials.\\ </file> If you would have told gnupg to trust this key, the last part would have looked different. To me, adding a trustlevel to this key makes no real sense, except when you've met one of the kernel developers who had the key with him and could present thrustworthy credentials.\\
 Nevertheless, the outcome is that the source code archive was indeed signed with the key that you just imported. So, that is good news. Nevertheless, the outcome is that the source code archive was indeed signed with the key that you just imported. So, that is good news.
 +
 +===== Translations =====
 +
 +  * This article has been translated into Spanish by Jorge Courbis: [[http://coredump.cl/wiki/doku.php?id=compilaci%C3%B3n_de_kernel | http://coredump.cl/wiki/doku.php?id=compilaci%C3%B3n_de_kernel]]
 +

Personal Tools
sponsoring