mirror of
https://salsa.debian.org/kernel-team/kernel-handbook.git
synced 2026-01-11 19:58:20 +00:00
Use a richer set of markup elements
Instead of just <screen> and <literal>, use these elements as appropriate:
<command>
<computeroutput>
<envar>
<filename>
<lineannotation>
<literallayout>
<package>,
<prompt>
<symbol>
<userinput>
Also use <email> for the single email address.
This commit is contained in:
Ben Hutchings
parent
d5cbb8e9bb
commit
3018ac6f3a
11 changed files with 924 additions and 906 deletions
|
|
@ -299,7 +299,7 @@ url="https://wiki.debian.org/DebianKernelReportingBugs">https://wiki.debian.org/
|
|||
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 <ulink
|
||||
url="https://bugs.debian.org">https://bugs.debian.org</ulink>. You can also
|
||||
submit the bugs by using the <literal>reportbug</literal> command from the
|
||||
submit the bugs by using the <command>reportbug</command> 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 <emphasis>not</emphasis> be reported to the Debian BTS
|
||||
|
|
@ -335,8 +335,8 @@ bug list</ulink> to see whether something similar has been reported already.
|
|||
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 <literal>dmesg</literal> (or portions
|
||||
thereof), output of the <literal>lspci -vn</literal>.
|
||||
also want to include the output of <command>dmesg</command> (or portions
|
||||
thereof), output of the <command>lspci -vn</command>.
|
||||
<command>reportbug</command> 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.
|
||||
|
|
@ -397,20 +397,20 @@ regression.
|
|||
To start, recreate the problem with a vanilla kernel:
|
||||
</para>
|
||||
<screen>
|
||||
# apt-get install git build-essential
|
||||
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
|
||||
$ cd linux
|
||||
<prompt>#</prompt> <userinput>apt-get install git build-essential</userinput>
|
||||
<prompt>$</prompt> <userinput>git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git</userinput>
|
||||
<prompt>$</prompt> <userinput>cd linux</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
The above commands acquire a vanilla kernel. Configure, build and test a
|
||||
binary package as explained in <xref linkend="s-common-building"/>:
|
||||
</para>
|
||||
<screen>
|
||||
$ make localmodconfig; # minimal configuration
|
||||
$ scripts/config --disable DEBUG_INFO; # to keep the build reasonably small
|
||||
$ make deb-pkg
|
||||
# dpkg -i ../linux-image-3.5.0_3.5.0-1_i386.deb; # substitute package name from the previous command
|
||||
# reboot
|
||||
<prompt>$</prompt> <userinput>make localmodconfig</userinput> <lineannotation># minimal configuration</lineannotation>
|
||||
<prompt>$</prompt> <userinput>scripts/config --disable DEBUG_INFO</userinput> <lineannotation># to keep the build reasonably small</lineannotation>
|
||||
<prompt>$</prompt> <userinput>make deb-pkg</userinput>
|
||||
<prompt>#</prompt> <userinput>dpkg -i ../linux-image-3.5.0_3.5.0-1_i386.deb</userinput> <lineannotation># substitute package name from the previous command</lineannotation>
|
||||
<prompt>#</prompt> <userinput>reboot</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
If the bug doesn't show up, try again with the official configuration file from
|
||||
|
|
@ -422,41 +422,41 @@ Initialize the bisection process by declaring which versions worked and did not
|
|||
work:
|
||||
</para>
|
||||
<screen>
|
||||
$ cd linux
|
||||
$ git bisect start
|
||||
$ git bisect good v3.0; # or whichever was known to be good
|
||||
$ git bisect bad; # current version is bad
|
||||
<prompt>$</prompt> <userinput>cd linux</userinput>
|
||||
<prompt>$</prompt> <userinput>git bisect start</userinput>
|
||||
<prompt>$</prompt> <userinput>git bisect good v3.0</userinput> <lineannotation># or whichever was known to be good</lineannotation>
|
||||
<prompt>$</prompt> <userinput>git bisect bad</userinput> <lineannotation># current version is bad</lineannotation>
|
||||
</screen>
|
||||
<para>
|
||||
Now git checks out a version half-way in between to test. Build it, reusing
|
||||
the prepared configuration.
|
||||
</para>
|
||||
<screen>
|
||||
$ make silentoldconfig
|
||||
$ make deb-pkg
|
||||
<prompt>$</prompt> <userinput>make silentoldconfig</userinput>
|
||||
<prompt>$</prompt> <userinput>make deb-pkg</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
Install the package, reboot, and test.
|
||||
</para>
|
||||
<screen>
|
||||
$ git bisect good; # if this version doesn't exhibit the bug
|
||||
$ git bisect bad; # if it does
|
||||
$ git bisect skip; # if some other bug makes it hard to test
|
||||
<prompt>$</prompt> <userinput>git bisect good</userinput> <lineannotation># if this version doesn't exhibit the bug</lineannotation>
|
||||
<prompt>$</prompt> <userinput>git bisect bad</userinput> <lineannotation># if it does</lineannotation>
|
||||
<prompt>$</prompt> <userinput>git bisect skip</userinput> <lineannotation># if some other bug makes it hard to test</lineannotation>
|
||||
</screen>
|
||||
<para>
|
||||
And on to the next iteration:
|
||||
</para>
|
||||
<screen>
|
||||
$ make silentoldconfig
|
||||
$ make deb-pkg
|
||||
<prompt>$</prompt> <userinput>make silentoldconfig</userinput>
|
||||
<prompt>$</prompt> <userinput>make deb-pkg</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
At the end of the process, the name of the "first bad commit" is printed, which
|
||||
is very useful for tracking down the bug. Narrowing down the regression range
|
||||
with a few rounds is useful even if you don't get that far; in that case, run
|
||||
<literal>git bisect log</literal> to produce a log. If you are the visual sort
|
||||
of person, <literal>git bisect visualize</literal> with the
|
||||
<literal>gitk</literal> package installed can show what is happening between
|
||||
<command>git bisect log</command> to produce a log. If you are the visual sort
|
||||
of person, <command>git bisect visualize</command> with the
|
||||
<package>gitk</package> package installed can show what is happening between
|
||||
steps.
|
||||
</para>
|
||||
<para>
|
||||
|
|
|
|||
|
|
@ -7,16 +7,16 @@
|
|||
<para>
|
||||
To get the Debian kernel source at the current maximum patchlevel, it is
|
||||
sufficient to install the latest
|
||||
<literal>linux-source-<replaceable>version</replaceable></literal> package and unpack
|
||||
<package>linux-source-<replaceable>version</replaceable></package> package and unpack
|
||||
the source, for example:
|
||||
</para>
|
||||
<screen>
|
||||
# apt-get install linux-source-4.3
|
||||
$ tar xaf /usr/src/linux-source-4.3.tar.xz
|
||||
<prompt>#</prompt> <userinput>apt-get install linux-source-4.3</userinput>
|
||||
<prompt>$</prompt> <userinput>tar xaf /usr/src/linux-source-4.3.tar.xz</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
The unpacked source tree then will be available in
|
||||
<literal>linux-source-4.3</literal> directory.
|
||||
<filename>linux-source-4.3</filename> directory.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
|
@ -31,8 +31,8 @@ Run the following commands:
|
|||
</para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><literal># apt-get install build-essential fakeroot</literal></term>
|
||||
<term><literal># apt-get build-dep linux</literal></term>
|
||||
<term><prompt>#</prompt> <userinput>apt-get install build-essential fakeroot</userinput></term>
|
||||
<term><prompt>#</prompt> <userinput>apt-get build-dep linux</userinput></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This will install the packages required by the kernel build process.
|
||||
|
|
@ -40,12 +40,12 @@ This will install the packages required by the kernel build process.
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>$ apt-get source linux</literal></term>
|
||||
<term><prompt>$</prompt> <userinput>apt-get source linux</userinput></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This will download and unpack the <literal>linux</literal> source package,
|
||||
This will download and unpack the <package>linux</package> source package,
|
||||
making the tree available in the
|
||||
<literal>linux-<replaceable>version</replaceable></literal> directory. As always,
|
||||
<filename>linux-<replaceable>version</replaceable></filename> directory. As always,
|
||||
the revision part of the version of this package (for example, 1 in 3.2.19-1)
|
||||
will determine its patchlevel with respect to the original upstream kernel
|
||||
source.
|
||||
|
|
@ -53,7 +53,7 @@ source.
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>$ cd linux-<replaceable>version</replaceable></literal></term>
|
||||
<term><prompt>$</prompt> <userinput>cd linux-<replaceable>version</replaceable></userinput></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Enter the source directory.
|
||||
|
|
@ -67,14 +67,14 @@ Building binary packages for a single kernel flavour with debug info enabled
|
|||
(currently true for the <literal>686-pae</literal>, <literal>amd64</literal>,
|
||||
<literal>rt-686-pae</literal>, <literal>rt-amd64</literal> and
|
||||
<literal>s390x</literal> configurations) requires up to 10 GB space in the
|
||||
package directory and 300 MB in <literal>/tmp</literal> (or
|
||||
<literal>$TMPDIR</literal>).
|
||||
package directory and 300 MB in <filename>/tmp</filename> (or
|
||||
<envar>$TMPDIR</envar>).
|
||||
</para>
|
||||
<para>
|
||||
Building with debug info disabled requires about 2 GB and 25 MB respectively.
|
||||
You can disable debug info by changing the value of
|
||||
<literal>debug-info</literal> to <literal>false</literal> in
|
||||
<literal>debian/config/</literal><replaceable>arch</replaceable><literal>/defines</literal>.
|
||||
<filename>debian/config/<replaceable>arch</replaceable>/defines</filename>.
|
||||
</para>
|
||||
<para>
|
||||
Building all binary packages for i386 or amd64 currently requires about 20 GB
|
||||
|
|
@ -91,21 +91,21 @@ The source package includes a script to simplify the process of building with
|
|||
extra patches. You can use this by running commands such as:
|
||||
</para>
|
||||
<screen>
|
||||
# apt-get install devscripts
|
||||
$ bash debian/bin/test-patches ../fix-bug123456.patch ../add-foo-driver.patch
|
||||
<prompt>#</prompt> <userinput>apt-get install devscripts</userinput>
|
||||
<prompt>$</prompt> <userinput>bash debian/bin/test-patches ../fix-bug123456.patch ../add-foo-driver.patch</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
This script has options to control the flavour, featureset, etc. For a summary
|
||||
of the options, run:
|
||||
</para>
|
||||
<screen>
|
||||
$ bash debian/bin/test-patches
|
||||
<prompt>$</prompt> <userinput>bash debian/bin/test-patches</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
You may then need to build the linux-base package as well:
|
||||
</para>
|
||||
<screen>
|
||||
$ fakeroot make -f debian/rules.real install-linux-base
|
||||
<prompt>$</prompt> <userinput>fakeroot make -f debian/rules.real install-linux-base</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
However, if you need to change the configuration or make other changes, you
|
||||
|
|
@ -116,7 +116,7 @@ should not use this script and should follow the instructions below.
|
|||
<section id="s4.2.3"><title>Applying patches or configuration changes</title>
|
||||
<para>
|
||||
It is possible to apply extra patches to the source before starting the build.
|
||||
In the <literal>linux</literal> source package, the default (non-featureset)
|
||||
In the <package>linux</package> source package, the default (non-featureset)
|
||||
patches are automatically applied in the top level directory.
|
||||
</para>
|
||||
<para>
|
||||
|
|
@ -135,23 +135,23 @@ top level
|
|||
<term>source with featureset:</term>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>debian/build/source_<replaceable>featureset</replaceable></literal>
|
||||
<filename>debian/build/source_<replaceable>featureset</replaceable></filename>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<para>
|
||||
You should apply the extra patches in the appropriate directory. In the
|
||||
<literal>linux</literal> source package you can use the
|
||||
<literal>quilt</literal> utility to do this.
|
||||
<package>linux</package> source package you can use the
|
||||
<command>quilt</command> utility to do this.
|
||||
</para>
|
||||
<para>
|
||||
To change the configuration before building, for example for the 686-pae
|
||||
flavour on i386, run the commands:
|
||||
</para>
|
||||
<screen>
|
||||
$ fakeroot make -f debian/rules.gen setup_i386_none_686-pae
|
||||
$ make -C debian/build/build_i386_none_686-pae menuconfig
|
||||
<prompt>$</prompt> <userinput>fakeroot make -f debian/rules.gen setup_i386_none_686-pae</userinput>
|
||||
<prompt>$</prompt> <userinput>make -C debian/build/build_i386_none_686-pae menuconfig</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
If the patches or configuration changes alter type definitions for the kernel,
|
||||
|
|
@ -164,19 +164,19 @@ you may need to change the ABI name; see <xref linkend="s-abi-name"/>.
|
|||
To build all possible packages for this architecture, run:
|
||||
</para>
|
||||
<screen>
|
||||
$ fakeroot debian/rules binary
|
||||
<prompt>$</prompt> <userinput>fakeroot debian/rules binary</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
To build all architecture-dependent packages, run:
|
||||
</para>
|
||||
<screen>
|
||||
$ fakeroot debian/rules binary-arch
|
||||
<prompt>$</prompt> <userinput>fakeroot debian/rules binary-arch</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
To build all architecture-independent packages, run:
|
||||
</para>
|
||||
<screen>
|
||||
$ fakeroot debian/rules binary-indep
|
||||
<prompt>$</prompt> <userinput>fakeroot debian/rules binary-indep</userinput>
|
||||
</screen>
|
||||
</section>
|
||||
|
||||
|
|
@ -186,8 +186,8 @@ For example, to build only the binary packages for 686-pae flavour on i386
|
|||
architecture, use the following commands:
|
||||
</para>
|
||||
<screen>
|
||||
$ fakeroot debian/rules source
|
||||
$ fakeroot make -f debian/rules.gen binary-arch_i386_none_686-pae
|
||||
<prompt>$</prompt> <userinput>fakeroot debian/rules source</userinput>
|
||||
<prompt>$</prompt> <userinput>fakeroot make -f debian/rules.gen binary-arch_i386_none_686-pae</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
The target in this command has the general form of
|
||||
|
|
@ -195,12 +195,12 @@ The target in this command has the general form of
|
|||
Replace the <literal><replaceable>featureset</replaceable></literal> with
|
||||
<literal>none</literal> 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 <literal>linux-headers-<replaceable>version</replaceable>-common</literal>
|
||||
need the <package>linux-headers-<replaceable>version</replaceable>-common</package>
|
||||
binary package, which can be built using the commands:
|
||||
</para>
|
||||
<screen>
|
||||
$ fakeroot debian/rules source
|
||||
$ fakeroot make -f debian/rules.gen binary-arch_i386_none_real
|
||||
<prompt>$</prompt> <userinput>fakeroot debian/rules source</userinput>
|
||||
<prompt>$</prompt> <userinput>fakeroot make -f debian/rules.gen binary-arch_i386_none_real</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
The target in this command has the general form of
|
||||
|
|
@ -217,8 +217,8 @@ version:
|
|||
</para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><literal># apt-get install build-essential fakeroot rsync git</literal></term>
|
||||
<term><literal># apt-get build-dep linux</literal></term>
|
||||
<term><prompt>#</prompt> <userinput>apt-get install build-essential fakeroot rsync git</userinput></term>
|
||||
<term><prompt>#</prompt> <userinput>apt-get build-dep linux</userinput></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The last two commands will install the build dependencies required by the
|
||||
|
|
@ -227,7 +227,7 @@ kernel build process.
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>$ git clone -b <replaceable>dist</replaceable> --single-branch https://anonscm.debian.org/git/kernel/linux.git</literal></term>
|
||||
<term><prompt>$</prompt> <userinput>git clone -b <replaceable>dist</replaceable> --single-branch https://anonscm.debian.org/git/kernel/linux.git</userinput></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This will check out the Debian packaging. <replaceable>dist</replaceable> is
|
||||
|
|
@ -239,10 +239,10 @@ this will download several hundred megabytes of data.
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>$ apt-get source -d linux</literal></term>
|
||||
<term><prompt>$</prompt> <userinput>apt-get source -d linux</userinput></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This will download the <literal>linux</literal> upstream source (and the last
|
||||
This will download the <package>linux</package> 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
|
||||
<ulink url="https://people.debian.org">people.debian.org</ulink> instead.
|
||||
|
|
@ -250,8 +250,8 @@ you might need to override APT's version selection or download a tarball from
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>$ cd linux</literal></term>
|
||||
<term><literal>$ debian/rules orig</literal></term>
|
||||
<term><prompt>$</prompt> <userinput>cd linux</userinput></term>
|
||||
<term><prompt>$</prompt> <userinput>debian/rules orig</userinput></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This unpacks the upstream source and merges it with the Debian packaging.
|
||||
|
|
@ -259,7 +259,7 @@ This unpacks the upstream source and merges it with the Debian packaging.
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>$ debian/rules debian/control</literal></term>
|
||||
<term><prompt>$</prompt> <userinput>debian/rules debian/control</userinput></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This generates a Debian package control file based on the current definitions
|
||||
|
|
@ -268,7 +268,7 @@ of the various kernel flavours which can be built.
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>$ fakeroot debian/rules <replaceable>target</replaceable></literal></term>
|
||||
<term><prompt>$</prompt> <userinput>fakeroot debian/rules <replaceable>target</replaceable></userinput></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Finally, build binary packages as explained in <xref
|
||||
|
|
@ -287,32 +287,32 @@ version is a release candidate, change the string <literal>-rc</literal> to
|
|||
<literal>~</literal> indicates a pre-release.)
|
||||
</para>
|
||||
<para>
|
||||
The 'orig' tarball is generated by the <literal>genorig.py</literal> script.
|
||||
The 'orig' tarball is generated by the <command>genorig.py</command> script.
|
||||
It takes either a tarball and optional patch from kernel.org, or a git
|
||||
repository. First ensure you have the necessary tools installed:
|
||||
</para>
|
||||
<screen>
|
||||
# apt-get install unifdef
|
||||
<prompt>#</prompt> <userinput>apt-get install unifdef</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
Then if you have a tarball, run a command such as:
|
||||
</para>
|
||||
<screen>
|
||||
$ debian/bin/genorig.py ../linux-4.3.tar.xz ../patch-4.4-rc1.xz
|
||||
<prompt>$</prompt> <userinput>debian/bin/genorig.py ../linux-4.3.tar.xz ../patch-4.4-rc1.xz</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
Or if you have a git repository, pass the name of its directory:
|
||||
</para>
|
||||
<screen>
|
||||
$ debian/bin/genorig.py ~/src/linux
|
||||
<prompt>$</prompt> <userinput>debian/bin/genorig.py ~/src/linux</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
Either of these will generate a file such as
|
||||
<literal>../orig/linux_3.5~rc1.orig.tar.xz</literal>. You can then combine
|
||||
<filename>../orig/linux_3.5~rc1.orig.tar.xz</filename>. You can then combine
|
||||
this tarball with the Debian packaging by running:
|
||||
</para>
|
||||
<screen>
|
||||
$ debian/rules orig
|
||||
<prompt>$</prompt> <userinput>debian/rules orig</userinput>
|
||||
</screen>
|
||||
</section>
|
||||
|
||||
|
|
@ -327,13 +327,13 @@ to it.
|
|||
<para>
|
||||
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 <literal>linux-source</literal> package and the
|
||||
<literal>make deb-pkg</literal> target. First, prepare the kernel tree:
|
||||
source is to use the <package>linux-source</package> package and the
|
||||
<command>make deb-pkg</command> target. First, prepare the kernel tree:
|
||||
</para>
|
||||
<screen>
|
||||
# apt-get install linux-source-4.3
|
||||
$ tar xaf /usr/src/linux-source-4.3.tar.xz
|
||||
$ cd linux-source-4.3
|
||||
<prompt>#</prompt> <userinput>apt-get install linux-source-4.3</userinput>
|
||||
<prompt>$</prompt> <userinput>tar xaf /usr/src/linux-source-4.3.tar.xz</userinput>
|
||||
<prompt>$</prompt> <userinput>cd linux-source-4.3</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
The kernel now needs to be configured, that is you have to set the kernel
|
||||
|
|
@ -343,48 +343,49 @@ number of targets, which invoke different configuration frontends. For
|
|||
example, one can use console-based menu configuration by invoking the command
|
||||
</para>
|
||||
<screen>
|
||||
$ make menuconfig
|
||||
<prompt>$</prompt> <userinput>make menuconfig</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
Instead of <literal>menuconfig</literal> one can use <literal>config</literal>
|
||||
(text-based line-by-line configuration frontend) or <literal>xconfig</literal>
|
||||
(graphical configuration frontend). It is also possible to reuse your old
|
||||
configuration file by placing it as a <literal>.config</literal> file in the
|
||||
configuration file by placing it as a <filename>.config</filename> file in the
|
||||
top-level directory and running one of the configuration targets (if you want
|
||||
to adjust something) or <literal>make oldconfig</literal> (to keep the same
|
||||
to adjust something) or <command>make oldconfig</command> (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
|
||||
<literal>menuconfig</literal> frontend requires the <literal>ncurses</literal>
|
||||
library, which at time of writing is provided by the
|
||||
<literal>libncurses5-dev</literal> package.
|
||||
<package>libncurses5-dev</package> package.
|
||||
</para>
|
||||
<para>
|
||||
The build will use less disk space if the CONFIG_DEBUG_INFO option is disabled
|
||||
(see <xref linkend="s-common-size"/>). Debuginfo is only needed if you plan to
|
||||
The build will use less disk space if the
|
||||
<symbol>CONFIG_DEBUG_INFO</symbol> option is disabled (see <xref
|
||||
linkend="s-common-size"/>). Debuginfo is only needed if you plan to
|
||||
use binary object tools like crash, kgdb, and SystemTap on the kernel.
|
||||
</para>
|
||||
<screen>
|
||||
$ scripts/config --disable DEBUG_INFO
|
||||
<prompt>$</prompt> <userinput>scripts/config --disable DEBUG_INFO</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
After the configuration process is finished, the new or updated kernel
|
||||
configuration will be stored in <literal>.config</literal> file in the
|
||||
configuration will be stored in <filename>.config</filename> file in the
|
||||
top-level directory. The build is started using the commands
|
||||
</para>
|
||||
<screen>
|
||||
$ make clean
|
||||
$ make deb-pkg
|
||||
<prompt>$</prompt> <userinput>make clean</userinput>
|
||||
<prompt>$</prompt> <userinput>make deb-pkg</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
As a result of the build, a custom kernel package
|
||||
<literal>linux-image-3.2.19_3.2.19-1_i386.deb</literal> (name will reflect the
|
||||
<filename>linux-image-3.2.19_3.2.19-1_i386.deb</filename> (name will reflect the
|
||||
version of the kernel and build number) will be created in the directory one
|
||||
level above the top of the tree. It may be installed using
|
||||
<literal>dpkg</literal> just as any other package:
|
||||
<command>dpkg</command> just as any other package:
|
||||
</para>
|
||||
<screen>
|
||||
|
||||
# dpkg -i ../linux-image-3.2.19_3.2.19-1_i386.deb
|
||||
<prompt>#</prompt> <userinput>dpkg -i ../linux-image-3.2.19_3.2.19-1_i386.deb</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
This command will unpack the kernel, generate the initrd if necessary (see
|
||||
|
|
@ -393,7 +394,7 @@ the newly installed kernel the default one. If this command completed without
|
|||
any problems, you can reboot using the
|
||||
</para>
|
||||
<screen>
|
||||
# shutdown -r now
|
||||
<prompt>#</prompt> <userinput>shutdown -r now</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
command to boot the new kernel.
|
||||
|
|
@ -401,10 +402,10 @@ command to boot the new kernel.
|
|||
<para>
|
||||
For much more information about bootloaders and their configuration please
|
||||
check their documentation, which can be accessed using the commands
|
||||
<literal>man lilo</literal>, <literal>man lilo.conf</literal>, <literal>man
|
||||
grub</literal>, and so on. You can also look for documentation in the
|
||||
<literal>/usr/share/doc/<replaceable>package</replaceable></literal> directories,
|
||||
with <literal><replaceable>package</replaceable></literal> being the name of the
|
||||
<command>man lilo</command>, <command>man lilo.conf</command>, <command>man
|
||||
grub</command>, and so on. You can also look for documentation in the
|
||||
<filename>/usr/share/doc/<replaceable>package</replaceable></filename> directories,
|
||||
with <replaceable>package</replaceable> being the name of the
|
||||
package involved.
|
||||
</para>
|
||||
</section>
|
||||
|
|
@ -421,7 +422,7 @@ source is downloaded using your favourite browser or using wget, as follows:
|
|||
</para>
|
||||
<screen>
|
||||
|
||||
$ wget https://kernel.org/pub/linux/kernel/v4.x/linux-4.3.tar.xz
|
||||
<prompt>$</prompt> <userinput>wget https://kernel.org/pub/linux/kernel/v4.x/linux-4.3.tar.xz</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
The integrity of the downloaded archive may be verified by fetching the
|
||||
|
|
@ -429,43 +430,43 @@ corresponding cryptographic signature
|
|||
</para>
|
||||
<screen>
|
||||
|
||||
$ wget https://kernel.org/pub/linux/kernel/v4.x/linux-4.3.tar.sign
|
||||
<prompt>$</prompt> <userinput>wget https://kernel.org/pub/linux/kernel/v4.x/linux-4.3.tar.sign</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
and running this command (<literal>gnupg</literal> package must be installed):
|
||||
and running this command (<package>gnupg</package> package must be installed):
|
||||
</para>
|
||||
<screen>
|
||||
$ unxz -c linux-4.3.tar.xz | gpg --verify linux-4.3.tar.sign -
|
||||
<prompt>$</prompt> <userinput>unxz -c linux-4.3.tar.xz | gpg --verify linux-4.3.tar.sign -</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
Successful verification results in output similar to the one below:
|
||||
</para>
|
||||
<screen>
|
||||
gpg: Signature made Mon 21 May 2012 01:48:14 AM CEST using RSA key ID 00411886
|
||||
<computeroutput>gpg: Signature made Mon 21 May 2012 01:48:14 AM CEST using RSA key ID 00411886
|
||||
gpg: Good signature from "Linus Torvalds <torvalds@linux-foundation.org>"
|
||||
gpg: WARNING: This key is not certified with a trusted signature!
|
||||
gpg: There is no indication that the signature belongs to the owner.
|
||||
Primary key fingerprint: ABAF 11C6 5A29 70B1 30AB E3C4 79BE 3E43 0041 1886
|
||||
Primary key fingerprint: ABAF 11C6 5A29 70B1 30AB E3C4 79BE 3E43 0041 1886</computeroutput>
|
||||
</screen>
|
||||
<para>
|
||||
After that the archive may be unpacked using
|
||||
</para>
|
||||
<screen>
|
||||
$ tar xaf linux-4.3.tar.xz
|
||||
$ cd linux-4.3
|
||||
<prompt>$</prompt> <userinput>tar xaf linux-4.3.tar.xz</userinput>
|
||||
<prompt>$</prompt> <userinput>cd linux-4.3</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
The unpacked kernel tree (in <literal>linux-4.3</literal> now has to be
|
||||
The unpacked kernel tree (in <filename>linux-4.3</filename> now has to be
|
||||
configured. The existing configuration file may be used as a starting point
|
||||
</para>
|
||||
<screen>
|
||||
$ cp /boot/config-3.2.0-2-686-pae ./.config
|
||||
<prompt>$</prompt> <userinput>cp /boot/config-3.2.0-2-686-pae ./.config</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
After the configuration with one of the configuration frontends (invoked by
|
||||
<literal>make oldconfig</literal>, <literal>make config</literal>,
|
||||
<literal>make menuconfig</literal>, etc) is completed, the build may be started
|
||||
using <literal>make deb-pkg</literal> target as described above.
|
||||
<command>make oldconfig</command>, <command>make config</command>,
|
||||
<command>make menuconfig</command>, etc) is completed, the build may be started
|
||||
using <command>make deb-pkg</command> target as described above.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
|
@ -475,11 +476,11 @@ 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 <literal>3.2.0-2-686-pae</literal> (use the <literal>uname
|
||||
-r</literal> command to verify the version) from the
|
||||
<literal>linux-image-3.2.0-2-686-pae</literal> package, and would like to use
|
||||
Debian kernel <literal>3.2.0-2-686-pae</literal> (use the <command>uname
|
||||
-r</command> command to verify the version) from the
|
||||
<package>linux-image-3.2.0-2-686-pae</package> package, and would like to use
|
||||
the squash filesystem, all you need to do is install
|
||||
<literal>squashfs-modules-3.2.0-2-686-pae</literal> binary package, which
|
||||
<package>squashfs-modules-3.2.0-2-686-pae</package> binary package, which
|
||||
provides the neccessary binary kernel modules.
|
||||
</para>
|
||||
<para>
|
||||
|
|
@ -487,13 +488,13 @@ 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
|
||||
<replaceable role="strong">source</replaceable> for the kernel modules. Names of
|
||||
such packages typically end in <literal>-source</literal>, for example
|
||||
<literal>squashfs-source</literal>, <literal>thinkpad-source</literal>,
|
||||
<literal>rt2x00-source</literal> and many others. These packages contain
|
||||
<package>squashfs-source</package>, <package>thinkpad-source</package>,
|
||||
<package>rt2x00-source</package> and many others. These packages contain
|
||||
debianized source code of the kernel modules, suitable for building using the
|
||||
<literal>module-assistant</literal> (or <literal>m-a</literal>) script from the
|
||||
<literal>module-assistant</literal> package. Typical sequence to build a
|
||||
<command>module-assistant</command> (or <command>m-a</command>) script from the
|
||||
<package>module-assistant</package> package. Typical sequence to build a
|
||||
custom binary module package, matching a kernel
|
||||
<literal>3.2.0-2-686-pae</literal> (as returned by <literal>uname -r</literal>)
|
||||
<literal>3.2.0-2-686-pae</literal> (as returned by <command>uname -r</command>)
|
||||
from the debianized source consists of the following steps:
|
||||
</para>
|
||||
<para>
|
||||
|
|
@ -501,33 +502,33 @@ Install a set of kernel headers, matching the kernel for which the modules are
|
|||
going to be built:
|
||||
</para>
|
||||
<screen>
|
||||
# apt-get install linux-headers-3.2.0-2-686-pae
|
||||
<prompt>#</prompt> <userinput>apt-get install linux-headers-3.2.0-2-686-pae</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
Install the package containing the source:
|
||||
</para>
|
||||
<screen>
|
||||
# apt-get install squashfs-source
|
||||
<prompt>#</prompt> <userinput>apt-get install squashfs-source</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
Invoke <literal>module-assistant</literal> (aka <literal>m-a</literal>) to do
|
||||
Invoke <command>module-assistant</command> (aka <command>m-a</command>) to do
|
||||
the heavy lifting:
|
||||
</para>
|
||||
<screen>
|
||||
# m-a build squashfs
|
||||
<prompt>#</prompt> <userinput>m-a build squashfs</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
As a result, a Debian package is going to be built and placed in
|
||||
<literal>/usr/src</literal>. It can be installed the usual way, using
|
||||
<literal>dpkg -i</literal>. Two last steps (building and installation) may be
|
||||
<filename>/usr/src</filename>. It can be installed the usual way, using
|
||||
<command>dpkg -i</command>. Two last steps (building and installation) may be
|
||||
combined using the invocation
|
||||
</para>
|
||||
<screen>
|
||||
# m-a auto-install squashfs
|
||||
<prompt>#</prompt> <userinput>m-a auto-install squashfs</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
Check out the <literal>module-assistant</literal> documentation (<literal>man
|
||||
module-assistant</literal>) for other options and much more information on how
|
||||
Check out the <command>module-assistant</command> documentation (<command>man
|
||||
module-assistant</command>) for other options and much more information on how
|
||||
to use it.
|
||||
</para>
|
||||
<para>
|
||||
|
|
@ -536,10 +537,10 @@ 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
|
||||
<literal>/usr/src/linux-headers-<replaceable>uname</replaceable></literal>, provided
|
||||
by the <literal>linux-headers-<replaceable>uname</replaceable></literal> package.
|
||||
Here <literal><replaceable>uname</replaceable></literal> is the output of the
|
||||
<literal>uname -r</literal> command. If you are building and running your own
|
||||
<filename>/usr/src/linux-headers-<replaceable>uname</replaceable></filename>, provided
|
||||
by the <package>linux-headers-<replaceable>uname</replaceable></package> package.
|
||||
Here <replaceable>uname</replaceable> is the output of the
|
||||
<command>uname -r</command> 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.
|
||||
</para>
|
||||
|
|
|
|||
|
|
@ -11,11 +11,11 @@ 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 <literal>init</literal> script on the initramfs
|
||||
the real root filesystem. The <command>init</command> script on the initramfs
|
||||
loads modules and performs other neccessary initialization steps. At the end
|
||||
of this stage <literal>run-init</literal> deletes the initramfs from memory,
|
||||
of this stage <command>run-init</command> deletes the initramfs from memory,
|
||||
mounts the real root filesystem and passes control to the
|
||||
<literal>/sbin/init</literal> program on it.
|
||||
<command>/sbin/init</command> program on it.
|
||||
</para>
|
||||
<para>
|
||||
Two major goals are achieved with such setup: the kernel size is kept under
|
||||
|
|
@ -31,24 +31,24 @@ 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:
|
||||
<literal>update-initramfs</literal> provided by
|
||||
<literal>initramfs-tools</literal> (default) and
|
||||
<literal>dracut-update-initramfs</literal> provided by the
|
||||
<literal>dracut</literal> package (experimental).
|
||||
<command>update-initramfs</command> provided by
|
||||
<package>initramfs-tools</package> (default) and
|
||||
<command>dracut-update-initramfs</command> provided by the
|
||||
<package>dracut</package> package (experimental).
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id="s-initramfs-regen"><title>Regenerating the initramfs</title>
|
||||
<para>
|
||||
If changes are desired after the corresponding <literal>linux-image</literal>
|
||||
If changes are desired after the corresponding <package>linux-image</package>
|
||||
has been installed, the initramfs needs to be regenerated. This is achieved by
|
||||
the command
|
||||
</para>
|
||||
<screen>
|
||||
# dpkg-reconfigure linux-image-3.2.0-2-686-pae
|
||||
<prompt>#</prompt> <userinput>dpkg-reconfigure linux-image-3.2.0-2-686-pae</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
where <literal>linux-image-3.2.0-2-686-pae</literal> is the name of the kernel
|
||||
where <package>linux-image-3.2.0-2-686-pae</package> is the name of the kernel
|
||||
package for which the initramfs regeneration is requested.
|
||||
</para>
|
||||
</section>
|
||||
|
|
@ -60,17 +60,17 @@ problem or for educational purposes. They are compressed
|
|||
<literal>cpio</literal> archives, which may be extracted using the command
|
||||
</para>
|
||||
<screen>
|
||||
$ zcat /boot/initrd.img-3.2.0-2-686-pae | cpio -i
|
||||
<prompt>$</prompt> <userinput>zcat /boot/initrd.img-3.2.0-2-686-pae | cpio -i</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
It will unpack the contents of the initramfs into the current directory.
|
||||
</para>
|
||||
<para>
|
||||
It is also possible to list the contents of an initramfs using the
|
||||
<literal>cpio -t</literal> option or the command
|
||||
<command>cpio</command> <option>-t</option> option or the command
|
||||
</para>
|
||||
<screen>
|
||||
$ lsinitramfs /boot/initrd.img-3.2.0-2-686-pae
|
||||
<prompt>$</prompt> <userinput>lsinitramfs /boot/initrd.img-3.2.0-2-686-pae</userinput>
|
||||
</screen>
|
||||
</section>
|
||||
|
||||
|
|
|
|||
|
|
@ -7,38 +7,37 @@
|
|||
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
|
||||
<literal>lsmod</literal> command, modules may be loaded using
|
||||
<literal>modprobe</literal>, and removed using <literal>modprobe -r</literal>.
|
||||
The <literal>depmod</literal> command may be used to regenerate the list of
|
||||
<command>lsmod</command> command, modules may be loaded using
|
||||
<command>modprobe</command>, and removed using <command>modprobe -r</command>.
|
||||
The <command>depmod</command> 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.
|
||||
</para>
|
||||
<para>
|
||||
Normally, the devices are detected and neccessary kernel modules are loaded by
|
||||
<literal>udev</literal> during boot time. Occasionally, one may need finer
|
||||
<command>udev</command> 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.
|
||||
</para>
|
||||
<para>
|
||||
If some modules are not loaded automatically by <literal>udev</literal>, but
|
||||
If some modules are not loaded automatically by <command>udev</command>, but
|
||||
you would like them to be loaded during boot, it is possible to force it by
|
||||
listing the names of the modules in <literal>/etc/modules</literal>. This will
|
||||
listing the names of the modules in <filename>/etc/modules</filename>. This will
|
||||
be scanned for the names of the modules (one name per line), which will then be
|
||||
loaded using <literal>modprobe</literal>. For example, a typical
|
||||
<literal>/etc/modules</literal> might look like:
|
||||
loaded using <command>modprobe</command>. For example, a typical
|
||||
<filename>/etc/modules</filename> might look like:
|
||||
</para>
|
||||
<screen>
|
||||
loop
|
||||
<literallayout class="monospaced">loop
|
||||
sbp2
|
||||
</screen>
|
||||
</literallayout>
|
||||
<para>
|
||||
To find out what parameters are accepted by a given module, you can use the
|
||||
<literal>modinfo</literal> command, for example:
|
||||
<command>modinfo</command> command, for example:
|
||||
</para>
|
||||
<screen>
|
||||
# modinfo loop
|
||||
filename: /lib/modules/3.2.0-2-686-pae/kernel/drivers/block/loop.ko
|
||||
<prompt>#</prompt> <userinput>modinfo loop</userinput>
|
||||
<computeroutput>filename: /lib/modules/3.2.0-2-686-pae/kernel/drivers/block/loop.ko
|
||||
alias: devname:loop-control
|
||||
alias: char-major-10-237
|
||||
alias: block-major-7-*
|
||||
|
|
@ -47,38 +46,36 @@ depends:
|
|||
intree: Y
|
||||
vermagic: 3.2.0-2-686-pae SMP mod_unload modversions 686
|
||||
parm: max_loop:Maximum number of loop devices (int)
|
||||
parm: max_part:Maximum number of partitions per loop device (int)
|
||||
parm: max_part:Maximum number of partitions per loop device (int)</computeroutput>
|
||||
</screen>
|
||||
<para>
|
||||
To add custom arguments to the modules loaded by <literal>udev</literal> early
|
||||
To add custom arguments to the modules loaded by <command>udev</command> early
|
||||
in the boot process, you need to create a custom configuration file for
|
||||
<literal>modprobe</literal>, which <literal>udev</literal> uses to load the
|
||||
<command>modprobe</command>, which <command>udev</command> uses to load the
|
||||
modules. For example, to pass an <literal>atapi_enabled=1</literal> argument
|
||||
to the <literal>libata</literal> kernel module, create
|
||||
<literal>/etc/modprobe.d/local.conf</literal> file with the following line:
|
||||
<filename>/etc/modprobe.d/local.conf</filename> file with the following line:
|
||||
</para>
|
||||
<screen>
|
||||
options libata atapi_enabled=1
|
||||
</screen>
|
||||
<literallayout class="monospaced">options libata atapi_enabled=1
|
||||
</literallayout>
|
||||
<para>
|
||||
You can use any name ending in <literal>.conf</literal> for the
|
||||
configuration files in <literal>/etc/modprobe.d</literal> and put
|
||||
configuration files in <filename>/etc/modprobe.d</filename> and put
|
||||
multiple <literal>options</literal> lines in the same file.
|
||||
</para>
|
||||
<para>
|
||||
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 <literal>udev</literal>
|
||||
different kernel modules to operate. In such situation <command>udev</command>
|
||||
loads both kernel modules, with unpredictable results. To avoid this problem,
|
||||
you can prevent any module (let's say, <literal>tulip</literal>) from loading
|
||||
by creating a file containing the line:
|
||||
</para>
|
||||
<screen>
|
||||
blacklist tulip
|
||||
</screen>
|
||||
<literallayout class="monospaced">blacklist tulip
|
||||
</literallayout>
|
||||
<para>
|
||||
in <literal>/etc/modprobe.d</literal> directory. See the
|
||||
<literal>modprobe</literal> manual page (<literal>man modprobe</literal>) for
|
||||
in <filename>/etc/modprobe.d</filename> directory. See the
|
||||
<command>modprobe</command> manual page (<command>man modprobe</command>) for
|
||||
much more information on configuring and using modprobe.
|
||||
</para>
|
||||
</chapter>
|
||||
|
|
|
|||
|
|
@ -9,53 +9,53 @@ 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
|
||||
<literal>linux</literal>. The
|
||||
<literal>linux</literal> source package supports building of kernel images and
|
||||
<package>linux</package>. The
|
||||
<package>linux</package> 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
|
||||
<literal>linux</literal> source package.
|
||||
<package>linux</package> source package.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id="s-arch-indep"><title>Architecture-independent packages</title>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><literal>linux-source-<replaceable>version</replaceable></literal></term>
|
||||
<term><package>linux-source-<replaceable>version</replaceable></package></term>
|
||||
<listitem>
|
||||
<para>
|
||||
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 4.2.5-1 of the package <literal>linux-source-4.2</literal> contains
|
||||
version 4.2.5-1 of the package <package>linux-source-4.2</package> contains
|
||||
the version 4.2.5 of the Debian kernel source patched to patchlevel 1. Once
|
||||
the package is installed, the source tarball is available at
|
||||
<literal>/usr/src/linux-source-<replaceable>version</replaceable>.tar.xz</literal>.
|
||||
<filename>/usr/src/linux-source-<replaceable>version</replaceable>.tar.xz</filename>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>linux-manual-<replaceable>version</replaceable></literal></term>
|
||||
<term><package>linux-manual-<replaceable>version</replaceable></package></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This package contains the manual pages for the functions, constituting the
|
||||
kernel API. These pages are installed into
|
||||
<literal>/usr/share/man/man9/</literal>, and are accessible with the standard
|
||||
<literal>man</literal> command. Due to filename conflicts, only one
|
||||
<literal>linux-manual</literal> package may be installed at any given time.
|
||||
<filename>/usr/share/man/man9/</filename>, and are accessible with the standard
|
||||
<command>man</command> command. Due to filename conflicts, only one
|
||||
<package>linux-manual</package> package may be installed at any given time.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>linux-doc-<replaceable>version</replaceable></literal></term>
|
||||
<term><package>linux-doc-<replaceable>version</replaceable></package></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This package contains the rest of the kernel documentation in various formats.
|
||||
It is installed in
|
||||
<literal>/usr/share/doc/linux-doc-<replaceable>version</replaceable></literal>.
|
||||
<filename>/usr/share/doc/linux-doc-<replaceable>version</replaceable></filename>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>linux-support-<replaceable>version</replaceable>-<replaceable>abiname</replaceable></literal></term>
|
||||
<term><package>linux-support-<replaceable>version</replaceable>-<replaceable>abiname</replaceable></package></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This package contains the support files for building of out-of-tree modules for
|
||||
|
|
@ -106,17 +106,17 @@ together with a short description is given below.
|
|||
</para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><literal>linux-headers-<replaceable>version</replaceable>-<replaceable>abiname</replaceable>-common[-<replaceable>featureset</replaceable>]</literal></term>
|
||||
<term><package>linux-headers-<replaceable>version</replaceable>-<replaceable>abiname</replaceable>-common[-<replaceable>featureset</replaceable>]</package></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This package contains a common set of kernel headers for a particular
|
||||
featureset (or arch, if featureset is empty). Together with the
|
||||
flavour-specific <literal>linux-headers</literal> package it provides a full
|
||||
flavour-specific <package>linux-headers</package> 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
|
||||
<literal>/usr/src/linux-headers-<replaceable>version</replaceable>-<replaceable>abiname</replaceable>-common[-<replaceable>featureset</replaceable>]</literal>
|
||||
<filename>/usr/src/linux-headers-<replaceable>version</replaceable>-<replaceable>abiname</replaceable>-common[-<replaceable>featureset</replaceable>]</filename>
|
||||
directory.
|
||||
</para>
|
||||
</listitem>
|
||||
|
|
@ -124,15 +124,15 @@ directory.
|
|||
</variablelist>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><literal>linux-headers-<replaceable>version</replaceable>-<replaceable>abiname</replaceable>[-<replaceable>featureset</replaceable>]-<replaceable>flavour</replaceable></literal></term>
|
||||
<term><package>linux-headers-<replaceable>version</replaceable>-<replaceable>abiname</replaceable>[-<replaceable>featureset</replaceable>]-<replaceable>flavour</replaceable></package></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This package provides flavour-specific header files. It depends on the
|
||||
corresponding
|
||||
<literal>linux-headers-<replaceable>version</replaceable>-<replaceable>abiname</replaceable>-common[-<replaceable>featureset</replaceable>]</literal>
|
||||
<package>linux-headers-<replaceable>version</replaceable>-<replaceable>abiname</replaceable>-common[-<replaceable>featureset</replaceable>]</package>
|
||||
package, and sets up symbolic links into its directory tree in such a way that
|
||||
the directory
|
||||
<literal>/usr/src/linux-headers-<replaceable>version</replaceable>-<replaceable>abiname</replaceable>[-<replaceable>featureset</replaceable>]-<replaceable>flavour</replaceable></literal>
|
||||
<filename>/usr/src/linux-headers-<replaceable>version</replaceable>-<replaceable>abiname</replaceable>[-<replaceable>featureset</replaceable>]-<replaceable>flavour</replaceable></filename>
|
||||
appears to contain a full set of headers, required for building of out-of-tree
|
||||
kernel modules. For more information on this check out <xref
|
||||
linkend="s-common-out-of-tree"/>. A complete set of kernel headers matching the
|
||||
|
|
@ -144,18 +144,18 @@ apt-get install linux-headers-$(uname -r)
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>linux-image[-<replaceable>featureset</replaceable>]-<replaceable>flavour</replaceable></literal></term>
|
||||
<term><literal>linux-headers[-<replaceable>featureset</replaceable>]-<replaceable>flavour</replaceable></literal></term>
|
||||
<term><package>linux-image[-<replaceable>featureset</replaceable>]-<replaceable>flavour</replaceable></package></term>
|
||||
<term><package>linux-headers[-<replaceable>featureset</replaceable>]-<replaceable>flavour</replaceable></package></term>
|
||||
<listitem>
|
||||
<para>
|
||||
These virtual packages provide (via dependencies) the latest binary image and
|
||||
matching set of header files (respectively) for a particular flavour. Example:
|
||||
<literal>linux-image-rt-686-pae</literal>
|
||||
<package>linux-image-rt-686-pae</package>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>linux-image-<replaceable>version</replaceable>-<replaceable>abiname</replaceable>[-<replaceable>featureset</replaceable>]-<replaceable>flavour</replaceable></literal></term>
|
||||
<term><package>linux-image-<replaceable>version</replaceable>-<replaceable>abiname</replaceable>[-<replaceable>featureset</replaceable>]-<replaceable>flavour</replaceable></package></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This package contains the binary kernel image and pre-built binary modules for
|
||||
|
|
@ -165,7 +165,7 @@ files for the <literal>i386</literal> architecture are:
|
|||
</para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><literal>/boot/vmlinuz-<replaceable>version</replaceable>-<replaceable>abiname</replaceable>[-<replaceable>featureset</replaceable>]-<replaceable>flavour</replaceable></literal></term>
|
||||
<term><filename>/boot/vmlinuz-<replaceable>version</replaceable>-<replaceable>abiname</replaceable>[-<replaceable>featureset</replaceable>]-<replaceable>flavour</replaceable></filename></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The binary (compressed) kernel image.
|
||||
|
|
@ -173,7 +173,7 @@ The binary (compressed) kernel image.
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>/boot/initrd.img-<replaceable>version</replaceable>-<replaceable>abiname</replaceable>[-<replaceable>featureset</replaceable>]-<replaceable>flavour</replaceable></literal></term>
|
||||
<term><filename>/boot/initrd.img-<replaceable>version</replaceable>-<replaceable>abiname</replaceable>[-<replaceable>featureset</replaceable>]-<replaceable>flavour</replaceable></filename></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Initial RAM filesystem (initramfs) image. Note, that this file is
|
||||
|
|
@ -184,7 +184,7 @@ linkend="ch-initramfs"/> for more details.
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>/boot/config-<replaceable>version</replaceable>-<replaceable>abiname</replaceable>[-<replaceable>featureset</replaceable>]-<replaceable>flavour</replaceable></literal></term>
|
||||
<term><filename>/boot/config-<replaceable>version</replaceable>-<replaceable>abiname</replaceable>[-<replaceable>featureset</replaceable>]-<replaceable>flavour</replaceable></filename></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The kernel configuration file used to build this particular kernel. May be
|
||||
|
|
@ -193,7 +193,7 @@ used to rebuild the kernel from source, if necessary.
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>/lib/modules/<replaceable>version</replaceable>-<replaceable>abiname</replaceable>[-<replaceable>featureset</replaceable>]-<replaceable>flavour</replaceable>/</literal></term>
|
||||
<term><filename>/lib/modules/<replaceable>version</replaceable>-<replaceable>abiname</replaceable>[-<replaceable>featureset</replaceable>]-<replaceable>flavour</replaceable>/</filename></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Directory containing the pre-built binary kernel modules.
|
||||
|
|
@ -204,7 +204,7 @@ Directory containing the pre-built binary kernel modules.
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>linux-libc-dev</literal></term>
|
||||
<term><package>linux-libc-dev</package></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This package provides Linux kernel headers for use by userspace programs, such
|
||||
|
|
|
|||
|
|
@ -16,9 +16,9 @@ Note that this is a work in progress, and some information is inaccurate.
|
|||
<para>
|
||||
Some of the commands mentioned in the text must be executed with superuser
|
||||
priviliges, either by becoming the <literal>root</literal> user or by using
|
||||
<literal>sudo</literal>. To distinguish between commands which may be executed
|
||||
<command>sudo</command>. To distinguish between commands which may be executed
|
||||
by an unprivileged user and those requiring superuser privileges, commands are
|
||||
prepended by <literal>$</literal> or <literal>#</literal> respectively. This
|
||||
prepended by <prompt>$</prompt> or <prompt>#</prompt> respectively. This
|
||||
symbol is not a part of the command.
|
||||
</para>
|
||||
</section>
|
||||
|
|
@ -33,7 +33,7 @@ url="https://anonscm.debian.org/gitweb/?p=kernel-handbook/kernel-handbook.git">g
|
|||
repository</ulink>. 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
|
||||
<literal>kernel-handbook-general@lists.alioth.debian.org</literal> mailing
|
||||
<email>kernel-handbook-general@lists.alioth.debian.org</email> 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
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ licensing restrictions, unclear license information, or failure to comply with
|
|||
the Debian Free Software Guidelines (DFSG), parts of the kernel are removed in
|
||||
order to distribute the source in the <literal>main</literal> section of the
|
||||
Debian archive. Such removal produces
|
||||
<literal>linux_<replaceable>version</replaceable>.orig.tar.xz</literal> tarball,
|
||||
<filename>linux_<replaceable>version</replaceable>.orig.tar.xz</filename> tarball,
|
||||
which serves as the original upstream source. <replaceable>version</replaceable> is
|
||||
the actual upstream version.
|
||||
</para>
|
||||
|
|
@ -38,7 +38,7 @@ url="https://wiki.debian.org/KernelFirmwareLicensing">KernelFirmwareLicensing</u
|
|||
<para>
|
||||
The source from which the Debian binary kernels are built is obtained by taking
|
||||
the source from
|
||||
<literal>linux_<replaceable>version</replaceable>.orig.tar.xz</literal> (that is,
|
||||
<filename>linux_<replaceable>version</replaceable>.orig.tar.xz</filename> (that is,
|
||||
pristine kernel source with problematic parts removed) and applying a set of
|
||||
Debian patches. These patches typically implement essential fixes for serious
|
||||
bugs and security holes. The Debian version of the kernel packages has the
|
||||
|
|
@ -46,7 +46,7 @@ form <replaceable>version</replaceable><literal>-</literal><replaceable>revision
|
|||
<replaceable>version</replaceable> is the upstream version of the
|
||||
kernel (like 3.2.20) and <replaceable>revision</replaceable>
|
||||
determines the patchlevel. For example, the packages with version 3.2.20-1 are
|
||||
built from the <literal>linux_3.2.20.orig.tar.xz</literal> source, patched up
|
||||
built from the <filename>linux_3.2.20.orig.tar.xz</filename> source, patched up
|
||||
to patchlevel 1. Certain packages include extra 'featuresets' not included in
|
||||
the upstream source, such as <literal>rt</literal>.
|
||||
</para>
|
||||
|
|
|
|||
|
|
@ -11,48 +11,46 @@ any requirements for them.
|
|||
<section id="s-kernel-hooks"><title>Kernel hooks</title>
|
||||
<para>
|
||||
The maintainer scripts in Linux kernel packages must use
|
||||
<literal>run-parts</literal> to invoke hook scripts in the corresponding
|
||||
subdirectory of <literal>/etc/kernel</literal>, e.g. the
|
||||
<command>run-parts</command> to invoke hook scripts in the corresponding
|
||||
subdirectory of <filename>/etc/kernel</filename>, e.g. the
|
||||
<literal>postinst</literal> script must invoke scripts in
|
||||
<literal>/etc/kernel/postinst.d</literal>.
|
||||
<filename>/etc/kernel/postinst.d</filename>.
|
||||
</para>
|
||||
<para>
|
||||
The arguments given to all kernel hook scripts are the kernel ABI version (the
|
||||
string that <literal>uname -r</literal> reports) and, optionally, the absolute
|
||||
string that <command>uname -r</command> reports) and, optionally, the absolute
|
||||
path to the kernel image. If the second argument is missing then the path is
|
||||
either <literal>/boot/vmlinuz-<replaceable>version</replaceable></literal> or
|
||||
<literal>/boot/vmlinux-<replaceable>version</replaceable></literal>, according to
|
||||
either <filename>/boot/vmlinuz-<replaceable>version</replaceable></filename> or
|
||||
<filename>/boot/vmlinux-<replaceable>version</replaceable></filename>, according to
|
||||
architecture convention. The environment variable
|
||||
<literal>DEB_MAINT_PARAMS</literal> will contain the arguments given to the
|
||||
<envar>DEB_MAINT_PARAMS</envar> will contain the arguments given to the
|
||||
kernel maintainer script, possibly single-quoted. In a shell script, this
|
||||
variable can be parsed using:
|
||||
</para>
|
||||
<screen>
|
||||
eval set -- "$DEB_MAINT_PARAMS"
|
||||
</screen>
|
||||
<literallayout class="monospaced">eval set -- "$DEB_MAINT_PARAMS"
|
||||
</literallayout>
|
||||
<para>
|
||||
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:
|
||||
</para>
|
||||
<screen>
|
||||
exec </dev/null >&2
|
||||
</screen>
|
||||
<literallayout class="monospaced">exec </dev/null >&2
|
||||
</literallayout>
|
||||
</section>
|
||||
|
||||
<section id="s-kernel-hooks-loader"><title>Kernel hooks required for boot loaders</title>
|
||||
<para>
|
||||
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
|
||||
<literal>/etc/kernel/postinst.d</literal> and
|
||||
<literal>/etc/kernel/postrm.d</literal>.
|
||||
<filename>/etc/kernel/postinst.d</filename> and
|
||||
<filename>/etc/kernel/postrm.d</filename>.
|
||||
</para>
|
||||
<para>
|
||||
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 <literal>zz-</literal> and no other packages may use this
|
||||
prefix or one that sorts later by the rules used by
|
||||
<literal>run-parts</literal>. A postrm hook script should warn but exit with
|
||||
<command>run-parts</command>. 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.
|
||||
</para>
|
||||
|
|
@ -73,8 +71,8 @@ install kernel hook scripts in order to update that menu.
|
|||
<para>
|
||||
Packages for boot loaders that need to be updated whenever the files they load
|
||||
are modified must also install hook scripts in
|
||||
<literal>/etc/initramfs/post-update.d</literal>. Initramfs builders must call
|
||||
these scripts using <literal>run-parts</literal> after they create, update or
|
||||
<filename>/etc/initramfs/post-update.d</filename>. Initramfs builders must call
|
||||
these scripts using <command>run-parts</command> after 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.
|
||||
</para>
|
||||
|
|
@ -88,8 +86,8 @@ must exit successfully.
|
|||
<section id="s-kernel-hooks-initramfs"><title>Kernel hooks required for initramfs builders</title>
|
||||
<para>
|
||||
Initramfs builders must install hook scripts in
|
||||
<literal>/etc/kernel/postinst.d</literal> and
|
||||
<literal>/etc/kernel/postrm.d</literal>, to create/update and delete the
|
||||
<filename>/etc/kernel/postinst.d</filename> and
|
||||
<filename>/etc/kernel/postrm.d</filename>, to create/update and delete the
|
||||
corresponding initramfs images. The postinst hook script must complete its
|
||||
work before returning.
|
||||
</para>
|
||||
|
|
@ -104,24 +102,24 @@ hooks may be invoked (in this order):
|
|||
<listitem>
|
||||
<para>
|
||||
A <literal>postinst_hook</literal> or <literal>postrm_hook</literal> command
|
||||
set by the user or the installer in <literal>/etc/kernel-img.conf</literal>
|
||||
set by the user or the installer in <filename>/etc/kernel-img.conf</filename>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
A hook script in <literal>/etc/initramfs/post-update.d</literal>
|
||||
A hook script in <filename>/etc/initramfs/post-update.d</filename>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
A hook script in <literal>/etc/kernel/postinst.d</literal> or
|
||||
...<literal>/postrm.d</literal>
|
||||
A hook script in <filename>/etc/kernel/postinst.d</filename> or
|
||||
...<filename>/postrm.d</filename>
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
<para>
|
||||
To avoid unnecessary updates, the hooks invoked at steps 1 and 2 may check
|
||||
whether <literal>$DPKG_MAINTSCRIPT_PACKAGE</literal> begins with
|
||||
whether <envar>$DPKG_MAINTSCRIPT_PACKAGE</envar> begins with
|
||||
<literal>linux-image-</literal> and do nothing in this case.
|
||||
</para>
|
||||
</section>
|
||||
|
|
@ -129,10 +127,10 @@ whether <literal>$DPKG_MAINTSCRIPT_PACKAGE</literal> begins with
|
|||
<section id="s-deprecation"><title>Deprecated features</title>
|
||||
<para>
|
||||
Kernel packages must not invoke boot loaders or initramfs builders
|
||||
except via hooks. If <literal>/etc/kernel-img.conf</literal> contains
|
||||
except via hooks. If <filename>/etc/kernel-img.conf</filename> contains
|
||||
<literal>do_bootloader = yes</literal> or equivalent, maintainer
|
||||
scripts that previously acted on this must warn that they are ignoring
|
||||
it. <literal>linux-base</literal> must also warn on upgrade that the
|
||||
it. <package>linux-base</package> must also warn on upgrade that the
|
||||
default has changed.
|
||||
</para>
|
||||
</section>
|
||||
|
|
@ -141,7 +139,7 @@ default has changed.
|
|||
<para>
|
||||
The installer must not define <literal>do_bootloader</literal>,
|
||||
<literal>postinst_hook</literal> or <literal>postrm_hook</literal> in
|
||||
<literal>/etc/kernel-img.conf</literal>.
|
||||
<filename>/etc/kernel-img.conf</filename>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ It is not changed for every new package version. The
|
|||
</variablelist>
|
||||
<para>
|
||||
Many programs parse the kernel version string reported by the
|
||||
<literal>uname</literal> system call or command and expect to find at least 3
|
||||
<command>uname</command> 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.
|
||||
</para>
|
||||
|
|
@ -66,7 +66,7 @@ changed when the ABI between the kernel and modules changes.
|
|||
In official kernel packages, we change the <replaceable>abiname</replaceable>
|
||||
part of the kernel version to mark ABI changes that aren't due to a new
|
||||
upstream version. This part comes from the <literal>abiname</literal> setting
|
||||
in <literal>debian/config/defines</literal>. We use either a number or 'trunk'
|
||||
in <filename>debian/config/defines</filename>. We use either a number or 'trunk'
|
||||
(for experimental), but for a custom package it should be some other string.
|
||||
</para>
|
||||
</section>
|
||||
|
|
@ -82,10 +82,10 @@ depend on that part of the ABI.
|
|||
<para>
|
||||
Bug fixes or configuration changes to the kernel may alter the ABI. If an
|
||||
exported function is conditional on
|
||||
<literal>CONFIG_</literal><replaceable>FOO</replaceable>, or it uses a type
|
||||
<symbol>CONFIG_<replaceable>FOO</replaceable></symbol>, or it uses a type
|
||||
whose definition depends on
|
||||
<literal>CONFIG_</literal><replaceable>FOO</replaceable>, then turning
|
||||
<literal>CONFIG_</literal><replaceable>FOO</replaceable> on or off changes the
|
||||
<symbol>CONFIG_<replaceable>FOO</replaceable></symbol>, then turning
|
||||
<symbol>CONFIG_<replaceable>FOO</replaceable></symbol> 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.
|
||||
|
|
@ -99,17 +99,17 @@ set of symbol versions represents the kernel ABI.
|
|||
</para>
|
||||
<para>
|
||||
We collect the symbol versions for previously uploaded packages under the
|
||||
directory <literal>debian/abi</literal> and then compare the new kernel with
|
||||
directory <filename>debian/abi</filename> 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.
|
||||
</para>
|
||||
<para>
|
||||
If the kernel ABI has changed you must then change the ABI name in
|
||||
<literal>debian/config/defines</literal>. Then run the command
|
||||
<filename>debian/config/defines</filename>. Then run the command
|
||||
</para>
|
||||
<screen>
|
||||
$ fakeroot debian/rules debian/control-real
|
||||
<prompt>$</prompt> <userinput>fakeroot debian/rules debian/control-real</userinput>
|
||||
</screen>
|
||||
<para>
|
||||
to regenerate the package definitions for this ABI name.
|
||||
|
|
|
|||
1
debian/changelog
vendored
1
debian/changelog
vendored
|
|
@ -8,6 +8,7 @@ kernel-handbook (1.0.17) UNRELEASED; urgency=medium
|
|||
* Convert all source files to DocBook format
|
||||
- Makefile,debian/control: Use xmlto to build from DocBook
|
||||
- Update Japanese translation for the format conversion
|
||||
- Use a richer set of markup elements
|
||||
* Remove statement that the final '.0' will be removed from upstream versions
|
||||
* Update 'Linus version format' to begin with 4
|
||||
* Remove references to Debian 6.0 and earlier releases, and the linux-2.6
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
Loading…
Add table
Reference in a new issue