[ 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 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 is also a frozen 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 Woody (3.0r0), are recorded into the stable (symlink to woody/) directory:

Now, in addition to the above locations, new 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 Sarge, are recorded into the testing (symlink to sarge/) directory after they have undergone some degree of testing in unstable. Now, in addition to the above locations, new 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 mustn't have dependencies that make them uninstallable; they also have to 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://ftp-master.debian.org/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/. New 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". (The recent Woody release process did not create a symbolic link frozen/, so frozen was not a distribution but just a development stage of the testing distribution.)

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 woody/ and sarge/, 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 a real directory like unstable suddenly changed its name to stable/, a lot of stuff would have to be needlessly downloaded again).

Currently, stable/ is a symbolic link to woody/, and testing/ is a symbolic link to sarge/. This means that Woody is the current stable distribution and Sarge 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

Other 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, and "Potato" for release 2.2.


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. Also, at the time of writing, older distributions have not been converted to use pools, so you'll see paths containing distribution names such as potato or woody in the "Directory" header field.

Normally, you won't have to worry about any of this, as new apt and probably older dpkg-ftp (see Methods for upgrading a Debian system, Section 2.3.1) 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. For those architectures not yet released, the first time they were released 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 for testing and unstable 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.9 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 carefully designed 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 send 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(8) 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_VersionNumber-DebianRevisionNumber.deb

where foo represents the package name. As a check, one can determine the package name associated with a particular Debian archive file (.deb file) in one of these ways:

The VVV component is the version number specified by the upstream developer. There are no standards governing version numbers, so they may have formats as different as "19990513" and "1.3.8pre1".

The RRR component is the Debian revision number, and is specified by the Debian developer (or an individual user if he chooses to build the package himself). This number corresponds to the revision level of the Debian package; thus, a new revision level usually signifies changes in the Debian makefile (debian/rules), the Debian control file (debian/control), the installation or removal scripts (debian/p*), or the configuration files used with the package.


2.2.4 Preservation of the local configuration

Preservation of user-configurable files is enabled through Debian's "conffiles" mechanism. User configuration files (usually placed in /etc/) are specified in the conffiles within the Debian package system. The package management system guarantees not to overwrite these files when the package is upgraded.

When it is possible to configure the system without modifying files that belong to various Debian packages, it is usually a good idea not to modify them even if they are "conffiles". This ensures faster and smoother upgrade operations.

To determine exactly which files are preserved during an upgrade, run:

     dpkg --status package

and look under "Conffiles:".

