API tools faq
paste
samuderapase

Debian Linux Kernel Handbook 

samuderapase
Dec 30th, 2011
206
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 57.11 KB | None | 0 0
raw download clone embed print report
  1. Debian Linux Kernel Handbook 
  2.  
  3. Copyright Notice
  4. Copyright © 2005-2011 Debian Kernel Handbook Project
  5. This handbook is free software; you may redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version.
  6. This is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.
  7. A copy of the GNU General Public License is available as /usr/share/common-licenses/GPL in the Debian GNU/Linux distribution or on the World Wide Web at the GNU General Public Licence. You can also obtain it by writing to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
  8.  
  9. Contents
  10. 1 About this handbook
  11. 1.1 Scope
  12. 1.2 Authors and Contributors
  13. 2 Debian kernel source
  14. 2.1 Changes to the pristine kernel source
  15. 2.2 Debian kernel patches
  16. 2.3 Policy for patch acceptance
  17. 3 Debian kernel packages
  18. 3.1 Source package
  19. 3.2 Architecture-independent packages
  20. 3.3 Architecture-dependent packages
  21. 4 Common kernel-related tasks
  22. 4.1 Obtaining the Debian kernel source
  23. 4.2 Rebuilding official Debian kernel packages
  24. 4.2.1 Preparation
  25. 4.2.2 Simple patching and building
  26. 4.2.3 Applying patches or configuration changes
  27. 4.2.4 Building many packages
  28. 4.2.5 Building packages for one flavour
  29. 4.3 Building a development version of the Debian kernel package
  30. 4.4 Generating orig tarball from newer upstream
  31. 4.5 Building a custom kernel from Debian kernel source
  32. 4.6 Building a custom kernel from the "pristine" kernel source
  33. 4.7 Building out-of-tree kernel modules
  34. 5 Version numbers and ABIs
  35. 5.1 The different types of version
  36. 5.2 The kernel ABI
  37. 5.2.1 The ABI name
  38. 5.2.2 Maintaining and updating the ABI
  39. 6 Managing the kernel modules
  40. 7 Managing the initial ramfs (initramfs) archive
  41. 7.1 Initramfs generation tools
  42. 7.2 Regenerating the initramfs
  43. 7.3 Examining the initramfs contents
  44. 8 Package maintainer scripts and hooks
  45. 8.1 Kernel hooks
  46. 8.2 Kernel hooks required for boot loaders
  47. 8.3 Initramfs hooks
  48. 8.4 Kernel hooks required for initramfs builders
  49. 8.5 Optimising boot loader updates
  50. 8.6 Deprecated features
  51. 8.7 Initial configuration by the installer
  52. 9 Reporting and handling bugs
  53. 9.1 Bug handling policy for the kernel team
  54. 9.1.1 Required information
  55. 9.1.2 Severities
  56. 9.1.3 Tagging
  57. 9.1.4 Analysis by maintainers
  58. 9.1.5 Testing by submitter
  59. 9.1.6 Keeping bugs separate
  60. 9.1.7 Applying patches
  61. 9.1.8 Talking to submitters
  62. 9.2 Filing a bug against a kernel package
  63.  
  64. [ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]
  65.  
  66. Debian Linux Kernel Handbook
  67. version 1.0.12, Wed Sep 28 15:38:16 BST 2011
  68.  
  69. The Debian Kernel Handbook Project
  70.  
  71.  
  72. [ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]
  73.  
  74. Debian Linux Kernel Handbook 
  75. Chapter 1 - About this handbook
  76.  
  77. 1.1 Scope
  78. The main goal of this handbook is to serve as a single access point to all kernel-related documentation. It contains the information about the Debian packaging of Linux kernel for the Lenny release of Debian (version 5.0). The latest released version is always available from http://kernel-handbook.alioth.debian.org. Note that this is a work in progress, and some information is inaccurate.
  79. Some of the commands mentioned in the text must be executed with superuser priviliges, either by becoming the root user or by using sudo. To distinguish between commands which may be executed by an unprivileged user and those requiring superuser privileges, commands are prepended by $ or # respectively. This symbol is not a part of the command.
  80.  
  81. 1.2 Authors and Contributors
  82. This handbook is maintained within the kernel-handbook project on Alioth. The SGML source of the book may be checked out from the Debian git repository. It is intended as a community project, thus all proposals for improvements and contributions are welcome. The preferred way to submit a contribution is to send it to the [email protected] mailing list. When submitting a contribution please clearly identify its copyright holder and include the licensing statement. Note that to be accepted the contribution must be licensed under the same license as the rest of the document, namely GPL version 2 or later. Below is the list of current contributors:
  83. Jurij Smakov
  84. Sven Luther
  85. Andres Salomon
  86. Maximilian Attems
  87. Ben Hutchings
  88.  
  89. [ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]
  90.  
  91. Debian Linux Kernel Handbook
  92. version 1.0.12, Wed Sep 28 15:38:16 BST 2011
  93.  
  94. The Debian Kernel Handbook Project
  95.  
  96.  
  97.  
  98.  
  99. Debian Linux Kernel Handbook 
  100. Chapter 3 - Debian kernel packages
  101.  
  102. 3.1 Source package
  103. To ensure that the latest kernel version, containing all the essential bug and security fixes is available on as many architectures as possible, starting with 2.6.12 the kernel team introduced a new packaging scheme. In it most of the kernel-related binary packages are built from a single source package linux-2.6. The linux-2.6 source package supports building of kernel images and headers for all currently supported architectures. Subsequent sections of this chapter document the naming and contents of the binary packages built from the linux-2.6 source package.
  104.  
  105. 3.2 Architecture-independent packages
  106. linux-source-version
  107. This package contains the Debian kernel source tarball. The patchlevel of the source is determined by the Debian revision of the package, for example the version 2.6.26-2 of the package linux-source-2.6.26contains the version 2.6.26 of the Debian kernel source patched to patchlevel 2. Once the package is installed, the source tarball is available at /usr/src/linux-source-version.tar.bz2. For the instructions on obtaining Debian kernel source with arbitrary patchlevel, see Obtaining the Debian kernel source, Section 4.1.
  108. linux-manual-version
  109. This package contains the manual pages for the functions, constituting the kernel API. These pages are installed into /usr/share/man/man9/, and are accessible with the standard man command. Due to filename conflicts, only one linux-manual package may be installed at any given time.
  110. linux-doc-version
  111. This package contains the rest of the kernel documentation in various formats. It is installed in /usr/share/doc/linux-doc-version.
  112. linux-patch-debian-version
  113. This package contains all patches used to produce the Debian kernel source. It also contains the scripts which allow application or un-application of patchsets, bringing the source to the desired patchlevel. After the installation the patches are installed in /usr/src as follows:
  114. /usr/src/kernel-patches/all/version/debian/
  115. This directory contains the hierarchy of subdirectories with individual compressed patch files for a given version. Subdirectories indicate source or purpose of the patches contained within it, like bugfix(essential bugfixes), debian (Debian-specific patches) or features (kernel features not yet merged upstream). Within these directories patches are further subdivided by architecture.
  116. /usr/src/kernel-patches/all/version/debian/series/
  117. This directory contains the control files, which determine which patches need to be applied (or unapplied) to move from one patchlevel to another. These are text files named N (or N-extra), where N is the number specifiying the patchlevel. The file N contains a list of patches which need to be applied (in case when the name of the patch prepended with plus) or unapplied (if it is prepended with a minus) to move from patchlevel N-1 to patchlevel N. For example, the file 1 lists the patches which need to be applied to go from the original Debian kernel source to the patchlevel 1. Files named N-extra list the architecture-specific patches, along with the architectures they apply to. There is also a special file orig-0, which lists the patches (scripts) which were applied (run) in order to obtain the Debian kernel source from upstream kernel source (by removing the parts incompatible with DFSG). Invocation of a script is identified by X in the first column in this file.
  118. /usr/src/kernel-patches/all/version/apply/debian
  119. This script may be used to change the patchlevel of the currently available source tree, when run from its top-level directory. For usage example see Obtaining the Debian kernel source, Section 4.1. Current patchlevel of the source tree is stored in the version.Debian file in the top-level directory, and script modifies it appropriately when switching from one patchlevel to another. You can specify patchlevel origto remove all Debian-specific patches, rolling back to the original Debian kernel source (differing from upstream by removal of firmware and other problematic files, as well as changes required for the resulting kernel to be buildable). Note that there is currently a bug in the script, preventing rollbacks of more than one patchlevel. For example, if your tree is currently at patchlevel 2, a command
  120. $ /usr/src/kernel-patches/all/2.6.26/apply/debian orig
  121. is likely to fail, so use commands
  122. $ /usr/src/kernel-patches/all/2.6.26/apply/debian 1
  123. $ /usr/src/kernel-patches/all/2.6.26/apply/debian orig
  124. i.e. switch the levels one by one instead.
  125. /usr/src/kernel-patches/all/version/unpatch/debian
  126. This script brings the tree to the orig patchlevel (equivalent to running /usr/src/kernel-patches/all/version/apply/debian orig). See previous sections for discussion.
  127. linux-tree-version
  128. This is a dummy package whose sole purpose is to satisfy the build dependencies for a successful kernel build. In the old kernel build system build-depending on the package linux-tree-version-N, provided by the linux-tree-version, would result in the automatic installation of all the required source and patch packages, and patching of the kernel source to patchlevel N before building. It has been obsoleted by the new common packaging system and is provided for backward compatibility only.
  129. linux-support-version-abiname
  130. This package contains the support files for building of out-of-tree modules for given version and abiname.
  131.  
  132. 3.3 Architecture-dependent packages
  133. The kind of hardware the particular kernel package is designed for is uniquely identified by the architecture, featureset, and flavour. Kernels for all architectures are built from the same Debian kernel source tree, which is obtained using the procedure described in Debian kernel source, Chapter 2. Each architecture usually has multiple flavours of the binary kernel images. Different flavours correspond to different kernel configuration files, used to build the binary images from the same kernel tree.
  134. In order to build a working kernel with an extra featureset not provided by the upstream source, additional changes to the Debian kernel source are required. Again, multiple flavours of binary images may be built from the featureset tree. For example, the i386 architecture has a number of different flavours, such as 486, 686 and 686-bigmem, built from the common Debian kernel source. It also contains xen and openvz featuresets. The source tree for building the kernels for each of these featuresets is obtained by applying additional patches to the Debian kernel source. It may be used to build the xen-686 and openvz-686 binary image flavours. The names of the Debian binary packages incorporate the name of the flavour and, if necessary, the name of the featureset (there is no need to worry about the name of the architecture, since Debian tools will only allow installation of the packages with "correct" architecture). If the arch does not have any featuresets, the featureset part is omitted from the name, as indicated by the square brackets below.
  135. Package names also include the abiname, a small integer, which identifies the kernel's binary compatibility level. The kernels with different abinames are binary incompatible, so upgrading to a kernel with a different abiname will most likely require recompilation of third-party binary modules against the new kernel. The list of architecture-dependent packages together with a short description is given below.
  136. linux-headers-version-abiname-common[-featureset]
  137. This package contains a common set of kernel headers for a particular featureset (or arch, if featureset is empty). Together with the flavour-specific linux-headers package it provides a full set of kernel headers, suitable for building of out-of-tree modules. This package should not normally be installed directly, but only as a dependency of the flavour-specific headers package (see next description). It unpacks into the/usr/src/linux-headers-version-abiname-common[-featureset] directory.
  138. linux-headers-version-abiname[-featureset]-flavour
  139. This package provides flavour-specific header files. It depends on the corresponding linux-headers-version-abiname-common[-featureset] package, and sets up symbolic links into its directory tree in such a way that the directory /usr/src/linux-headers-version-abiname[-featureset]-flavour appears to contain a full set of headers, required for building of out-of-tree kernel modules. For more information on this check out Building out-of-tree kernel modules, Section 4.7. A complete set of kernel headers matching the currently running official kernel may be installed with a command
  140. apt-get install linux-headers-$(uname -r)
  141. linux-image[-featureset]-flavour
  142. This is a virtual package, providing (via dependencies) the latest binary image for a particular flavour. Example: linux-image-openvz-686.
  143. linux-image-2.6[-featureset]-flavour
  144. linux-headers-2.6[-featureset]-flavour
  145. These virtual packages provide (via dependencies) the latest 2.6 series binary image and matching set of header files (respectively) for a particular flavour. Example: linux-image-2.6-openvz-686
  146. linux-image-version-abiname[-featureset]-flavour
  147. This package contains the binary kernel image and pre-built binary modules for a particular arch/featureset/flavour combination. Names of the files installed by this package are architecture-dependent. Typical locations of essential files for the i386 architecture are:
  148. /boot/vmlinuz-version-abiname[-featureset]-flavour
  149. The binary (compressed) kernel image.
  150. /boot/initrd.img-version-abiname[-featureset]-flavour
  151. Initial RAM filesystem (initramfs) image. Note, that this file is automatically generated in the installation process and is not shipped as a part of the package. See Managing the initial ramfs (initramfs) archive, Chapter 7 for more details.
  152. /boot/config-version-abiname[-featureset]-flavour
  153. The kernel configuration file used to build this particular kernel. May be used to rebuild the kernel from source, if necessary.
  154. /lib/modules/version-abiname[-featureset]-flavour/
  155. Directory containing the pre-built binary kernel modules.
  156. linux-libc-dev
  157. This package provides Linux kernel headers for use by userspace programs, such as GNU glibc and other system libraries.
  158.  
  159. [ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]
  160.  
  161. Debian Linux Kernel Handbook
  162. version 1.0.12, Wed Sep 28 15:38:16 BST 2011
  163.  
  164. The Debian Kernel Handbook Project
  165.  
  166.  
  167. [ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]
  168.  
  169. Debian Linux Kernel Handbook 
  170. Chapter 4 - Common kernel-related tasks
  171.  
  172. 4.1 Obtaining the Debian kernel source
  173. To get the Debian kernel source at the current maximum patchlevel, it is sufficient to install the latest linux-source-version package and unpack the source, for example:
  174. # apt-get install linux-source-2.6.18
  175. $ tar jxf /usr/src/linux-source-2.6.18.tar.bz2
  176. The unpacked source tree then will be available in linux-source-2.6.18 directory.
  177. In order to get the Debian kernel source at a patchlevel different from the one provided by the current linux-source-version package, one should first install and unpack it, then roll back the unneeded patch sets using a script from the linux-patch-debian-version package. In the steps mentioned in the previous example we assume that version 2.6.18-8 of the linux-source-2.6.18 package was installed and unpacked, so that the Debian kernel source at patchlevel 8 is available in the linux-source-2.6.18 directory. It can then be rolled back to the desired patchlevel (1 in the example below) by running
  178. # apt-get install linux-patch-debian-2.6.18
  179. $ cd linux-source-2.6.18
  180. $ /usr/src/kernel-patches/all/2.6.18/apply/debian 2.6.18-1
  181. The last command will unapply the set of patches, which lead from patchlevel 1 to patchlevel 8 and the resulting tree will appear as if it came from the version 2.6.18-1 of the linux-source-2.6.18 package. This system ensures that the source code for any revision of the Debian kernel source may be recovered from the latest one, without keeping multiple copies of the source in the archive.
  182. The linux-patch-debian-version package contains all the individual patches applied to the source to achieve any patchlevel up to N (e.g. patch level 8 for 2.6.18-8). They are stored in the directory/usr/src/kernel-patches/all/version/debian/.
  183.  
  184. 4.2 Rebuilding official Debian kernel packages
  185. You can build all or selected kernel packages by following these instructions. You may be asked to do this in order to test a potential bug fix.
  186.  
  187. 4.2.1 Preparation
  188. Run the following commands:
  189. $ apt-get source linux-2.6
  190. This will download and unpack the linux-2.6 source package, making the tree available in the linux-2.6-version directory. As always, the revision part of the version of this package (for example, 8 in 2.6.18-8) will determine its patchlevel with respect to the original upstream kernel source.
  191. # apt-get install build-essential fakeroot
  192. # apt-get build-dep linux-2.6
  193. The last two commands will install the build dependencies required by the kernel build process.
  194. $ cd linux-2.6-version
  195. Enter the source directory.
  196.  
  197. 4.2.2 Simple patching and building
  198. Starting from version 2.6.32-6, the source package includes a script to simplify the process of building with extra patches. You can use this by running commands such as:
  199. # apt-get install devscripts
  200. $ bash debian/bin/test-patches ../fix-bug123456.patch ../add-foo-driver.patch
  201. This script has options to control the flavour, featureset, etc. For a summary of the options, run:
  202. $ bash debian/bin/test-patches
  203. You may then need to build the linux-base package as well:
  204. $ fakeroot make -f debian/rules.real install-linux-base
  205. However, if you need to change the configuration or make other changes, you should not use this script and should follow the instructions below.
  206.  
  207. 4.2.3 Applying patches or configuration changes
  208. It is possible to apply extra patches to the source before starting the build. First, you should apply the existing patches by running:
  209. $ fakeroot debian/rules source
  210. You will then find the patched source in the subdirectories debian/build/source_arch_none (default) and debian/build/source_arch_featureset (featuresets added). You should apply the extra patches in the appropriate subdirectory.
  211. To change the configuration before building, for example for the 686-bigmem flavour on i386, run the commands:
  212. $ fakeroot make -f debian/rules.gen setup_i386_none_686-bigmem
  213. $ make -C debian/build/build_i386_none_686-bigmem menuconfig
  214. If the patches or configuration changes alter type definitions for the kernel, you may need to change the ABI name; see The ABI name, Section 5.2.1.
  215.  
  216. 4.2.4 Building many packages
  217. To build all possible packages for this architecture, run:
  218. $ fakeroot debian/rules binary
  219. To build all architecture-dependent packages, run:
  220. $ fakeroot debian/rules binary-arch
  221. To build all architecture-independent packages, run:
  222. $ fakeroot debian/rules binary-indep
  223.  
  224. 4.2.5 Building packages for one flavour
  225. For example, to build only the binary packages for 686 flavour on i386 architecture, use the following commands:
  226. $ fakeroot debian/rules source
  227. $ fakeroot make -f debian/rules.gen binary-arch_i386_none_686
  228. The target in this command has the general form of target_arch_featureset_flavour. Replace the featureset with none if you do not want any of the extra featuresets. This command will build the linux image and kernel headers packages. You may also need the linux-headers-version-common binary package, which can be built using the commands:
  229. $ fakeroot debian/rules source
  230. $ fakeroot make -f debian/rules.gen binary-arch_i386_none_real
  231. The target in this command has the general form of target_arch_featureset_real
  232.  
  233. 4.3 Building a development version of the Debian kernel package
  234. To build a kernel image based on the kernel team's unreleased development version:
  235. # apt-get install build-essential fakeroot rsync svn
  236. # apt-get build-dep linux-2.6
  237. The last two commands will install the build dependencies required by the kernel build process.
  238. $ svn co svn://anonscm.debian.org/svn/kernel/dists/dist/linux-2.6
  239. This will check out the Debian packaging. dist is normally the distribution codename such as wheezy or sid (unstable). For the very latest version, usually based on an upstream release candidate, use trunk.
  240. $ apt-get source -d linux-2.6
  241. This will download the linux-2.6 upstream source (and the last released Debian patches). Depending on which version you are trying to build, you might need to override APT's version selection or download a tarball from people.debian.org instead.
  242. $ cd linux-2.6
  243. $ debian/rules orig
  244. This unpacks the upstream source and merges it with the Debian packaging.
  245. $ debian/rules debian/control
  246. This generates a Debian package control file based on the current definitions of the various kernel flavours which can be built.
  247. $ fakeroot debian/rules target
  248. Finally, build binary packages as explained in Rebuilding official Debian kernel packages, Section 4.2.
  249.  
  250. 4.4 Generating orig tarball from newer upstream
  251. First you must add a changelog entry for the new upstream version. If the new version is a release candidate, change the string -rc to ~rc. (In Debian package versions, a suffix beginning with ~ indicates a pre-release.)
  252. The 'orig' tarball is generated by the genorig.py script. It takes either a tarball and optional patch from kernel.org, or a git repository. If you have a tarball, run a command such as:
  253. $ python debian/bin/genorig.py ../linux-2.6.20.tar.bz2 ../patch-2.6.21-rc6.bz2
  254. If you have a git repository, pass the name of its directory:
  255. $ python debian/bin/genorig.py ~/src/linux-2.6
  256. Either of these will generate a file such as ../orig/linux-2.6_2.6.21~rc6.orig.tar.gz. You can then combine this tarball with the Debian packaging by running:
  257. $ debian/rules orig
  258.  
  259. 4.5 Building a custom kernel from Debian kernel source
  260. This section describes the simplest possible procedure to build a custom kernel the "Debian way". It is assumed that user is somewhat familiar with kernel configuration and build process. If that's not the case, it is recommended to consult the kernel documentation and many excellent online resources dedicated to it.
  261. The easiest way to build a custom kernel (the kernel with the configuration different from the one used in the official packages) from the Debian kernel source is to use the linux-source package and the make deb-pkgtarget. First, prepare the kernel tree:
  262. # apt-get install linux-source-2.6.18
  263. $ tar xjf /usr/src/linux-source-2.6.18.tar.bz2
  264. $ cd linux-source-2.6.18
  265. The kernel now needs to be configured, that is you have to set the kernel options and select the drivers which are going to be included, either as built-in, or as external modules. The kernel build infrastructure offers a number of targets, which invoke different configuration frontends. For example, one can use console-based menu configuration by invoking the command
  266. $ make menuconfig
  267. Instead of menuconfig one can use config (text-based line-by-line configuration frontend) or xconfig (graphical configuration frontend). It is also possible to reuse your old configuration file by placing it as a .configfile in the top-level directory and running one of the configuration targets (if you want to adjust something) or make oldconfig (to keep the same configuration). Note that different frontends may require different additional libraries and utilities to be installed to function properly. For example, the menuconfig frontend requires the ncurses library, which at time of writing is provided by the libncurses5-dev package.
  268. After the configuration process is finished, the new or updated kernel configuration will be stored in .config file in the top-level directory. The build is started using the commands
  269. $ make clean
  270. $ make KDEB_PKGVERSION=custom.1.0 deb-pkg
  271. The custom.1.0 part in this command is the version identifier, which will get appended to the kernel package name. Feel free to adjust it to your liking. As a result of the build, a custom kernel package linux-image-2.6.18_custom.1.0_i386.deb (name will reflect the version of the kernel and the revision chosen in the command line above) will be created in the directory one level above the top of the tree. It may be installed usingdpkg just as any other package:
  272.  
  273. # dpkg -i ../linux-image-2.6.18_custom.1.0_i386.deb
  274. This command will unpack the kernel, generate the initrd if necessary (see Managing the initial ramfs (initramfs) archive, Chapter 7 for details), and configure the bootloader to make the newly installed kernel the default one. If this command completed without any problems, you can reboot using the
  275. # shutdown -r now
  276. command to boot the new kernel.
  277. For much more information about bootloaders and their configuration please check their documentation, which can be accessed using the commands man lilo, man lilo.conf, man grub, and so on. You can also look for documentation in the /usr/share/doc/package directories, with package being the name of the package involved.
  278.  
  279. 4.6 Building a custom kernel from the "pristine" kernel source
  280. Building a kernel from the "pristine" (also sometimes called "vanilla") kernel source, distributed from www.kernel.org and its mirrors, may be occasionally useful for debugging or in the situations when a newer kernel version is desired. The procedure differs only in obtaining the kernel source: instead of unpacking the kernel source from Debian packages, the "pristine" source is downloaded using your favourite browser or using wget, as follows:
  281.  
  282. $ wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.19.tar.bz2
  283. The integrity of the downloaded archive may be verified by fetching the corresponding cryptographic signature
  284.  
  285. $ wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.19.tar.bz2.sign
  286. and running this command (gnupg package must be installed):
  287. $ gpg --verify linux-2.6.19.tar.bz2.sign
  288. Successful verification results in output similar to the one below:
  289. gpg: Signature made Wed 29 Nov 2006 02:50:07 PM PST using DSA key ID 517D0F0E
  290. gpg: Good signature from "Linux Kernel Archives Verification Key <[email protected]>"
  291. gpg: WARNING: This key is not certified with a trusted signature!
  292. gpg: There is no indication that the signature belongs to the owner.
  293. Primary key fingerprint: C75D C40A 11D7 AF88 9981 ED5B C86B A06A 517D 0F0E
  294. After that the archive may be unpacked using
  295. $ tar xjf linux-2.6.19.tar.bz2
  296. $ cd linux-2.6.19
  297. The unpacked kernel tree (in linux-2.6.19 now has to be configured. The existing configuration file may be used as a starting point
  298. $ cp /boot/config-2.6.18-3-686 ./.config
  299. After the configuration with one of the configuration frontends (invoked by make oldconfig, make config, make menuconfig, etc) is completed, the build may be started using make deb-pkg target as described above.
  300.  
  301. 4.7 Building out-of-tree kernel modules
  302. Some kernel modules are not included in the upstream or Debian kernel source, but are provided as third-party source packages. For some of the most popular out-of-tree modules, the binary Debian packages with modules built against the stock Debian kernels are provided. For example, if you are running stock Debian kernel 2.6.18-3-686 (use the uname -r command to verify the version) from the linux-image-2.6.18-3-686 package, and would like to use the squash filesystem, all you need to do is install squashfs-modules-2.6.18-3-686 binary package, which provides the neccessary binary kernel modules.
  303. If you are not so lucky, and there are no binary module packages in the archive, there is a fair chance that the Debian archive contains the packaged source for the kernel modules. Names of such packages typically end in -source, for example squashfs-source, thinkpad-source, rt2x00-source and many others. These packages contain debianized source code of the kernel modules, suitable for building using the module-assistant (or m-a) script from the module-assistant package. Typical sequence to build a custom binary module package, matching a kernel 2.6.18-3-686 (as returned by uname -r) from the debianized source consists of the following steps:
  304. Install a set of kernel headers, matching the kernel for which the modules are going to be built:
  305. # apt-get install linux-headers-2.6.18-3-686
  306. Install the package containing the source:
  307. # apt-get install squashfs-source
  308. Invoke module-assistant (aka m-a) to do the heavy lifting:
  309. # m-a build squashfs
  310. As a result, a Debian package is going to be built and placed in /usr/src. It can be installed the usual way, using dpkg -i. Two last steps (building and installation) may be combined using the invocation
  311. # m-a auto-install squashfs
  312. Check out the module-assistant documentation (man module-assistant) for other options and much more information on how to use it.
  313. Finally, in some rare circumstances, you might need to build the kernel modules from the upstream source packages. In that case, follow the documentation included with the package to build the modules. If the build process will require you to specify the directory with the kernel headers, matching the currently running kernel, for stock Debian kernels this directory is /usr/src/linux-headers-uname, provided by the linux-headers-uname package. Here uname is the output of the uname -r command. If you are building and running your own custom kernels, it is a good idea to keep the original build tree around, as it also can be used for out-of-tree module building.
  314.  
  315. [ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]
  316.  
  317. Debian Linux Kernel Handbook
  318. version 1.0.12, Wed Sep 28 15:38:16 BST 2011
  319.  
  320. The Debian Kernel Handbook Project
  321.  
  322.  
  323. [ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]
  324.  
  325. Debian Linux Kernel Handbook 
  326. Chapter 5 - Version numbers and ABIs
  327.  
  328. 5.1 The different types of version
  329. Upstream version
  330. The version that Linus or a stable series maintainer uses for a release. Currently Linus will use the version format: 3.x[-rcy]. Stable series maintainers use the version format: 3.x.y.
  331. Package version
  332. The version used in a Debian package. Following Debian policy, it should follow the format upstreamversion-debianrevision. However, for an upstream release candidate, the string '-rc' must be replaced with '~rc' so that it will be recognised as an earlier version than the following release.
  333. Kernel version
  334. This is the version that appears in kernel messages, filenames, package names and the output of 'uname -r'. In official kernel packages it follows the format upstreamversion[-abiname][-featureset]-flavour. It is not changed for every new package version. The abiname is changed as explained below.
  335. Many programs parse the kernel version string reported by the uname system call or command and expect to find at least 3 version components separated by dots. For compatibility, the official kernel packages currently add '.0' to the upstream version.
  336.  
  337. 5.2 The kernel ABI
  338. An ABI (Application Binary Interface) is an interface between two software components, considered at the level of register allocation and memory layout. The ABI between the kernel and user-space is generally maintained carefully, and is not a concern here. However, the ABI between the kernel and its modules is not. In order to support out-of-tree modules, the kernel version should be changed when the ABI between the kernel and modules changes.
  339.  
  340. 5.2.1 The ABI name
  341. In official kernel packages, we change the abiname part of the kernel version to mark ABI changes that aren't due to a new upstream version. This part comes from the abiname setting in debian/config/defines. We use either a number or 'trunk' (for experimental), but for a custom package it should be some other string.
  342.  
  343. 5.2.2 Maintaining and updating the ABI
  344. In order to avoid the need for users to rebuild out-of-tree modules frequently, we try to avoid changing the kernel ABI during updates to a Debian stable or oldstable release. Most importantly, we avoid making such changes without changing the ABI name, except where it appears that out-of-tree modules do not depend on that part of the ABI.
  345. Bug fixes or configuration changes to the kernel may alter the ABI. If an exported function is conditional on CONFIG_FOO, or it uses a type whose definition depends on CONFIG_FOO, then turning CONFIG_FOO on or off changes the ABI of that function, and thus of the kernel as a whole. Enabling or changing the configuration of a single driver usually doesn't change the ABI, because most drivers don't export anything.
  346. The kernel build process generates a 'symbol version' for each exported function or variable. This is a hash of the definitions that it depends on, and should change whenever the function's ABI changes. The kernel module loader detects incompatible modules by comparing symbol versions. The whole set of symbol versions represents the kernel ABI.
  347. We collect the symbol versions for previously uploaded packages under the directory debian/abi and then compare the new kernel with those. If the ABI name is unchanged but the ABI itself is changed - except for additions, or changes that we have marked as acceptable - then the build is aborted.
  348. If the kernel ABI has changed you must then change the ABI name in debian/config/defines. Then run the command
  349. $ fakeroot debian/rules debian/control-real
  350. to regenerate the package definitions for this ABI name.
  351.  
  352. [ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]
  353.  
  354. Debian Linux Kernel Handbook
  355. version 1.0.12, Wed Sep 28 15:38:16 BST 2011
  356.  
  357. The Debian Kernel Handbook Project
  358.  
  359.  
  360. [ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]
  361.  
  362. Debian Linux Kernel Handbook 
  363. Chapter 6 - Managing the kernel modules
  364.  
  365. Linux device drivers come in the form of kernel modules - object files which may be loaded into the running kernel to extend its functionality. The list of currently loaded kernel modules can be obtained using the lsmodcommand, modules may be loaded using modprobe, and removed using modprobe -r. The depmod command may be used to regenerate the list of available modules (after installation of the new modules, for example), even though it is pretty unlikely that you will ever need to invoke it by hand.
  366. Normally, the devices are detected and neccessary kernel modules are loaded by udev during boot time. Occasionally, one may need finer control over the loading of kernel modules, for example to pass the additional parameters to the module, force loading of some modules on startup, or prevent certain module(s) from being loaded.
  367. If some modules are not loaded automatically by udev, but you would like them to be loaded during boot, it is possible to force it by listing the names of the modules in one of the files
  368. /etc/modules-version
  369. /etc/modules-major
  370. /etc/modules
  371. where version and major are the kernel version as returned by uname -r (like 2.6.18-3-686) and the major part of the kernel version (like 2.6), respectively. The initialization script will look for these files, matching the version and major part for the running kernel, in the order listed. The first file found will be scanned for the names of the modules (one name per line), which will then be loaded using modprobe. You can also specify the arguments for the modules. For example, a typical /etc/modules might look like that
  372. loop max_int=32
  373. sbp2
  374. To find out what parameters are accepted by a given module, you can use the modinfo command, for example:
  375. # modinfo loop
  376. filename: /lib/modules/2.6.18-3-686/kernel/drivers/block/loop.ko
  377. license: GPL
  378. alias: block-major-7-*
  379. vermagic: 2.6.18-3-686 SMP mod_unload 686 REGPARM gcc-4.1
  380. depends:
  381. parm: max_loop:Maximum number of loop devices (1-256) (int)
  382. To add custom arguments to the modules loaded by udev early in the boot process, you need to create a custom configuration file for modprobe, which udev uses to load the modules. For example, to pass anatapi_enabled=1 argument to the libata kernel module, create /etc/modprobe.d/local file with a following line:
  383. options libata atapi_enabled=1
  384. You can choose arbitrary names for the configuration files in /etc/modprobe.d and put multiple options lines in the same file.
  385. Sometimes two different modules claim support for the same device, usually because two slightly different versions of the device exist, requiring different kernel modules to operate. In such situation udev loads both kernel modules, with unpredictable results. To avoid this problem, you can prevent any module (let's say, tulip) from loading by creating an arbitrarily named file, containing a line
  386. blacklist tulip
  387. in /etc/modprobe.d directory. See the modprobe manual page (man modprobe) for much more information on configuring and using modprobe.
  388.  
  389. [ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]
  390.  
  391. Debian Linux Kernel Handbook
  392. version 1.0.12, Wed Sep 28 15:38:16 BST 2011
  393.  
  394. The Debian Kernel Handbook Project
  395.  
  396.  
  397. [ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]
  398.  
  399. Debian Linux Kernel Handbook 
  400. Chapter 7 - Managing the initial ramfs (initramfs) archive
  401.  
  402. The booting in Debian is a two-stage process, involving the initial RAM filesystem (initramfs for short, sometimes it is also referred to as initrd, which stands for initial RAM disk). First, the bootloader loads the kernel and initramfs into memory, and passes the execution control to the kernel. After basic initialization the kernel extracts the initramfs archive and mounts it as a temporary root filesystem. initramfs contains kernel modules and userspace programs required to initialize the physical or logical device(s) containing the real root filesystem. The init script on the initramfs loads modules and performs other neccessary initialization steps. At the end of this stage run-init deletes the initramfs from memory, mounts the real root filesystem and passes control to the /sbin/init program on it.
  403. Two major goals are achieved with such setup: the kernel size is kept under control by allowing most of the drivers to be compiled as modules (in a initramfs-less setup the drivers neccessary for the boot-time initialization of the root device must be compiled into it) and allow the setups which require initialization which cannot be done in-kernel, but is performed by userspace utilities.
  404.  
  405. 7.1 Initramfs generation tools
  406. Since initramfs usually needs to be customized for the particular hardware/device configuration and kernel version, they are not included as a part of any package, but are generated on the fly at kernel installation time. Currently there are two tools in Debian capable of generating an initramfs: update-initramfs provided by initramfs-tools (default) and dracut-update-initramfs provided by the dracut package (experimental).
  407.  
  408. 7.2 Regenerating the initramfs
  409. If changes are desired after the corresponding linux-image has been installed, the initramfs needs to be regenerated. This is achieved by the command
  410. # dpkg-reconfigure linux-image-2.6.18-3-686
  411. where linux-image-2.6.18-3-686 is the name of the kernel package for which the initramfs regeneration is requested.
  412.  
  413. 7.3 Examining the initramfs contents
  414. Occasionally it is useful to examine the contents of initramfs to diagnose a problem or for educational purposes. They are compressed cpio archives, which may be extracted using the command
  415. $ zcat /boot/initrd.img-2.6.18-3-686 | cpio -i
  416. It will unpack the contents of the initramfs into the current directory.
  417.  
  418. [ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]
  419.  
  420. Debian Linux Kernel Handbook
  421. version 1.0.12, Wed Sep 28 15:38:16 BST 2011
  422.  
  423. The Debian Kernel Handbook Project
  424.  
  425.  
  426. [ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]
  427.  
  428. Debian Linux Kernel Handbook 
  429. Chapter 8 - Package maintainer scripts and hooks
  430.  
  431. Kernel packages for Debian have historically had complex maintainer scripts which can invoke the initramfs builder and/or a boot loader, based on a mixture of file tests, explicit configuration through the file /etc/kernel-img.conf and debconf questions. Starting with Debian 6.0, this will be greatly simplified.
  432. The following policy applies to Debian GNU/Linux 6.0 'squeeze' and later releases. Some parts may be applicable to kernels other than Linux, but this policy does not set any requirements for them.
  433.  
  434. 8.1 Kernel hooks
  435. The maintainer scripts in Linux kernel packages must use run-parts to invoke hook scripts in the corresponding subdirectory of /etc/kernel, e.g. the postinst script must invoke scripts in/etc/kernel/postinst.d.
  436. The arguments given to all kernel hook scripts are the kernel ABI version (the string that uname -r reports) and, optionally, the absolute path to the kernel image. If the second argument is missing then the path is either/boot/vmlinuz-version or /boot/vmlinux-version, according to architecture convention. The environment variable DEB_MAINT_PARAMS will contain the arguments given to the kernel maintainer script, possibly single-quoted. In a shell script, this variable can be parsed using:
  437. eval set -- "$DEB_MAINT_PARAMS"
  438. Kernel hook scripts may be run under debconf. In this case they must not use stdin and stdout, and should send all output to stderr (fd 2). A shell script can ensure that it does this using:
  439. exec </dev/null >&2
  440.  
  441. 8.2 Kernel hooks required for boot loaders
  442. Packages for boot loaders that need to be updated whenever the files they load are modified (i.e. those that store a block list) must install hook scripts in /etc/kernel/postinst.d and /etc/kernel/postrm.d.
  443. Since these boot loaders should be updated as the last step during installation/upgrade and removal, hook scripts for boot loaders must be named using the prefix zz- and no other packages may use this prefix or one that sorts later by the rules used by run-parts. A postrm hook script should warn but exit with code 0 if the boot loader configuration file still refers to the kernel image that has been removed.
  444. These boot loader packages must be installable on the filesystem in a disabled state where they will not write to the boot sector or other special storage. While a boot loader is disabled, any kernel hooks it includes must do nothing except (optionally) printing a warning that the boot loader is disabled, and must exit successfully.
  445. Packages for boot loaders that can provide a menu of kernel versions should install kernel hook scripts in order to update that menu.
  446.  
  447. 8.3 Initramfs hooks
  448. Packages for boot loaders that need to be updated whenever the files they load are modified must also install hook scripts in /etc/initramfs/post-update.d. Initramfs builders must call these scripts using run-partsafter they create, update or delete an initramfs. The arguments given to these hook scripts are the kernel ABI version and the absolute path to the initramfs image.
  449. While a boot loader is disabled, any initramfs hook it includes must do nothing except (optionally) printing a warning that the boot loader is disabled, and must exit successfully.
  450.  
  451. 8.4 Kernel hooks required for initramfs builders
  452. Initramfs builders must install hook scripts in /etc/kernel/postinst.d and /etc/kernel/postrm.d, to create/update and delete the corresponding initramfs images. The postinst hook script must complete its work before returning. [initramfs-tools currently uses a trigger to defer this because it may be invoked twice, but this means it also has to know how to update specific boot loaders. This new requirement will allow boot loader packages to avoid unnecessary updates, as described in the following section.]
  453.  
  454. 8.5 Optimising boot loader updates
  455. During a kernel package installation, upgrade or removal, various boot loader hooks may be invoked (in this order):
  456. 1. A postinst_hook or postrm_hook command set by the user or the installer in /etc/kernel-img.conf
  457. 2. A hook script in /etc/initramfs/post-update.d
  458. 3. A hook script in /etc/kernel/postinst.d or .../postrm.d
  459. To avoid unnecessary updates, the hooks invoked at steps 1 and 2 may check whether $DPKG_MAINTSCRIPT_PACKAGE begins with linux-image- and do nothing in this case.
  460.  
  461. 8.6 Deprecated features
  462. Kernel packages must not invoke boot loaders except via hooks. If /etc/kernel-img.conf contains do_bootloader = yes or equivalent, maintainer scripts that previously acted on this must warn that they are ignoring it. linux-base must also warn on upgrade that the default has changed. In squeeze+1, this prohibition extends to initramfs builder packages.
  463.  
  464. 8.7 Initial configuration by the installer
  465. The installer must not define do_bootloader, postinst_hook or postrm_hook in /etc/kernel-img.conf.
  466.  
  467. [ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]
  468.  
  469. Debian Linux Kernel Handbook
  470. version 1.0.12, Wed Sep 28 15:38:16 BST 2011
  471.  
  472. The Debian Kernel Handbook Project
  473.  
  474.  
  475. [ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]
  476.  
  477. Debian Linux Kernel Handbook 
  478. Chapter 9 - Reporting and handling bugs
  479.  
  480. 9.1 Bug handling policy for the kernel team
  481.  
  482. 9.1.1 Required information
  483. Submitters are expected to run reportbug or other tool that runs our bug script under the kernel version in question. The response to reports without this information should be a request to follow-up using reportbug. If we do not receive this information within a month of the request, the bug may be closed.
  484. Exceptions:
  485. If the kernel does not boot or is very unstable, instead of the usual system information we need the console messages via netconsole, serial console, or a photograph.
  486. If the report is relaying information about a bug acknowledged upstream, we do not need system information but we do need specific references (bugzilla.kernel.org or git commit id).
  487. If the bug is clearly not hardware-specific (e.g. packaging error), we do not need system information.
  488. If the bug is reported against a well-defined model, we may not need device listings.
  489.  
  490. 9.1.2 Severities
  491. Many submitters report bugs with the wrong severity. We interpret the criteria as follows and will adjust severity as appropriate:
  492. critical: makes unrelated software on the system (or the whole system) break...
  493. The bug must make the kernel unbootable or unstable on common hardware or all systems that a specific flavour is supposed to support. There is no 'unrelated software' since everything depends on the kernel.
  494. grave: makes the package in question unusable or mostly so...
  495. If the kernel is unusable, this already qualifies as critical.
  496. grave: ...or causes data loss...
  497. We exclude loss of data in memory due to a crash. Only corruption of data in storage or communication, or silent failure to write data, qualifies.
  498. important
  499. We include lack of support for new hardware that is generally available.
  500.  
  501. 9.1.3 Tagging
  502. We do not use user-tags. In order to aid bug triage we should make use of the standard tags and forwarded field defined by the BTS. In particular:
  503. Add moreinfo whenever we are waiting for a response from the submitter and remove it when we are not
  504. Do not add unreproducible to bugs that may be hardware-dependent
  505.  
  506. 9.1.4 Analysis by maintainers
  507. Generally we should not expect to be able to reproduce bugs without having similar hardware. We should consider:
  508. Searching bugzilla.kernel.org (including closed bugs) or other relevant bug tracker
  509. Searching kernel mailing lists
  510. Of the many archives, news.gmane.org seems to suck least
  511. Patches submitted to some lists are archived at patchwork.kernel.org
  512. Viewing git commit logs for relevant source files
  513. In case of a regression, from the known good to the bad version
  514. In other cases, from the bad version forwards, in case the bug has been fixed since
  515. Searching kerneloops.org for similar oopses
  516. Matching the machine code and registers in an 'oops' against the source and deducing how the impossible happened (this doesn't work that often but when it does you look like a genius ;-)
  517.  
  518. 9.1.5 Testing by submitter
  519. Depending on the technical sophistication of the submitter and the service requirements of the system in question (e.g. whether it's a production server) we can request one or more of the following:
  520. Gathering more information passively (e.g. further logging, reporting contents of files in procfs or sysfs)
  521. Upgrading to the current stable/stable-proposed-updates/stable-security version, if it includes a fix for a similar bug
  522. Adding debug or fallback options to the kernel command line or module parameters
  523. Installing the unstable or backports version temporarily
  524. Rebuilding and installing the kernel with a specific patch added (the script debian/bin/test-patches should make this easy)
  525. Using git bisect to find a specific upstream change that introduced the bug
  526. When a bug occurs in what upstream considers the current or previous stable release, and we cannot fix it, we ask the submitter to report it upstream at bugzilla.kernel.org under a specific Product and Component, and to tell us the upstream bug number. We do not report bugs directly because follow-up questions from upstream need to go to the submitter, not to us. Given the upstream bug number, we mark the bug as forwarded.bts-link then updates its status.
  527.  
  528. 9.1.6 Keeping bugs separate
  529. Many submitters search for a characteristic error message and treat this as indicating a specific bug. This can lead to many 'me too' follow-ups where, for example, the message indicates a driver bug and the second submitter is using a different driver from the original submitter.
  530. In order to avoid the report turning into a mess of conflicting information about two or more different bugs:
  531. We should try to respond to such a follow-up quickly, requesting a separate bug report
  532. We can use the BTS summary command to improve the description of the bug
  533. As a last resort, it may be necessary to open new bugs with the relevant information, set their submitters accordingly, and close the original report
  534. Where the original report describes more than one bug ('...and other thing...'), we should clone it and deal with each separately.
  535.  
  536. 9.1.7 Applying patches
  537. Patches should normally be reviewed and accepted by the relevant upstream maintainer (aside from necessary adjustments for an older kernel version) before being applied.
  538.  
  539. 9.1.8 Talking to submitters
  540. We should always be polite to submitters. Not only is this implied by the Social Contract, but it is likely to lead to a faster resolution of the bug. If a submitter overrated the severity, quietly downgrade it. If a submitter has done something stupid, request that they undo that and report back. 'Sorry' and 'please' make a big difference in tone.
  541. We will maintain general advice to submitters at http://wiki.debian.org/DebianKernelReportingBugs.
  542.  
  543. 9.2 Filing a bug against a kernel package
  544. Debian kernel team keeps track of the kernel package bugs in the Debian Bug Tracking System (BTS). For information on how to use the system see http://bugs.debian.org. You can also submit the bugs by using the reportbug command from the package with the same name. Please note that kernel bugs found in distributions derived from Debian (such as Knoppix, Mepis, Progeny, Ubuntu, Xandros, etc.) should not be reported to the Debian BTS (unless they can be also reproduced on a Debian system using official Debian kernel packages). Derived distributions have their own policies and procedures regarding kernel packaging, so the bugs found in them should be reported directly to their bug tracking systems or mailing lists.
  545. Nothing in this chapter is intended to keep you from filing a bug against one of the Debian kernel packages. However, you should recognize that the resources of the Debian kernel team are limited, and efficient reaction to a bug is largely determined by the amount and quality of the information included in the bug report. Please help us to do a better job by using the following guidelines when preparing to file the bug against kernel packages:
  546. Do the research. Before filing the bug search the web for the particular error message or symptom you are getting. As it is highly unlikely that you are the only person experiencing a particular problem, there is always a chance that it has been discussed elsewhere, and a possible solution, patch, or workaround has been proposed. If such information exists, always include the references to it in your report. Check the current bug list to see whether something similar has been reported already.
  547. Collect the information. Please provide enough information with your report. At a minimum, it should contain the exact version of the official Debian kernel package, where the bug is encountered, and steps to reproduce it. Depending on the nature of the bug you are reporting, you might also want to include the output of dmesg (or portions thereof), output of the lspci -vn. reportbug will do this automatically. If applicable, include the information about the latest known kernel version where the bug is not present, and output of the above commands for the working kernel as well. Use common sense and include other relevant information, if you think that it might help in solving the problem.
  548. Try to reproduce the problem with "vanilla" kernel. If you have a chance, try to reproduce the problem by building the binary kernel image from the "vanilla" kernel source, available fromhttp://www.kernel.org or its mirrors, using the same configuration as the Debian stock kernels. For more information on how to do this, look at Building a custom kernel from Debian kernel source, Section 4.5. If there is convincing evidence that the buggy behavior is caused by the Debian-specific changes to the kernel, the bug will usually be assigned higher priority by the kernel team. If the bug is not specific for Debian, check out the upstream kernel bug database to see if it has been reported there. If you are sure that it is an upstream problem, you can also report your bug there (but submit it to Debian BTS anyway, so that we can track it properly).
  549. Use the correct package to report the bug against. Please file bugs against the package containing the kernel version where the problem occurs (e.g. linux-image-2.6.26-2-686), not a metapackage (e.g.linux-image-2.6-686).
  550. Bugs involving ACPI. While ACPI (Advanced Control and Power Interface) support in Linux kernel has matured greatly in the 2.6 series, it occasionally causes problems (misrouted interrupts, failure to go into or return from the sleep/hybernation/suspend mode, thermal problems) on newer laptop models. They may be caused both by bugs in the kernel code or (more likely) in the ACPI interface of a particular machine. As resolution of such bugs requires access to the machine in question, it is pretty unlikely that kernel team will be able to do something about it. Consider reporting the problem to the Linux ACPI mailing list along with the submission to the Debian BTS. As a workaround, try booting the kernel with some combination of boot options acpi=off, pci=norouteirq, pci=noacpi, and nolapic to see if that improves the situation.
  551. Bugs involving tainted kernels. If a kernel crashes, it normally prints out some debugging information, indicating, among other things, whether the running kernel has been tainted. The kernel is referred to as tainted if at the time of the crash it had some binary third-party modules loaded. As kernel developers do not have access to the source code for such modules, problems involving them are notoriously difficult to debug. It is therefore strongly recommended to try and reproduce the problem with an untainted kernel (by preventing the loading of binary modules, for example). If the problem is due to the presence of such modules, there is not much the kernel community can do about it and it should be reported directly to their authors.
  552.  
  553. [ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]
  554.  
  555. Debian Linux Kernel Handbook
  556. version 1.0.12, Wed Sep 28 15:38:16 BST 2011
  557.  
  558. The Debian Kernel Handbook Project
Advertisement
Add Comment
Please, Sign In to add comment
Public Pastes
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!