[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ next ]

Debian Reference
Chapter 2 - Debian fundamentals

This chapter provides fundamental information on the Debian system for non-developers. For authoritative information, see:

listed under References, Section 15.1.

If you are looking for less detailed "how-to" explanations, jump directly to Debian package management, Chapter 6 or other relevant chapters.

This chapter is based on documents taken from the "Debian FAQ", greatly reorganized to allow the ordinary Debian system administrator to get started.

2.1 The Debian archives

2.1.1 Directory structures

The software that has been packaged for Debian is available in one of several directory trees on each Debian mirror site through FTP or HTTP.

The following directories can be found on each Debian mirror site under the debian directory:

dists/:

This directory contains the "distributions", and this used to be the canonical way to access the currently available packages in Debian releases and pre-releases. Some old packages, the Contents-*.gz and Packages.gz files are still in here.

pool/:

The new physical location for all packages of Debian releases and pre-releases.

tools/:

DOS utilities for creating boot disks, partitioning your disk drive, compressing/decompressing files, and booting Linux.

doc/:

The basic Debian documentation, such as the FAQ, the bug reporting system instructions, etc.

indices/:

The Maintainers file and the override files.

project/:

mostly developer-only materials, such as:

project/experimental/:

This directory contains packages and tools which are still being developed, and are still in the alpha testing stage. Users shouldn't be using packages from here, because they can be dangerous and harmful even for the most experienced.

project/orphaned/:

Packages that have been orphaned by their old maintainers, and withdrawn from the distribution.

2.1.2 Debian distributions

Normally there are three Debian distributions in the dists directory. They are named the stable distribution, the testing distribution, and the unstable distribution. Sometimes there was also a frozen distribution (currently it is just a development stage of the testing distribution). Each distribution is defined as a symlink to the actual directory with a codename in the dists directory.

2.1.3 The stable distribution

Package entries for the stable distribution, Debian Sarge (3.1r0), are recorded into the stable (symlink to sarge/) directory:

Now, in addition to the above locations, nowadays physical packages are located under the pool directory (The pool directory, Section 2.1.10).

The current status of stable distribution bugs is reported on the Stable Problems web page.

2.1.4 The testing distribution

Package entries for the testing distribution, Debian Etch, are recorded into the testing (symlink to etch/) directory after they have undergone some degree of testing in unstable. Nowadays physical packages are located under the pool directory (The pool directory, Section 2.1.10). There are also main, contrib, and non-free subdirectories in testing/, which serve the same functions as in stable/.

These packages must be in sync on all architectures where they have been built and must be installable; they must also have fewer release-critical bugs than the versions currently in unstable. This way, we hope that testing is always close to being a release candidate. More details of the testing mechanism are at http://www.debian.org/devel/testing.

The latest status of the testing distribution is reported at these sites:

2.1.5 The unstable distribution

Package entries for the unstable distribution, always codenamed "Sid", are recorded into the unstable (symlink to sid/) directory after they are uploaded to the Debian archive and stay here until they are moved to testing/. Nowadays physical packages are located under the pool directory (The pool directory, Section 2.1.10). There are also main, contrib, and non-free subdirectories in unstable/, which serve the same functions as in stable/.

The unstable distribution contains a snapshot of the most current development system. Users are welcome to use and test these packages, but are warned about their state of readiness. The advantage of using the unstable distribution is that you are always up-to-date with the latest in the Debian software project—but if it breaks, you get to keep both parts. :-)

The current status of unstable distribution bugs is reported on the Unstable Problems web page.

2.1.6 The frozen distribution

When the testing distribution is mature enough, it becomes frozen, meaning no new code is accepted anymore, just bugfixes, if necessary. Also, a new testing tree is created in the dists directory, assigned a new codename. The frozen distribution passes through a few months of testing, with intermittent updates and deep freezes called "test cycles".