Specifics regarding the contents of a Debian conffiles file are provided in the Debian Policy Manual, section 11.7 (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 any dependency of a program that requires a news reader on a system in order to work or to be useful. They are therefore both said to provide the "virtual package" called news-reader.

Similarly, exim and sendmail both 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 depending on the installation of a mail transport agent will be satisfied by the existence of this virtual package.

Debian has a mechanism so 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 package system has a range of package "dependencies" which are designed to indicate (in a single flag) the level at which Program A can operate independently of the existence of Program B on a given system:

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

Note that dselect has 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"

"Pre-depends" is a special dependency. In the case of an ordinary package, dpkg will unpack its archive file (i.e., its .deb file) independently of whether or not the files on which it depends exist on the system. Unpacking basically means that dpkg will extract the files from the archive file that were meant to be installed on your filesystem, and put them in place. If those packages depend on the existence of some other packages on your system, dpkg will refuse to complete the installation (by executing its "configure" action) until the other packages are installed.

However, there are some packages that dpkg will refuse even to unpack until certain dependencies are resolved. Such packages are said to "pre-depend" on the presence of some other package(s). The Debian project provided this mechanism to support the safe upgrading of systems from a.out format to ELF format, where the order in which packages were unpacked was critical. There are other large upgrade situations where this method is useful, e.g., for packages with "required" priority and their libc dependency.

Once again, more detailed information about this can be found in the Packaging Manual.


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; Overview of /etc/apt/preferences, Section 6.2.8 also contains a brief explanation.


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 consistent upgrade path and a secure upgrade process, and we always do our best to make a new release smoothly upgradable from the previous ones. Packages will alert the user when there are important notices during the upgrade process, and will often provide a solution to a possible problem.

You should also read the Release Notes, the document that describes the details of specific upgrades, shipped on all Debian CDs, and 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 describes the fundamental details.


2.3.1 Methods for upgrading a Debian system

One can always simply execute an anonymous FTP or wget call to a Debian archive, peruse the directories until one finds a desired file, fetch it, and finally install it using dpkg. (Note that dpkg will install upgrade files in place, even on a running system.) Sometimes, however, a revised package will require the installation of a newly revised version of another package, in which case the installation will fail until/unless the other package is installed.

Many people find this manual approach much too time-consuming, since Debian evolves so quickly—typically, a dozen or more new packages are uploaded every week. This number is larger just before a new major release. To deal with this avalanche, many people prefer to use an automated program for upgrading. Several specialized package management tools are available for this purpose.


2.3.2 Package management tools overview

The Debian package management system has two objectives: the manipulation of the package file itself and the retrieval of package files from the Debian archive. dpkg performs the former task, APT and dselect the latter.


2.3.3 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.4 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.

For more information, install the apt package and read apt-get(8), apt-cache(8), apt-cdrom(8), apt.conf(5), sources.list(5), apt_preferences(5) (Woody), and /usr/share/doc/apt/guide.html/index.html.

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.5 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.3.

For more information, install the install-doc package and read /usr/share/doc/install-doc/dselect-beginner.en.html or dselect Documentation for Beginners.


2.3.6 Upgrading a running system

The kernel (filesystem) in Debian systems supports replacing files even while they're being used.

We also provide a program called start-stop-daemon which is used to start daemons at boot time or to stop daemons when the kernel runlevel is changed (e.g., from multiuser to single-user or to "halt"). The same program is used by installation scripts when a new package containing a daemon is installed, to stop running daemons, and to restart them as necessary.

Note that the Debian system does not require use of the single-user mode to upgrade a running system.


2.3.7 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.8 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 Unices, 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. This script runs all of the scripts in /etc/rcS.d/ by sourcing or forking a subprocess depending on their file extension to perform initialization such as checking and mounting file systems, loading modules, starting the network services, setting the clock, etc. Then, for compatibility, it also runs the files (except those with a `.' in the filename) in /etc/rc.boot/. Any scripts in the latter directory are usually reserved for system administrator use, and using them in packages is deprecated. See System initialization, Section 9.1 and System run levels and init.d scripts in the Debian Policy Manual for more info.


2.4.2 Runlevels

After completing the boot process, init executes all start scripts in a directory specified by the default runlevel (this runlevel is given by the entry for id in /etc/inittab). Like most System V compatible Unices, Linux has 7 runlevels:

Debian systems come with id=2, which indicates that the default runlevel will be 2 when the multiuser state is entered, and the scripts in /etc/rc2.d/ will be run.

In fact, the scripts in any of the directories /etc/rcN.d/ are just symbolic links back to scripts in /etc/init.d/. However, the names of the files in each of the /etc/rcN.d/ directories are selected to indicate the way the scripts in /etc/init.d/ will be run. Specifically, before entering any runlevel, all the scripts beginning with `K' are run; these scripts kill services. Then all the scripts beginning with `S' are run; these scripts start services. The two-digit number following the `K' or `S' indicates the order in which the script is run. Lower-numbered scripts are executed first.

This approach works because the scripts in /etc/init.d/ all take an argument which can be either "start", "stop", "reload", "restart" or "force-reload" and will then do the task indicated by the argument. These scripts can be used even after a system has been booted, to control various processes.

For example, with the argument "reload" the command

     # /etc/init.d/sendmail reload

sends the sendmail daemon a signal to reread its configuration file.


2.4.3 Customizing the boot process

Debian does not use a BSD-style rc.local directory to customize the boot process; instead it provides the following mechanism for customization.

Suppose a system needs to execute script foo on startup, or on entry to a particular (System V) runlevel. Then the system administrator should:

  1. Enter the script foo into the directory /etc/init.d/.
  1. Run the Debian command update-rc.d with appropriate arguments, to set up links between the (command-line-specified) directories rc?.d and /etc/init.d/foo. Here, ? is a number from 0 through 6 that corresponds to one of the System V runlevels.
  1. Reboot the system.

The command update-rc.d will set up links between files in the directories rc?.d and the script in /etc/init.d/. Each link will begin with an `S' or a `K', followed by a number, followed by the name of the script. When the system enters a runlevel N, scripts beginning with `K' in /etc/rcN.d/ are executed with stop as their argument, followed by those beginning with `S' in /etc/rcN.d/ with start as their argument.

One might, for example, cause the script foo to execute at boot-up, by putting it in /etc/init.d/ and installing the links with update-rc.d foo defaults 19. The argument defaults refers to the default runlevels, which are 2 through 5. The argument 19 ensures that foo is called before any scripts containing numbers 20 or larger.


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 (or all) 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, 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(8) 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 Alternative boot loaders

To employ alternative boot loaders such as grub or loadlin, copy the compiled Linux kernel bzimage to other locations (e.g., to /boot/grub or to an MS-DOS partition).


2.7.4 Custom boot floppies

The task of making a custom boot floppy is greatly aided by the Debian package boot-floppies, normally found in the admin section of the Debian FTP archive. Shell scripts in this package produce boot floppies in syslinux format. These are MS-DOS formatted floppies whose master boot records have been altered so that they directly boot Linux (or whatever other operating system has been defined in the syslinux.cfg file on the floppy). Other scripts in this package produce emergency root disks and can even reproduce the base disks.

You will find more information about this in the /usr/doc/boot-floppies/README file after installing the boot-floppies package.


2.7.5 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/lib/modules_help/) which provide detailed information on appropriate arguments for each of the modules. See The modularized 2.4 kernel, Section 7.2 for examples.


2.7.6 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

1.06-17, Sat Jan 31 07:56:05 UTC 2004

Osamu Aoki osamu@debian.org
Editor: David Sewell dsewell@virginia.edu
Authors, Section A.1