Browse Source

Add kernel related information (cfr. ChangeLog)

Sven Vermeulen 12 years ago
  1. 5
  2. 149


@ -1,3 +1,8 @@
** (2010-08-27) Sven Vermeulen <>
- Add information on kernel module parameters
- Add information on autoloading modules and blacklisting modules
- Add blurb about "make install" in kernel installation
** (2010-08-26) Sven Vermeulen <>
- Reorganize sections within "Software Management"
- Add information on nl80211 iw toolset


@ -353,6 +353,119 @@ tifm_core 6420 1 tifm_7xx1</programlisting>
<programlisting># <command>modprobe ipw2200</command></programlisting>
<para>One of the advantages of using modules is that you can pass on
additional options to a module, effectively changing its behavior. But
first some information on getting more information on modules.</para>
<para>An interesting command is <command>modinfo</command><indexterm>
</indexterm>, which displays information about a module. Although
its output might seem cryptic, it nevertheless gives some interesting
pointers to what options a module supports.</para>
<programlisting># <command>modinfo uvcvideo</command>
filename: /lib/modules/2.6.34/kernel/drivers/media/video/uvc/uvcvideo.ko
version: v0.1.0
license: GPL
description: USB Video Class driver
author: Laurent Pinchart &lt;;
srcversion: 6B23A0D849FE5EC0262441F
alias: usb:v*p*d*dc*dsc*dp*ic0Eisc01ip00*
alias: usb:v1C4Fp3000d*dc*dsc*dp*ic0Eisc01ip00*
vermagic: 2.6.34 SMP preempt mod_unload
parm: clock:Video buffers timestamp clock
parm: nodrop:Don't drop incomplete frames (uint)
parm: quirks:Forced device quirks (uint)
parm: trace:Trace level bitmask (uint)
parm: timeout:Streaming control requests timeout (uint)</programlisting>
<para>The above example shows that the uvcvideo module uses the GPL
license, is the USB Video Class driver, ... and supports parameters
clock, nodrop, quirks, trace and timeout. Of course, it does not give
you information what these parameters mean, but that is what you have
<ulink url="">Google</ulink> for, right?</para>
<para>Anyway, suppose you want to load the uvcvideo module with the
<parameter>nodrop=1</parameter> argument (you might be instructed to
do so from a bugreport or forum posting). You can do this using
<programlisting># <command>modprobe uvcvideo nodrop=1</command></programlisting>
<para>This does not make the option permanent though: when you reboot,
the module will be loaded in without this option. And repeatedly
rmmod'ing the module just to load it again with a parameter is quite
resource-intensive. The solution is to tell modprobe that a particular
option should be set by default. This can be accomplished by setting
the necessary directives in
</indexterm> or in a file inside the /etc/modprobe.d<indexterm>
</indexterm> directory. The latter is more often used: people or
projects create a file inside /<filename>etc/modprobe.d</filename>
named after the module itself, which makes management easier.</para>
<para>The content of <filename>/etc/modprobe.d/uvcvideo</filename> in
the previous example would then be:</para>
<programlisting>options uvcvideo nodrop=1</programlisting>
<title>Loading Modules</title>
<para>By default, Linux will load the modules you need for your
system. It relies on hardware detection (modern hardware always
exposes information about itself on a standardized manner) combined
with the drivers of the kernel modules, which describe for which
hardware they are made (and which other modules they require). What
happens then is that udev (we'll talk about udev in the next chapter)
gets informed by the Linux kernel about new hardware being detected.
Udev then triggers a modprobe for that hardware, and based on the
module information, modprobe knows which module to load.</para>
<para>The module information is generated by
</indexterm> when kernel modules are installed (copied) to a system.
That's a "nice-to-know" item, because it will happen transparently for
the user (you'll most likely never need to run
<command>depmod</command> yourself).</para>
<para>However, not all drivers know up-front which hardware they
support (some hardware doesn't expose this information) or they
collide with other drivers and, as a result, a system is configured
not to autoload any module for that hardware. When you are in such a
situation, you can still instruct your system to automatically load a
particular kernel module at boot time. All you need to do is add the
kernel module name to
<para>You can also ask your system not to automatically load a
particular module. To accomplish this, add the kernel module name as a
blacklist inside
</indexterm> or <filename>/etc/modprobe.d/blacklist.conf</filename>
(the name actually doesn't matter, the content does):</para>
<programlisting>blacklist uvcvideo</programlisting>
<para>Blacklisting a module doesn't mean that the module cannot be
loaded anymore. It means that the automated load, based on the
hardware information, is disabled. In other words, the link between a
hardware device id and the module is blacklisted. A manual
<command>modprobe</command> will still do the trick, and if the
hardware isn't managed by another module yet, then this module will
handle the hardware device.</para>
@ -2275,6 +2388,25 @@ Prompt: Initial RAM filesystem and RAM disk (initramfs/initrd) support
<programlisting># <command>mount /boot</command>
# <command>cp /usr/src/linux/arch/x86/boot/bzImage /boot/kernel-2.6.25-r2</command></programlisting>
<para>You can also use <command>make install</command> right after (or
before) the <command>make modules_install</command> step. This will copy
the kernel to <filename>/boot</filename>, calling it
<filename>/boot/vmlinuz</filename>, copying the previous kernel to
<filename>/boot/vmlinuz.old</filename>. If you rather have it not
overwrite kernels, you can also first create a symbolic link
<filename>/boot/vmlinuz</filename> pointing to the correct kernel (say
<filename>/boot/vmlinuz-2.6.25</filename>). A make install will then save
the new kernel (as a new file) and update the link instead, keeping the
old kernel image available for future use. I actually recommend to either
manually copy the kernel, or use the symbolic link approach.</para>
<para>To safely support make install, do the following steps only
<programlisting># <command>cp /usr/src/linux/arch/x86/boot/bzImage /boot/vmlinuz-2.6.25-r2</command>
# <command>cd /boot</command>
# <command>ln -s vmlinuz-2.6.25-r2 vmlinuz</command></programlisting>
<title>Rebuilding a Kernel</title>
@ -2429,6 +2561,19 @@ kernel /kernel-2.6.20 root=/dev/sda8</programlisting>
kernel doesn't work, I can restart the system and select the second
entry in the menu to boot the old kernel (which I know works) and
attempt to fix the configuration.</para>
<para>If you, right after the kernel compilation, used the make install
method for installing the kernel image, your Grub configuration file can
look (and stay) like so:</para>
<programlisting>default 0
timeout 5
title=Gentoo Linux
kernel /vmlinuz root=/dev/sda8</programlisting>
<para>In case the kernel fails to boot, you can execute the steps as
described in <xref linkend="rescue_kernel_boot_entry" />.</para>
@ -2465,8 +2610,8 @@ kernel /kernel-2.6.20 root=/dev/sda8</programlisting>
ones, well, they require a bit preparation in order to easily
troubleshoot and, eventually, solve.</para>
<title>Rescue Kernel Boot Entry</title>
<section id="rescue_kernel_boot_entry">
<title id="rescue_kernel_boot_entry">Rescue Kernel Boot Entry</title>
<para>Whenever you have a kernel that boots (regardless of the fact
that the kernel doesn't support your sound card or doesn't play 3D