We keep a record of bugs in the frozen distribution that can delay a package from being released or bugs that can hold back the whole release. Once that bug count lowers to maximum acceptable values, the frozen distribution becomes stable, it is released, and the previous stable distribution becomes obsolete (and moves to the archive).

2.1.7 Debian distribution codenames

Physical directory names in the dists directory, such as sarge/ and etch/, are just "codenames". When a Debian distribution is in the development stage, it has no version number, but a codename instead. The purpose of these codenames is to make the mirroring of the Debian distributions easier. (If unstable would be a real directory and it's name would suddenly change to stable/, a lot of stuff would have to be needlessly downloaded again).

Currently, stable/ is a symbolic link to sarge/, and testing/ is a symbolic link to etch/. This means that Sarge is the current stable distribution and Etch is the current testing distribution.

unstable/ is a permanent symbolic link to sid/, as Sid is always the unstable distribution.

2.1.8 Codenames used in the past

Codenames that have already been used are: "Buzz" for release 1.1, "Rex" for release 1.2, "Bo" for releases 1.3.x, "Hamm" for release 2.0, "Slink" for release 2.1, "Potato" for release 2.2, "Woody" for release 3.0, and "Sarge" for release 3.1.

2.1.9 The source for codenames

So far they have been characters taken from the movie Toy Story by Pixar.

2.1.10 The pool directory

Historically, packages were kept in the subdirectory of dists corresponding to the distribution that contained them. This turned out to cause various problems, such as large bandwidth consumption on mirrors when major changes were made.

Packages are now kept in a large "pool", structured according to the name of the source package. To make this manageable, the pool is subdivided by section (main, contrib, and non-free) and by the first letter of the source package name. These directories contain several files: the binary packages for each architecture, and the source packages from which the binary packages were generated.

You can find out where each package is placed by executing a command like apt-cache showsrc mypackagename and looking at the "Directory:" line. For example, the apache packages are stored in pool/main/a/apache/. Since there are so many lib* packages, these are treated specially: for instance, libpaper packages are stored in pool/main/libp/libpaper/.

The dists directories are still used for the index files used by programs like apt.

Normally, you won't have to worry about any of this, as new apt and probably older dpkg-ftp will handle it seamlessly. If you want more information, see the RFC: implementation of package pools.

2.1.11 Historical notes about Sid

When the present-day Sid did not exist, the Debian archive site organization had one major flaw: there was an assumption that when an architecture was created in the current unstable/, it would be released when that distribution became the new stable. For many architectures that wasn't the case, with the result that those directories had to be moved at release time. This was impractical because the move would chew up lots of bandwidth.

The archive administrators worked around this problem for several years by placing binaries for unreleased architectures in a special directory called sid. When an architecture was released the first time there was a link from the current stable/ to sid/, and from then on they were created inside the unstable/ tree as usual. This layout was somewhat confusing to users.

With the advent of package pools (see The pool directory, Section 2.1.10) during the Woody distribution development, binary packages began to be stored in a canonical location in the pool, regardless of the distribution, so releasing a distribution no longer causes large bandwidth consumption on the mirrors (there is, however, a lot of gradual bandwidth consumption throughout the development process).

2.1.12 Uploaded packages in incoming/

Uploaded packages are first located at http://incoming.debian.org/ after being checked to insure that they really come from a Debian developer (and are put in the DELAYED subdirectory in the case of a Non-Maintainer Upload (NMU)). Once a day, they are moved out of incoming/ to unstable/.

In an emergency, you may want to install packages from incoming/ before they reach unstable/.

2.1.13 Retrieving an older package

While the most recent Debian distributions are kept under the debian directory on each Debian mirror site, archives for older Debian distributions such as Slink are kept on http://archive.debian.org/ or under the debian-archive directory on each Debian mirror site.

Older testing and unstable packages can be located at http://snapshot.debian.net/.

2.1.14 Architecture sections

Within each of the major directory trees (dists/stable/main, dists/stable/contrib, dists/stable/non-free, dists/unstable/main, etc.), the binary package entries reside in subdirectories whose names indicate the chip architecture for which they were compiled.

Please note that the actual binary packages no longer reside in these directories, but in the top-level pool directory. The index files (Packages and Packages.gz) have been kept, though, for backwards compatibility.

For the actual binary architectures supported, see the Release Notes for each distribution. They can be located at the Release Notes sites for stable and testing.

2.1.15 The source code

Source code is included for everything in the Debian system. Moreover, the license terms of most programs in the system require that source code be distributed along with the programs, or that an offer to provide the source code accompany the programs.

Normally the source code is distributed in the source directories, which are parallel to all the architecture-specific binary directories, or more recently in the pool directory (see The pool directory, Section 2.1.10). To retrieve the source code without having to be familiar with the structure of the Debian archive, try a command like apt-get source mypackagename.

Some packages, notably pine, are only available in a source package due to their licensing limitations. (Recently the pine-tracker package has been provided to facilitate Pine installation.) The procedures described in Port a package to the stable system, Section 6.4.10 and Packaging, Section 13.10 provide ways to build a package manually.

Source code may or may not be available for packages in the contrib and non-free directories, which are not formally part of the Debian system.

2.2 The Debian package management system

2.2.1 Overview of Debian packages

Packages generally contain all of the files necessary to implement a set of related commands or features. There are two types of Debian packages:

Installation of software by the package system uses "dependencies" which are declared by the package maintainers. These dependencies are documented in the control file associated with each package. For example, the package containing the GNU C compiler (gcc) Depends on the package binutils which includes the linker and assembler. If a user attempts to install gcc without having first installed binutils, the package management system (dpkg) will print an error message that it also needs binutils, and stop installing gcc. (However, this facility can be overridden by the insistent user; see dpkg(8).) For additional details, see Package dependencies, Section 2.2.8 below.

Debian's packaging tools can be used to:

2.2.2 Debian package format

A Debian "package", or a Debian archive file, contains the executable files, libraries, and documentation associated with a particular program suite or set of related programs. Normally, a Debian archive file has a filename that ends in .deb. [1]

The internals of this Debian binary package format are described in the deb(5) manual page. Because this internal format is subject to change (between major releases of Debian), always use dpkg-deb(1) for manipulating .deb files.

Through at least the Sarge distribution, all Debian archive files have been manipulable by the standard Unix commands ar and tar, even when dpkg commands are not available.

2.2.3 Naming conventions for Debian package filenames

The Debian package filenames conform to the following convention: 

     foo_ver-rev_arch.deb

where, usually, foo is the package name, ver is the upstream version number, rev is the Debian revision number, and arch is the target architecture. Files are easily renamed, of course. You can find out what package is really contained in any given file of name filename by running the following command: 

     dpkg --info filename

The Debian revision number is specified by the Debian developer or by whoever built the package. A change in revision number usually indicates that some aspect of the packaging has changed.

2.2.4 Preservation of local configuration

Files that are intended to be changeable by the local administrator are kept in /etc/. Debian policy dictates that all changes to locally configurable files be preserved across package upgrades.

If a default version of a locally configurable file is shipped in the package itself then the file is listed as a "conffile". The package management system does not upgrade conffiles that have been changed by the administrator since the package was last installed without getting the administrator's permission. On the other hand, if the conffile has not been changed by the administrator then the conffile will be upgraded along with the rest of the package. This is almost always desirable and so it is advantageous to minimize changes to conffiles.

To list the conffiles belonging to a package run the following command: 

     dpkg --status package

The list follows the "Conffiles:" line.

For more information about conffiles you can read the section of the Debian Policy Manual entitled "Configuration files". (See References, Section 15.1).

2.2.5 Debian maintenance scripts

Debian maintenance scripts are executable scripts which are automatically run before or after a package is installed. Along with a file named control, all of these files are part of the "control" section of a Debian archive file.

The individual files are:

preinst

This script executes before its package is unpacked from its Debian archive (.deb) file. Many "preinst" scripts stop services for packages which are being upgraded until their installation or upgrade is completed (following the successful execution of the "postinst" script).

postinst

This script typically completes any required configuration of a package once it has been unpacked from its Debian archive (.deb) file. Often, "postinst" scripts ask the user for input, and/or warn the user that if he accepts default values, he should remember to go back and reconfigure the package as the situation warrants. Many "postinst" scripts then execute any commands necessary to start or restart a service once a new package has been installed or upgraded.

prerm

This script typically stops any daemons which are associated with a package. It is executed before the removal of files associated with the package.

postrm

This script typically modifies links or other files associated with a package, and/or removes files created by it. (Also see Virtual packages, Section 2.2.7.)

Currently all of the control files can be found in the directory /var/lib/dpkg/info. The files relevant to package foo begin with the name "foo" and have file extensions of "preinst", "postinst", etc., as appropriate. The file foo.list in that directory lists all of the files that were installed with the package foo. (Note that the location of these files is a dpkg internal, and may be subject to change.)

2.2.6 Package priorities

Each Debian package is assigned a priority by the distribution maintainers, as an aid to the package management system. The priorities are:

Please note the differences among "Priority: required", "Section: base" and "Essential: yes" in the package description. "Section: base" means that this package is installed before everything else on a new system. Most of the packages in "Section: base" have the "Priority: required" or at least "Priority: important", and many of them are tagged with "Essential: yes". "Essential: yes" means that this package requires to specify an extra force option to the package management system such as dpkg when removing from the system. For example, libc6, mawk, and makedev are "Priority: required" and "Section: base" but are not "Essential: yes".

2.2.7 Virtual packages

A virtual package is a generic name that applies to any one of a group of packages, all of which provide similar basic functionality. For example, both the tin and trn programs are news readers, and either one should therefore satisfy the need of a program that requires a news reader on the system in order to be useful. They are therefore both said to Provide the "virtual package" called news-reader.

Similarly, many packages such as exim, exim4, sendmail, and postfix, provide the functionality of a mail transport agent. They are therefore said to Provide the virtual package mail-transport-agent. If either one is installed, then any program that Depends on the installation of a mail transport agent will be satisfied by the existence of this virtual package.

Debian has a mechanism such that, if more than one package which Provides the same virtual package is installed on a system, the system administrator can set one as the preferred package. The relevant command is update-alternatives, and is described further in Alternative commands, Section 6.5.3.

2.2.8 Package dependencies

The Debian packaging system handles dependency declarations which are used to express the fact that one package requires another package to be installed in order to work or in order to work better.

More detailed information on the use of each these terms can be found in the Packaging Manual and the Policy Manual.

Note that aptitude and dselect have more fine-grained control over packages specified by Recommends and Suggests than apt-get, which simply pulls all the packages specified by Depends and leaves all the packages specified by Recommends and Suggests. Both programs in modern form use APT as their back end.

2.2.9 The meaning of "Pre-Depends"

dpkg always configures a package upon which another package Depends before it configures the package that Depends on it. However, dpkg normally unpacks archive files in arbitrary order, independently of dependencies. (Unpacking consists of extracting files from the archive file and putting them in the right place.) If, however, a package Pre-Depends on another then the other package is unpacked and configured before the one that Pre-Depends is even unpacked. [2] The use of this dependency is kept to a minimum.

2.2.10 Package status

Package status can be "unknown", "install", "remove", "purge", or "hold". These "want" flags indicate what the user wanted to do with a package (either by making choices in the "Select" section of dselect, or by directly invoking dpkg).

Their meanings are:

2.2.11 Holding back packages from an upgrade

There are two mechanisms for holding back packages from an upgrade, through dpkg, or, beginning with Woody, through APT.

With dpkg, first export the list of package selections: 

     dpkg --get-selections \* > selections.txt

Then edit the resulting file selections.txt, changing the line containing the package you wish to hold, e.g. libc6, from this: 

     libc6                       install

to this: 

     libc6                       hold

Save the file, and reload it into dpkg database with: 

     dpkg --set-selections < selections.txt

Or, if you know the package name to hold, simply run: 

     echo libc6 hold | dpkg --set-selections

This procedure holds packages at the install process of each package file.

The same effect can be obtained through dselect. Simply enter the [S]elect screen, find the package you wish to hold in its present state, and press the `=' key (or `H'). The changes will take effect immediately after you exit the [S]elect screen.

The APT system in the Woody distribution has a new alternative mechanism for holding packages during the archive retrieval process using Pin-Priority. See the manual page apt_preferences(5), along with http://www.debian.org/doc/manuals/apt-howto/ or the apt-howto package.

2.2.12 Source packages

Source packages are distributed in a directory called source, and you can either download them manually, or use 

     apt-get source foo

to fetch them (see the apt-get(8) manual page on how to set up APT for doing that).

2.2.13 Building binary packages from a source package

For a package foo, you will need all of foo_*.dsc, foo_*.tar.gz, and foo_*.diff.gz to compile the source (note: there is no .diff.gz for a Debian native package).

Once you have them, if you have the dpkg-dev package installed, the command 

     $ dpkg-source -x foo_version-revision.dsc

will extract the package into a directory called foo-version.

Issue the following command to build the binary package: 

     $ cd foo-version
     $ su -c "apt-get update ; apt-get install fakeroot"
     $ dpkg-buildpackage -rfakeroot -us -uc

Then, 

     # su -c "dpkg -i ../foo_version-revision_arch.deb"

to install the newly built package. See Port a package to the stable system, Section 6.4.10.

2.2.14 Creating new Debian packages

For detailed information on creating new packages, read the New Maintainers' Guide, available in the maint-guide package, or at http://www.debian.org/doc/manuals/maint-guide/.

2.3 Upgrading a Debian system

One of Debian's goals is to provide a smooth, secure and reliable upgrade process. The packaging system alerts the administrator to important changes and sometimes asks the administrator to take decisions. You should also read the Release Notes; it is shipped on all Debian CDs and is available on the WWW at http://www.debian.org/releases/stable/releasenotes or http://www.debian.org/releases/testing/releasenotes.

A practical guide to upgrades is provided in Debian package management, Chapter 6. This section merely provides an outline, beginning with the packaging tools.

2.3.1 dpkg

This is the main program for manipulating package files; read dpkg(8) for a full description.

dpkg comes with several primitive supplemental programs.

dpkg-ftp and dpkg-mountable have been superseded by the introduction of the APT system.

2.3.2 APT

APT (the Advanced Packaging Tool) is an advanced interface to the Debian packaging system consisting of several programs whose names typically begin with "apt-". apt-get, apt-cache, and apt-cdrom are the command-line tools for handling packages. These also function as the user's "back end" programs to other tools, such as dselect and aptitude. Currently aptitude is the preferred tool for system maintenance.

For more information, install packages apt and aptitude and read aptitude(8), apt-get(8), apt-cache(8), apt-cdrom(8), apt.conf(5), sources.list(5), and apt_preferences(5).

An alternative source of information is the APT HOWTO. This can be installed by apt-howto at /usr/share/doc/Debian/apt-howto/.

apt-get upgrade and apt-get dist-upgrade pull only the packages listed under "Depends:" and overlook all the packages listed under "Recommends:" and "Suggests:". To avoid this, use dselect.

2.3.3 dselect

This program is a menu-driven user interface to the Debian package management system. It is particularly useful for first-time installations and large-scale upgrades. See dselect, Section 6.2.4.

For more information, read dselect Documentation for Beginners.

2.3.4 Upgrading a running system

The kernel (filesystem) in Debian systems supports replacing files even while they're being used. When packages are upgraded any services provided by those packages are restarted if they are configured to run in the current runlevel. The Debian system does not require use of the single-user mode to upgrade a running system.

2.3.5 Downloaded and cached .deb archive files

If you have manually downloaded package files to your disk (which is not absolutely necessary, see above for the description of dpkg-ftp or APT), then after you have installed the packages, you can remove the .deb files from your system.

If APT is used, these files are cached in the /var/cache/apt/archives directory. You may erase them after installation (apt-get clean) or copy them to another machine's /var/cache/apt/archives directory to save downloading during subsequent installations.

2.3.6 Record-keeping for upgrades

dpkg keeps a record of the packages that have been unpacked, configured, removed, and/or purged, but does not (currently) keep a log of terminal activity that occurred while a package was being so manipulated.

The simplest way to work around this is to run your dpkg, dselect, apt-get, etc., sessions within the script(1) program.

2.4 The Debian boot process

2.4.1 The init program

Like all Unixes, Debian boots up by executing the program init. The configuration file for init (which is /etc/inittab) specifies that the first script to be executed should be /etc/init.d/rcS.

What happens next depends on whether the sysv-rc package or the file-rc package is installed. The following assumes that the sysv-rc package is installed. (file-rc contains its own /etc/init.d/rcS script and uses a file instead of symlinks in rc directories to control which services are started in which runlevels.)

The /etc/init.d/rcS file from the sysv-rc package runs all of the scripts in /etc/rcS.d/ in order to perform initialization such as checking and mounting file systems, loading modules, starting the network services, setting the clock, and so on. Then, for compatibility, it also runs all the files (except those with a `.' in the filename) in /etc/rc.boot/. The latter directory is reserved for system administrator use, and using it is deprecated. See System initialization, Section 9.1 and System run levels and init.d scripts in the Debian Policy Manual for more info.

Debian does not use a BSD-style rc.local directory.

2.4.2 Runlevels

After completing the boot process, init starts all services that are configured to run in the default runlevel. The default runlevel is given by the entry for id in /etc/inittab. Debian ships with id=2.

Debian uses the following runlevels:

Runlevels 7, 8, and 9 can also be used but their rc directories are not populated when packages are installed.

Switch runlevels using the telinit command.

When entering a runlevel all scripts in /etc/rcrunlevel.d/ are executed. The first letter in the name of the script determines the way in which the script is run: scripts whose names begin with K are run with the argument stop. Scripts beginning with S are run with the argument start. The scripts are run in the alphabetical order of their names; thus "stop" scripts are run before "start" scripts and the two-digit numbers following the K or S determine the order in which the scripts are run.

The scripts in /etc/rcrunlevel.d are in fact just symbolic links back to scripts in /etc/init.d/. These scripts also accept "restart" and "force-reload" as argument; the latter methods can be used after a system has been booted in order to restart services or force them to reload their configuration files.

For example: 

     # /etc/init.d/exim4 force-reload

2.4.3 Customizing runlevels

Customizing runlevels is an advanced system administration task. The following advice holds for most services.

To enable service service in runlevel R create the symbolic link /etc/rcR.d/Sxyservice with target ../init.d/service. The sequence number xy should be the sequence number that was assigned to the service when the package was installed.

To disable the service, rename the symbolic link so that its name begins with a K instead of with an S and its sequence number is 100 minus xy.

It is convenient to use a runlevel editor such as sysv-rc-conf or ksysv for these purposes.

It is possible to delete the S symlink for a service in a particular runlevel directory instead of renaming it. This does not disable the service but leaves it in a "floating" state as far as the sysv-rc init system is concerned: on runlevel changes the service will be neither started nor stopped but will be left as it was, whether running or not running. Note, however, that a service left in such a floating state will be started if its package is upgraded whether or not it was running before the upgrade. This is a known shortcoming of the current Debian system. Note also that you should retain a service's K symlinks in runlevels 0 and 6. If you delete all the symlinks for a service then on upgrade the service's package will restore the symlinks to their factory default state.

It is not advisable to make any changes to symlinks in /etc/rcS.d/.

2.5 Supporting diversity

Debian offers several avenues to accommodate any wishes of the system administrator without breaking the system.

Any files under /usr/local/ belong to the system administrator and Debian will not touch them. Most files under /etc/ are conffiles and Debian will not overwrite them upon upgrade unless the system administrator requests so explicitly.

2.6 Internationalization

The Debian system is internationalized and provides support for character display and entry in many languages, both within the console and under X. Many documents, manual pages, and system messages have been translated into a growing number of languages. During installation, Debian prompts the user to choose an installation language (and sometimes a local language variant).

If your installed system does not support all the language features you need, or if you need to change languages or install a different keyboard to support your language, see Localization (l10n), Section 9.7.

2.7 Debian and the kernel

See The Linux kernel under Debian, Chapter 7.

2.7.1 Compiling a kernel from non-Debian source

One has to understand the Debian policy with respect to headers.

The Debian C libraries are built with the most recent stable releases of the kernel headers.

For example, the Debian-1.2 release used version 5.4.13 of the headers. This practice contrasts with the Linux kernel source packages distributed at all Linux FTP archive sites, which use even more recent versions of the headers. The kernel headers distributed with the kernel source are located in /usr/include/linux/include/.

If you need to compile a program with kernel headers that are newer than those provided by libc6-dev, then you must add -I/usr/src/linux/include/ to your command line when compiling. This came up at one point, for example, with the packaging of the automounter daemon (amd). When new kernels changed some internals dealing with NFS, amd needed to know about them. This required the inclusion of the latest kernel headers.

2.7.2 Tools to build custom kernels

Users who wish to (or must) build a custom kernel are encouraged to download the package kernel-package. This package contains the script to build the kernel package, and provides the capability to create a Debian kernel-image package just by running the command 

     # make-kpkg kernel_image

in the top-level kernel source directory. Help is available by executing the command 

     # make-kpkg --help

and through the manual page make-kpkg(1) and The Linux kernel under Debian, Chapter 7.

Users must separately download the source code for the most recent kernel (or the kernel of their choice) from their favorite Linux archive site, unless a kernel-source-version package is available (where version stands for the kernel version). The Debian initrd boot script requires a special kernel patch called initrd; see http://bugs.debian.org/149236.

Detailed instructions for using the kernel-package package are given in the file /usr/share/doc/kernel-package/README.gz.

2.7.3 Special provisions for dealing with modules

Debian's modconf package provides a shell script (/usr/sbin/modconf) which can be used to customize the configuration of modules. This script presents a menu-based interface, prompting the user for particulars on the loadable device drivers in his system. The responses are used to customize the file /etc/modules.conf (which lists aliases, and other arguments that must be used in conjunction with various modules) through files in /etc/modutils/, and /etc/modules (which lists the modules that must be loaded at boot time).

Like the (new) Configure.help files that are now available to support the construction of custom kernels, the modconf package comes with a series of help files (in /usr/share/modconf/) which provide detailed information on appropriate arguments for each of the modules.

2.7.4 De-installing an old kernel package

The kernel-image-NNN.prerm script checks to see whether the kernel you are currently running is the same as the kernel you are trying to de-install. Therefore you can safely remove unwanted kernel image packages using this command: 

     # dpkg --purge --force-remove-essential kernel-image-NNN

(Replace NNN with your kernel version and revision number, of course.)

[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ next ]

Debian Reference

CVS, Thu Jan 18 11:52:15 UTC 2007

Osamu Aoki osamu#at#debian.org
Authors, Section A.1