Chapter 2. Running Debian Installer

Table of Contents

2.1. Installation methods
2.2. The boot process
2.3. The Debian Installer Menu
2.4. Hooks provide additional flexibility
2.5. Some special tools
2.6. Automating the install using preseeding
2.7. Debugging the installer

The examples in this chapter are based on the CD-ROM and netboot installation methods for x86 (the amd64 and i386 architectures). The choice for x86 was made as this is most familiar to most users, but installations for other architectures are not structurally different[1].

The CD-ROM installation method also covers DVD, BD and the popular netinst images. Please note, that images for amd64 and i386 are built using isohybrid, so they can be used on optical media as well as on USB sticks.

So what are the basic steps when the installer is run? In any installation five stages can be distinguished:

  1. boot and initialization — setting up the installer so that it can load any additional components;
  2. loading additional components — expanding the installer to its full functionality;
  3. network configuration (unless already done in stage 1);
  4. partitioning;
  5. installing the target system.

The first three stages are where the fundamental difference between installation methods can be seen. All components (udebs) used there need to be included in the initrd with which the installer is booted.

The table below shows what components are involved in the first and second stage for the CD-ROM and netboot installation methods and also shows where these differ.

Stage CD-ROM NETBOOT Comments
- initrd-preseed Only if /preseed.cfg is present
1 localechooser Language/location/locale selection
1 console-setup Keyboard/keymap selection
1 cdrom-detect ethdetect Hardware detection and setup
1   netcfg Network configuration
- file-preseed network-preseed If selected at boot prompt
2   choose-mirror Mirror selection
2 load-cdrom (anna) download-installer (anna) Retrieve and unpack additional components
3 ethdetect   Hardware detection and setup
3 netcfg   Network configuration
3 choose-mirror   Mirror selection (only if the base system is not installable from CD)
3 clock-setup Set up clock and time zone

The remainder of the installation is basically the same for all installation methods.

Stage   Comments
4 hw-detect Additional hardware detection
4 partman Partitioning, file system creation and mount point selection
5 base-installer Base system (debootstrap) & kernel installation
5 user-setup Set up root and normal user accounts
5 apt-setup APT configuration in the target system (sources.list)
5 pkgsel Select and install additional packages (tasksel)
5 grub-installer; nobootloader Boot loader installation
5 finish-install Finish up the installation and reboot

2.1. Installation methods

The installer supports a lot of different installation methods and in some cases installation methods can be creatively combined. The definition of an installation method is based on the following questions.

  • How is the installer booted?
  • From where are additional udebs retrieved?
  • From where are packages needed to install the base system retrieved?
  • From where are packages needed to install tasks retrieved[2]?

The table below shows the answers to these questions for the most common installation methods.

Method Boot Udebs Base system Tasks
netboot network (TFTP server) network network network
mini.iso CD network network network
netinst CD CD CD CD network
full CD/DVD/BD CD CD CD CD (+ network)
hd-mediaa) harddisk/USB stick CD image CD image/network CD image/network

a) Whether packages for the base system and tasks are retrieved from CD (image) or the network depends on the type of CD used in combination with these boot methods.

2.2. The boot process

The boot process for the installer is similar to the boot of a regular system. A bootloader (in some cases the system's firmware) is responsible for loading the kernel and loading the initrd after which init is started. The boot process can be debugged by adding the BOOT_DEBUG parameter.

It is possible to pass additional kernel and boot parameters. Kernel parameters are sometimes needed to get non-conformant hardware supported, or to install from serial console instead of an attached keyboard/display.

Boot parameters can also be used to influence the installer itself. More about this in the section on preseeding.

The boot process is quite complex as it has evolved needing to support several generations of linux, with changes in e.g. the kernel and udev.

The following enumeration gives an overview of the main steps in the boot process.

1) /init (initramfs) or /sbin/init (initrd)

Sets up initial environment (/proc, /dev; run udev)

2) busybox init

/etc/inittab is parsed; this contains:

  • ::sysinit:/sbin/debian-installer-startup
  • ::respawn:/sbin/debian-installer
  • init for VT2 and VT3 (busybox shell), and for VT4 (/var/log/syslog)

3) /sbin/debian-installer-startup

This is a run-parts like script that executes or sources scripts in /lib/debian-installer-startup.d. The main functions that are performed are:

  • mount devfs and sysfs
  • load acpi modules
  • start syslog
  • check available memory and, depending on preset limits, enable a lowmem mode if needed
  • load any debconf templates present in the initrd
  • parse boot parameters to look for debconf patterns (<component>/<template>=<value>) and set these in the debconf database
  • detect the type of console that is used
  • load framebuffer modules
  • detect if the installer should run in rescue mode

4) /sbin/debian-installer

This is a run-parts like script that sources scripts in /lib/debian-installer.d. These scripts will be run again if the main installer process dies for some reason. The main functions that are performed are:

  • detect if a framebuffer device is available
  • initialize the console (blanking, UTF-8)
  • select which debconf frontend is to be used (text, newt, gtk)
  • start main-menu (see next section)
  • halt or reboot the system (after main-menu exits)

See also Section B.1.1, “System boot”.

2.3. The Debian Installer Menu

The component main-menu drives the rest of the installation. It is responsible both for dynamically assembling the menu and for executing components when they are selected. Note that the menu is only actually visible when installing at low or medium debconf priority. At higher priorities it is still there, but it will automatically execute the next component without showing the menu to the user.

In some situations the debconf priority is automatically changed. It is reduced when the execution of a component fails, or when the user uses the <Go Back> button to back out all the way to the menu. In these cases it will also be increased back to the original level when the next component executed finishes successfully.

An important characteristic of udebs is that execution of their postinst scripts is delayed. On installation udebs are only unpacked; the execution of the postinst is done by main-menu and is actually what happens when a component is selected in the menu. In other words, main-menu can be said to be responsible for configuring the udeb.

For a component to be included in the menu, it needs to have an Installer-Menu-Item line in the dpkg status file (/var/lib/dpkg/status). The order of components in the menu is determined primarily by its dependencies; the menu item number is used only where the order for two or more components cannot be resolved by dependencies alone.

Provides can be used to define virtual states which other components can depend on, as shown in the next example.

Package: netcfg
Status: install ok installed
Version: 1.52
Provides: configured-network
Depends: libc6-udeb (>= 2.10), libdebconfclient0-udeb,
         libdebian-installer4-udeb (>= 0.69), libiw30-udeb (>= 30~pre1),
Description: Configure the network
Installer-Menu-Item: 1800

Package: choose-mirror
Status: install ok unpacked
Version: 2.32
Depends: configured-network, choose-mirror-bin
Description: Choose mirror to install from
Installer-Menu-Item: 2300

This example also shows that netcfg has been run successfully (installed) while mirror selection has not yet taken place (unpacked).

Some components are included in the menu but are not run by default. These components have a menu number higher than 90000 and are listed after finish-install in the menu. Examples are components that allow to change the debconf priority, to save debug logs, to check the integrity of a CD-ROM or to abort the installation.

2.4. Hooks provide additional flexibility

At certain points in the installation, components provide run-parts like execution of scripts. This allows other components to just drop scripts there so that commands can be run at that point in the installation, even though the postinst for the component itself is run earlier or later (if the component even has a postinst).

An overview of available hooks can be found in Appendix B, Available hooks. The most relevant are the Section B.1.2, “General purpose run-parts hooks”.

Besides these general hooks, partman is basically structured as one big collection of hooks where partman components all drop their own scriptlets to extend partman's functionality. The most noteworthy of these hooks is /lib/partman/finish.d as some bootloaders drop scripts there to add checks that ensure the selected partitioning scheme conforms to their requirements.

2.5. Some special tools

The installer has some special commands which can be used in postinst or preseeding scripts:


Used to install additional, non-standard d-i components (udebs). It will check if anna has already been run. If it has, the component is unpacked immediately; if it has not, it will be scheduled for installation when anna is run.


Performs the same function for normal packages and installs them in the target system. Packages will either be installed immediately (if called after base-installer) or scheduled for installation as one of the extra packages installed near the end of base-installer's postinst script.


Allows to run a command and redirect its output (either stdout or stderr or both) to /var/log/syslog.


Allows to run a command in a chroot on /target with the chroot being set up for more demanding operations. For example, proc and sysfs are mounted and a policy-rc.d is created. Can obviously only be used after the base system has been set up.

See the README in the source for debian-installer-utils for more detailed information.

2.6. Automating the install using preseeding

There are three preconfiguration methods that are currently supported:

initrd preseeding

The preconfiguration file /preseed.cfg needs to be present in the initrd. It is read as part of the debian-installer-startup processing.

file preseeding

Triggered by the presence of the preseed/file boot parameter.

network preseeding

Triggered by the presence of the preseed/url boot parameter. It is also possible to trigger this from the DHCP server.

Which of these methods is available depends on the installation method.

The main purpose of preseeding is to set default values for debconf questions. Note that it makes no sense when using file or network preseeding to preseed values for questions that are asked before the preconfiguration file is parsed.

Besides offering the option to set default values for debconf questions, preseeding also makes it possible to run scripts at two distinct moments using preseed/early_command and preseed/late_command. The early_command is executed immediately after the preconfiguration file is parsed (only for file and network preseeding); the late_command is executed as part of the finish-install component.

These scripts can be made as complex as you like. One option is to use them to install additional packages on the target system (using apt-install). The early_command could be used to install additional d-i components (using anna-install) or to install scripts in the various hook script directories (if commands need to be executed at a specific point in the installation).

Additional information about preseeding is available in an appendix of the Installation Guide.

2.7. Debugging the installer

Because most of the installer is scripted, it is fairly easy to debug most problems by adding a set -x in the correct place. The obvious place to start is the postinst of the component you want to debug. The output will appear in /var/log/syslog, which can most easily be viewed by starting the internal webserver from the Save debug logs menu option (after the network has been configured).

For components written in C debugging is a bit harder. Options are to use the strace udeb (add it to a custom image if needed) or to create a custom version of a component with added debug statements in the source and use that.

For debugging, you will probably want to control when components are started. Booting the installer with install debconf/priority=medium is a good way to achieve that. It will make sure the menu is displayed before a new component is started.

If you boot the installer at medium priority, you will also be able to load the optional component openssh-client-udeb[3]. Loading this component will allow you to use scp to copy files from the system being installed to another computer and vice versa. Also useful for testing new versions of scripts or commands without rebuilding the udeb and image. The command nc from the netcat package is available by default in the installer.

[1] Some architectures may use specific additional components as part of their default installation. However, this does not make them structurally different.

[2] The last question can also be rephrased as what source lines are set up in the /etc/apt/sources.list file for the target system.

[3] If you want to load optional components when installing at the default priority, you need to back out to the menu, change the debconf priority to medium or low, and then select the component that installs additional installer components. After you've installed the desired components, the debconf priority can then be changed back to its original value.