Automating the installation using preseeding
This appendix explains how to preseed answers to questions in &d-i; to
automate your installation.
The configuration fragments used in this appendix are also available as an
example preconfiguration file from &urlset-example-preseed;.
Introduction
Preseeding provides a way to set answers to questions asked during the
installation process, without having to manually enter the answers while
the installation is running. This makes it possible to fully automate most
types of installation and even offers some features not available during
normal installations.
Preseeding is not required. If you use an empty preseed file, the installer
will behave just the same way as in a normal manual installation. Each
question you preseed will (if you got it right!) modify the installation in
some way from that baseline.
Preseeding methods
There are three methods that can be used for preseeding:
initrd, file and
network. Initrd preseeding will work with any
installation method and supports preseeding of more things, but it requires
the most preparation. File and network preseeding each can be used with
different installation methods.
The following table shows which preseeding methods can be used with which
installation methods.
Installation methodinitrd
filenetwork
CD/DVD
yes
yes
yes
but only if you have network access, and set preseed/url
appropriately
netboot
yes
no
yes
hd-media (including usb-stick)
yes
yes
yes
floppy based (cd-drivers)
yes
yes
yes
floppy based (net-drivers)
yes
no
yes
generic/tape
yes
no
yes
An important difference between the preseeding methods is the point at which
the preconfiguration file is loaded and processed. For initrd preseeding
this is right at the start of the installation, before the first question is
even asked. For file preseeding this is after the CD or CD image has been
loaded. For network preseeding it is only after the network has been
configured.
Obviously, any questions that have been processed before the
preconfiguration file is loaded cannot be preseeded (this will include
questions that are only displayed at medium or low priority, like the
first hardware detection run).
offers a way to avoid these questions being asked.
In order to avoid the questions that would normally appear before the
preseeding occurs, you can start the installer in auto
mode. This delays questions that would normally be asked too early for
preseeding (i.e. language, country and keyboard selection) until after
the network comes up, thus allowing them to be preseeded. It also runs
the installation at critical priority, which avoids many unimportant
questions. See for details.
Limitations
Although most questions used by &d-i; can be preseeded using this method,
there are some notable exceptions. You must (re)partition an entire disk
or use available free space on a disk; it is not possible to use existing
partitions.
Using preseeding
You will first need to create a preconfiguration file and place it in
the location from where you want to use it. Creating the preconfiguration file
is covered later in this appendix. Putting it in the correct location is fairly
straightforward for network preseeding or if you want to read the file off
a floppy or usb-stick. If you want to include the file on a CD or DVD, you
will have to remaster the ISO image. How to get the preconfiguration file
included in the initrd is outside the scope of this document; please consult
the developers' documentation for &d-i;.
An example preconfiguration file that you can use as basis for your own
preconfiguration file is available from &urlset-example-preseed;. This file is
based on the configuration fragments included in this appendix.
Loading the preconfiguration file
If you are using initrd preseeding, you only have to make sure a file named
preseed.cfg is included in the root directory of the
initrd. The installer will automatically check if this file is present and
load it.
For the other preseeding methods you need to tell the installer what file
to use when you boot it. This is normally done by passing the kernel a boot
parameter, either manually at boot time or by editing the bootloader
configuration file (e.g. syslinux.cfg) and adding the
parameter to the end of the append line(s) for the kernel.
If you do specify the preconfiguration file in the bootloader configuration,
you might change the configuration so you don't need to hit enter to boot the
installer. For syslinux this means setting the timeout to 1
in syslinux.cfg.
To make sure the installer gets the right preconfiguration file, you can
optionally specify a checksum for the file. Currently this needs to be a
md5sum, and if specified it must match the preconfiguration file or the
installer will refuse to use it.
Boot parameters to specify:
- if you're netbooting:
preseed/url=http://host/path/to/preseed.cfg
preseed/url/checksum=5da499872becccfeda2c4872f9171c3d
- if you're booting a remastered CD:
preseed/file=/cdrom/preseed.cfg
preseed/file/checksum=5da499872becccfeda2c4872f9171c3d
- if you're installing from USB media (put the preconfiguration file in the
toplevel directory of the USB stick):
preseed/file=/hd-media/preseed.cfg
preseed/file/checksum=5da499872becccfeda2c4872f9171c3d
Note that preseed/url can be shortened to just
url and preseed/file to just
file when they are passed as boot parameters.
Using boot parameters to preseed questions
If a preconfiguration file cannot be used to preseed some steps, the
install can still be fully automated, since you can pass preseed values on
the command line when booting the installer.
Boot parameters can also be used if you do not really want to use preseeding,
but just want to provide an answer for a specific question. Some examples where
this can be useful are documented elsewhere in this manual.
To set a value to be used inside &d-i;, just pass
path/to/variable=value
for any of the preseed variables listed in the examples in this appendix.
If a value is to be used to configure packages for the target system, you
will need to prepend the owner
The owner of a debconf variable (or template) is normally the name of the
package that contains the corresponding debconf template. For variables
used in the installer itself the owner is d-i
.
Templates and variables can have more than one owner which helps to
determine whether they can be removed from the debconf database if the
package is purged.
of the variable as in
owner:path/to/variable=value.
If you don't specify the owner, the value for the variable will not be
copied to the debconf database in the target system and thus remain unused
during the configuration of the relevant package.
Normally, preseeding a question in this way will mean that the question will
not be asked. To set a specific default value for a question, but still have
the question asked, use ?=
instead of =
as
operator. See also .
Note that some variables that are frequently set at the boot prompt
have a shorter alias. If an alias is available, it is used in the
examples in this appendix instead of the full variable. The
preseed/url variable for example has been aliased as
url. Another example is the tasks
alias, which translates to tasksel:tasksel/first.
A --
in the boot options has special meaning. Kernel
parameters that appear after the last --
may be copied
into the bootloader configuration for the installed system (if supported by
the installer for the bootloader). The installer will automatically filter
out any options (like preconfiguration options) that it recognizes.
Current linux kernels (2.6.9 and later) accept a maximum of 32 command line
options and 32 environment options, including any options added by default
for the installer. If these numbers are exceeded, the kernel will panic
(crash). (For earlier kernels, these numbers were lower.)
For most installations some of the default options in your bootloader
configuration file, like vga=normal, may be safely
removed which may allow you to add more options for preseeding.
It may not always be possible to specify values with spaces for boot
parameters, even if you delimit them with quotes.
Auto mode
There are several features of Debian Installer that combine to allow
fairly simple command lines at the boot prompt to result in
arbitrarily complex customized automatic installs. To illustrate
this, here are some examples that can be used at the boot prompt:
auto url=autoserver
This relies on there being a DHCP server that will get the machine to
the point where autoserver can be resolved by DNS,
perhaps after adding the local domain if that was provided by DHCP.
If this was done at a site where the domain is
example.com, and they have a reasonably sane DHCP
setup, it would result in the preseed file being retrieved from
http://autoserver.example.com/d-i/etch/./preseed.cfg.
The last part of that url (d-i/etch/./preseed.cfg)
is taken from auto-install/defaultroot. By default
this includes the directory etch to allow future versions
to specify their own codename and let people migrate forwards in a
controlled manner. The /./ bit is used to indicate
a root, relative to which subsequent paths can be anchored (for use in
preseed/include and preseed/run). This allows files to be specified
either as full URLs, paths starting with / that are thus anchored, or
even paths relative to the location where the last preseed file was
found. This can be used to construct more portable scripts where an
entire hierarchy of scripts can be moved to a new location without
breaking it, for example copying the files onto a USB stick when they
started out on a web server. In this example, if the preseed file
sets preseed/run to
/scripts/late_command.sh then the file will be
fetched from
http://autoserver.example.com/d-i/etch/./scripts/late_command.sh.
If there is no local DHCP or DNS infrastructure, or if you do not want to
use the default path to preseed.cfg, you can still
use an explicit url, and if you don't use the /./
element it will be anchored to the start of the path (i.e. the third
/ in the URL). Here is an example that requires minimal
support from the local network infrastructure:
auto url=http://192.168.1.2/path/to/mypreseed.file
The way this works is that:
if the URL is missing a protocol, http is assumed,
if the hostname section contains no periods, it has the domain derived
from DHCP appended to it, and
if there's no /'s after the hostname, then the default
path is added.
In addition to specifying the url, you can also specify settings that
do not directly affect the behavior of &d-i; itself, but can be passed
through to scripts specified using preseed/run
in the loaded preseed file. At present, the only example of
this is auto-install/classes, which has an alias
classes. This can be used thus:
auto url=example.com classes=class_A;class_B
The classes could for example denote the type of system to be installed,
or the localization to be used.
It is of course possible to extend this concept, and if you do, it is
reasonable to use the auto-install namespace for this. So one might have
something like auto-install/style which is then used
in your scripts. If you feel the need to do this, please mention it on
the debian-boot@lists.debian.org mailing list so that we
can avoid namespace conflicts, and perhaps add an alias for the parameter
for you.
The auto boot label is not yet defined on all
architectures. The same effect may be achieved by simply adding the two
parameters auto=true priority=critical to the kernel
command line. The auto parameter is an alias for
auto-install/enable and controls the delay of the
locale and keyboard questions until after there has been a chance to
preseed them, while priority is an alias for
debconf/priority and setting it to
critical stops any questions with a lower priority
from being asked.
Additional options that may be of interest while attempting to
automate an install while using DHCP are: interface=auto
netcfg/dhcp_timeout=60 which makes the machine choose the
first viable NIC and be more patient about getting a reply to its
DHCP query.
An extensive example of how to use this framework, including example scripts
and classes, can be found on the website
of its developer. The examples available there also show many other
nice effects that can be achieved by creative use of preconfiguration.
Aliases useful with preseeding
The following aliases can be useful when using (auto mode) preseeding.
autoauto-install/enable
classesauto-install/classes
fbdebian-installer/framebuffer
localedebian-installer/locale
prioritydebconf/priority
filepreseed/file
urlpreseed/url
interfacenetcfg/choose_interface
hostname netcfg/get_hostname
domainnetcfg/get_domain
protocolmirror/protocol
suitemirror/suite
Using a DHCP server to specify preconfiguration files
It's also possible to use DHCP to specify a preconfiguration file to download
from the network. DHCP allows specifying a filename. Normally this is a file
to netboot, but if it appears to be an URL then installation media that
support network preseeding will download the file from the URL and use it as a
preconfiguration file. Here is an example of how to set it up in the dhcpd.conf
for version 3 of the ISC DHCP server (the dhcp3-server Debian package).
if substring (option vendor-class-identifier, 0, 3) = "d-i" {
filename "http://host/preseed.cfg";
}
Note that the above example limits this filename to DHCP clients that identify
themselves as "d-i", so it will not affect regular DHCP clients, but only
the installer. You can also put the text in a stanza for only one particular
host to avoid preseeding all installs on your network.
A good way to use the DHCP preseeding is to only preseed values specific to
your network, such as the Debian mirror to use. This way installs on your
network will automatically get a good mirror selected, but the rest of the
installation can be performed interactively. Using DHCP preseeding to fully
automate Debian installs should only be done with care.
Creating a preconfiguration file
The preconfiguration file is in the format used by the
debconf-set-selections command. The general format of
a line in a preconfiguration file is:
<owner> <question name> <question type> <value>
There are a few rules to keep in mind when writing a preconfiguration file.
Put only a single space or tab between type and value: any additional
whitespace will be interpreted as belonging to the value.
A line can be split into multiple lines by appending a backslash
(\
) as the line continuation character.
A good place to split a line is after the question name; a bad place is
between type and value.
For debconf variables (templates) used in the installer itself, the
owner should be set to d-i
; to preseed variables used
in the installed system, the name of the package that contains the
corresponding debconf template should be used. Only variables that have
their owner set to something other than d-i
will be
propagated to the debconf database for the installed system.
Most questions need to be preseeded using the values valid in English and
not the translated values. However, there are some questions (for example
in partman) where the translated values need to be
used.
Some questions take a code as value instead of the English text that is
shown during installation.
The easiest way to create a preconfiguration file is to use the example file
linked in as basis and work from there.
An alternative method is to do a manual installation and then, after
rebooting, use the debconf-get-selections from the
debconf-utils package to dump both the debconf
database and the installer's cdebconf database to a single file:
$ debconf-get-selections --installer > file
$ debconf-get-selections >> file
However, a file generated in this manner will have some items that should
not be preseeded, and the example file is a better starting place for most
users.
This method relies on the fact that, at the end of the installation, the
installer's cdebconf database is saved to the installed system in
/var/log/installer/cdebconf. However, because the
database may contain sensitive information, by default the files are only
readable by root.
The directory /var/log/installer and all files in it
will be deleted from your system if you purge the package
installation-report.
To check possible values for questions, you can use nano
to examine the files in /var/lib/cdebconf while an
installation is in progress. View templates.dat for
the raw templates and questions.dat for the current
values and for the values assigned to variables.
To check if the format of your preconfiguration file is valid before performing
an install, you can use the command debconf-set-selections -c
preseed.cfg.
Contents of the preconfiguration file (for &releasename;)
The configuration fragments used in this appendix are also available as an
example preconfiguration file from &urlset-example-preseed;.
Note that this example is based on an installation for the Intel x86
architecture. If you are installing a different architecture, some of the
examples (like keyboard selection and bootloader installation) may not be
relevant and will need to be replaced by debconf settings appropriate for
your architecture.
Localization
Setting localization values will only work if you are using initrd preseeding.
With all other methods the preconfiguration file will only be loaded after
these questions have been asked.
The locale can be used to specify both language and country.
To specify the locale as a boot parameter, use
locale=en_US.
# Locale sets language and country.
d-i debian-installer/locale string en_US
Keyboard configuration consists of selecting a keyboard architecture and a
keymap. In most cases the correct keyboard architecture is selected by
default, so there's normally no need to preseed it. The keymap must
be valid for the selected keyboard architecture.
# Keyboard selection.
#d-i console-tools/archs select at
d-i console-keymaps-at/keymap select us
# Example for a different keyboard architecture
#d-i console-keymaps-usb/keymap select mac-usb-us
To skip keyboard configuration, preseed
console-tools/archs with
skip-config.
This will result in the kernel keymap remaining active.
The changes in the input layer for 2.6 kernels have made the keyboard
architecture virtually obsolete. For 2.6 kernels normally a PC
(at) keymap should be selected.
Network configuration
Of course, preseeding the network configuration won't work if you're
loading your preconfiguration file from the network. But it's great when
you're booting from CD or USB stick. If you are loading preconfiguration
files from the network, you can pass network config parameters by using
kernel boot parameters.
If you need to pick a particular interface when netbooting before loading
a preconfiguration file from the network, use a boot parameter such as
interface=eth1.
Although preseeding the network configuration is normally not possible when
using network preseeding (using preseed/url
), you can use
the following hack to work around that, for example if you'd like to set a
static address for the network interface. The hack is to force the network
configuration to run again after the preconfiguration file has been loaded
by creating a preseed/run
script containing the following
commands:
killall.sh; netcfg
The following debconf variables are relevant for network configuration.
# netcfg will choose an interface that has link if possible. This makes it
# skip displaying a list if there is more than one interface.
d-i netcfg/choose_interface select auto
# To pick a particular interface instead:
#d-i netcfg/choose_interface select eth1
# If you have a slow dhcp server and the installer times out waiting for
# it, this might be useful.
#d-i netcfg/dhcp_timeout string 60
# If you prefer to configure the network manually, uncomment this line and
# the static network configuration below.
#d-i netcfg/disable_dhcp boolean true
# If you want the preconfiguration file to work on systems both with and
# without a dhcp server, uncomment these lines and the static network
# configuration below.
#d-i netcfg/dhcp_failed note
#d-i netcfg/dhcp_options select Configure network manually
# Static network configuration.
#d-i netcfg/get_nameservers string 192.168.1.1
#d-i netcfg/get_ipaddress string 192.168.1.42
#d-i netcfg/get_netmask string 255.255.255.0
#d-i netcfg/get_gateway string 192.168.1.1
#d-i netcfg/confirm_static boolean true
# Any hostname and domain names assigned from dhcp take precedence over
# values set here. However, setting the values still prevents the questions
# from being shown, even if values come from dhcp.
d-i netcfg/get_hostname string unassigned-hostname
d-i netcfg/get_domain string unassigned-domain
# Disable that annoying WEP key dialog.
d-i netcfg/wireless_wep string
# The wacky dhcp hostname that some ISPs use as a password of sorts.
#d-i netcfg/dhcp_hostname string radish
Mirror settings
Depending on the installation method you use, a mirror may be used to
download additional components of the installer, to install the base system,
and to set up the /etc/apt/sources.list for the installed
system.
The parameter mirror/suite determines the suite for
the installed system.
The parameter mirror/udeb/suite determines the suite
for additional components for the installer. It is only useful to set this
if components are actually downloaded over the network and should match the
suite that was used to build the initrd for the installation method used for
the installation.
By default the value for mirror/udeb/suite is the
same as mirror/suite.
# If you select ftp, the mirror/country string does not need to be set.
#d-i mirror/protocol string ftp
d-i mirror/country string manual
d-i mirror/http/hostname string &archive-mirror;
d-i mirror/http/directory string /debian
d-i mirror/http/proxy string
# Suite to install.
#d-i mirror/suite string testing
# Suite to use for loading installer components (optional).
#d-i mirror/udeb/suite string testing
Clock and time zone setup
# Controls whether or not the hardware clock is set to UTC.
d-i clock-setup/utc boolean true
# You may set this to any valid setting for $TZ; see the contents of
# /usr/share/zoneinfo/ for valid values.
d-i time/zone string US/Eastern
# Controls whether to use NTP to set the clock during the install
d-i clock-setup/ntp boolean true
# NTP server to use. The default is almost always fine here.
#d-i clock-setup/ntp-server ntp.example.com
Partitioning
Using preseeding to partition the harddisk is very much limited to what is
supported by partman-auto. You can choose to partition
either existing free space on a disk or a whole disk. The layout of the
disk can be determined by using a predefined recipe, a custom recipe from
a recipe file or a recipe included in the preconfiguration file. It is
currently not possible to partition multiple disks using preseeding.
The identification of disks is dependent on the order in which their drivers
are loaded. If there are multiple disks in the system, make very sure the
correct one will be selected before using preseeding.
# If the system has free space you can choose to only partition that space.
# Note: this must be preseeded with a localized (translated) value.
#d-i partman-auto/init_automatically_partition \
# select Guided - use the largest continuous free space
# Alternatively, you can specify a disk to partition. The device name must
# be given in traditional non-devfs format.
# For example, to use the first SCSI/SATA hard disk:
d-i partman-auto/disk string /dev/sda
# Note: If you want to use whatever disk is available, no matter
# what its device name, comment the line above out. This will only work if
# the system only has one disk.
# In addition, you'll need to specify the method to use.
# The presently available methods are: "regular", "lvm" and "crypto"
d-i partman-auto/method string lvm
# If one of the disks that are going to be automatically partitioned
# contains an old LVM configuration, the user will normally receive a
# warning. This can be preseeded away...
d-i partman-lvm/device_remove_lvm boolean true
# And the same goes for the confirmation to write the lvm partitions.
d-i partman-lvm/confirm boolean true
# You can choose from any of the predefined partitioning recipes.
# Note: this must be preseeded with a localized (translated) value.
d-i partman-auto/choose_recipe \
select All files in one partition (recommended for new users)
#d-i partman-auto/choose_recipe \
# select Separate /home partition
#d-i partman-auto/choose_recipe \
# select Separate /home, /usr, /var, and /tmp partitions
# Or provide a recipe of your own...
# The recipe format is documented in the file devel/partman-auto-recipe.txt.
# If you have a way to get a recipe file into the d-i environment, you can
# just point at it.
#d-i partman-auto/expert_recipe_file string /hd-media/recipe
# If not, you can put an entire recipe into the preconfiguration file in one
# (logical) line. This example creates a small /boot partition, suitable
# swap, and uses the rest of the space for the root partition:
#d-i partman-auto/expert_recipe string \
# boot-root :: \
# 40 50 100 ext3 \
# $primary{ } $bootable{ } \
# method{ format } format{ } \
# use_filesystem{ } filesystem{ ext3 } \
# mountpoint{ /boot } \
# . \
# 500 10000 1000000000 ext3 \
# method{ format } format{ } \
# use_filesystem{ } filesystem{ ext3 } \
# mountpoint{ / } \
# . \
# 64 512 300% linux-swap \
# method{ swap } format{ } \
# .
# This makes partman automatically partition without confirmation, provided
# that you told it what to do using one of the methods above.
d-i partman/confirm_write_new_label boolean true
d-i partman/choose_partition \
select Finish partitioning and write changes to disk
d-i partman/confirm boolean true
Partitioning using RAID
You can also use preseeding to set up partitions on software RAID arrays.
Supported are RAID levels 0, 1 and 5, creating degraded arrays and
specifying spare devices.
If you are using RAID 1, you can preseed grub to install to all devices
used in the array; see .
This type of automated partitioning is easy to get wrong. It is also a
very new component that may still have some bugs or missing error
handling. The responsibility to get the various recipes right (so they
make sense and don't conflict) lies with the user.
Check /var/log/syslog if you run into problems.
Note that only RAID 0 and RAID 1 have been tested by the developers of the
component. RAID 5 is untested. Advanced RAID setup with degraded arrays or
spare devices has only been tested lightly.
# NOTE: this option is of beta release quality and should be used carefully
# The method should be set to "raid".
#d-i partman-auto/method string raid
# Specify the disks to be partitioned. They will all get the same layout,
# so this will only work if the disks are the same size.
#d-i partman-auto/disk string /dev/discs/disc0/disc /dev/discs/disc1/disc
# Next you need to specify the physical partitions that will be used.
#d-i partman-auto/expert_recipe string \
# multiraid :: \
# 1000 5000 4000 raid \
# $primary{ } method{ raid } \
# . \
# 64 512 300% raid \
# method{ raid } \
# . \
# 500 10000 1000000000 raid \
# method{ raid } \
# .
# Last you need to specify how the previously defined partitions will be
# used in the RAID setup. Remember to use the correct partition numbers
# for logical partitions.
# Parameters are:
# <raidtype> <devcount> <sparecount> <fstype> <mountpoint> \
# <devices> <sparedevices>
# RAID levels 0, 1 and 5 are supported; devices are separated using "#"
#d-i partman-auto-raid/recipe string \
# 1 2 0 ext3 / \
# /dev/discs/disc0/part1#/dev/discs/disc1/part1 \
# . \
# 1 2 0 swap - \
# /dev/discs/disc0/part5#/dev/discs/disc1/part5 \
# . \
# 0 2 0 ext3 /home \
# /dev/discs/disc0/part6#/dev/discs/disc1/part6 \
# .
# This makes partman automatically partition without confirmation.
d-i partman-md/confirm boolean true
d-i partman/confirm_write_new_label boolean true
d-i partman/choose_partition \
select Finish partitioning and write changes to disk
d-i partman/confirm boolean true
Base system installation
There is actually not very much that can be preseeded for this stage of the
installation. The only questions asked concern the installation of the kernel.
# Select the initramfs generator used to generate the initrd for 2.6 kernels.
#d-i base-installer/kernel/linux/initramfs-generators string yaird
# The kernel image (meta) package to be installed; "none" can be used if no
# kernel is to be installed.
#d-i base-installer/kernel/image string linux-image-2.6-486
Account setup
The password for the root account and name and password for a first regular
user's account can be preseeded. For the passwords you can use either clear
text values or MD5 hashes.
Be aware that preseeding passwords is not completely secure as everyone
with access to the preconfiguration file will have the knowledge of these
passwords. Using MD5 hashes is considered slightly better in terms of
security but it might also give a false sense of security as access to a
MD5 hash allows for brute force attacks.
# Skip creation of a root account (normal user account will be able to
# use sudo).
#d-i passwd/root-login boolean false
# Alternatively, to skip creation of a normal user account.
#d-i passwd/make-user boolean false
# Root password, either in clear text
#d-i passwd/root-password password r00tme
#d-i passwd/root-password-again password r00tme
# or encrypted using an MD5 hash.
#d-i passwd/root-password-crypted password [MD5 hash]
# To create a normal user account.
#d-i passwd/user-fullname string Debian User
#d-i passwd/username string debian
# Normal user's password, either in clear text
#d-i passwd/user-password password insecure
#d-i passwd/user-password-again password insecure
# or encrypted using an MD5 hash.
#d-i passwd/user-password-crypted password [MD5 hash]
# Create the first user with the specified UID instead of the default.
#d-i passwd/user-uid string 1010
# The user account will be added to some standard initial groups. To
# override that, use this.
#d-i passwd/user-default-groups string audio cdrom video
The passwd/root-password-crypted and
passwd/user-password-crypted variables can also
be preseeded with !
as their value. In that case, the
corresponding account is disabled. This may be convenient for the root
account, provided of course that an alternative method is setup to allow
administrative activities or root login (for instance by using SSH key
authentication or sudo).
The following command can be used to generate an MD5 hash for a password:
$ echo "r00tme" | mkpasswd -s -m md5
Apt setup
Setup of the /etc/apt/sources.list and basic configuration
options is fully automated based on your installation method and answers to
earlier questions. You can optionally add other (local) repositories.
# You can choose to install non-free and contrib software.
#d-i apt-setup/non-free boolean true
#d-i apt-setup/contrib boolean true
# Uncomment this if you don't want to use a network mirror.
#d-i apt-setup/use_mirror boolean false
# Select which update services to use; define the mirrors to be used.
# Values shown below are the normal defaults.
#d-i apt-setup/services-select multiselect security, volatile
#d-i apt-setup/security_host string security.debian.org
#d-i apt-setup/volatile_host string volatile.debian.org
# Additional repositories, local[0-9] available
#d-i apt-setup/local0/repository string \
# http://local.server/debian stable main
#d-i apt-setup/local0/comment string local server
# Enable deb-src lines
#d-i apt-setup/local0/source boolean true
# URL to the public key of the local repository; you must provide a key or
# apt will complain about the unauthenticated repository and so the
# sources.list line will be left commented out
#d-i apt-setup/local0/key string http://local.server/key
# By default the installer requires that repositories be authenticated
# using a known gpg key. This setting can be used to disable that
# authentication. Warning: Insecure, not recommended.
#d-i debian-installer/allow_unauthenticated string true
Package selection
You can choose to install any combination of tasks that are available.
Available tasks as of this writing include:
standard
desktop
gnome-desktop
kde-desktop
web-server
print-server
dns-server
file-server
mail-server
sql-database
laptop
You can also choose to install no tasks, and force the installation of a
set of packages in some other way. We recommend always including the
standard task.
If you want to install some individual packages in addition to packages
installed by tasks, you can use the parameter
pkgsel/include. The value of this parameter can be
a list of packages separated by either commas or spaces, which allows it
to be used easily on the kernel command line as well.
#tasksel tasksel/first multiselect standard, web-server
# If the desktop task is selected, install the kde and xfce desktops
# instead of the default gnome desktop.
#tasksel tasksel/desktop multiselect kde, xfce
# Individual additional packages to install
#d-i pkgsel/include string openssh-server build-essential
# Some versions of the installer can report back on what software you have
# installed, and what software you use. The default is not to report back,
# but sending reports helps the project determine what software is most
# popular and include it on CDs.
#popularity-contest popularity-contest/participate boolean false
Boot loader installation
# Grub is the default boot loader (for x86). If you want lilo installed
# instead, uncomment this:
#d-i grub-installer/skip boolean true
# To also skip installing lilo, and install no bootloader, uncomment this
# too:
#d-i lilo-installer/skip boolean true
# This is fairly safe to set, it makes grub install automatically to the MBR
# if no other operating system is detected on the machine.
d-i grub-installer/only_debian boolean true
# This one makes grub-installer install to the MBR if it also finds some other
# OS, which is less safe as it might not be able to boot that other OS.
d-i grub-installer/with_other_os boolean true
# Alternatively, if you want to install to a location other than the mbr,
# uncomment and edit these lines:
#d-i grub-installer/only_debian boolean false
#d-i grub-installer/with_other_os boolean false
#d-i grub-installer/bootdev string (hd0,0)
# To install grub to multiple disks:
#d-i grub-installer/bootdev string (hd0,0) (hd1,0) (hd2,0)
# Optional password for grub, either in clear text
#d-i grub-installer/password password r00tme
#d-i grub-installer/password-again password r00tme
# or encrypted using an MD5 hash, see grub-md5-crypt(8).
#d-i grub-installer/password-crypted password [MD5 hash]
An MD5 hash for a password for grub can be generated
using grub-md5-crypt, or using the command from the
example in .
Finishing up the installation
# Avoid that last message about the install being complete.
d-i finish-install/reboot_in_progress note
# This will prevent the installer from ejecting the CD during the reboot,
# which is useful in some situations.
#d-i cdrom-detect/eject boolean false
# This is how to make the installer shutdown when finished, but not
# reboot into the installed system.
#d-i debian-installer/exit/halt boolean true
X configuration
Preseeding Debian's X config is possible, but you probably need to know
some details about the video hardware of the machine, since Debian's X
configurator does not do fully automatic configuration of everything.
# X can detect the right driver for some cards, but if you're preseeding,
# you override whatever it chooses. Still, vesa will work most places.
#xserver-xorg xserver-xorg/config/device/driver select vesa
# A caveat with mouse autodetection is that if it fails, X will retry it
# over and over. So if it's preseeded to be done, there is a possibility of
# an infinite loop if the mouse is not autodetected.
#xserver-xorg xserver-xorg/autodetect_mouse boolean true
# Monitor autodetection is recommended.
xserver-xorg xserver-xorg/autodetect_monitor boolean true
# Uncomment if you have an LCD display.
#xserver-xorg xserver-xorg/config/monitor/lcd boolean true
# X has three configuration paths for the monitor. Here's how to preseed
# the "medium" path, which is always available. The "simple" path may not
# be available, and the "advanced" path asks too many questions.
xserver-xorg xserver-xorg/config/monitor/selection-method \
select medium
xserver-xorg xserver-xorg/config/monitor/mode-list \
select 1024x768 @ 60 Hz
Preseeding other packages
# Depending on what software you choose to install, or if things go wrong
# during the installation process, it's possible that other questions may
# be asked. You can preseed those too, of course. To get a list of every
# possible question that could be asked during an install, do an
# installation, and then run these commands:
# debconf-get-selections --installer > file
# debconf-get-selections >> file
Advanced options
Running custom commands during the installation
A very powerful and flexible option offered by the preconfiguration tools
is the ability to run commands or scripts at certain points in the
installation.
# d-i preseeding is inherently not secure. Nothing in the installer checks
# for attempts at buffer overflows or other exploits of the values of a
# preconfiguration file like this one. Only use preconfiguration files from
# trusted locations! To drive that home, and because it's generally useful,
# here's a way to run any shell command you'd like inside the installer,
# automatically.
# This first command is run as early as possible, just after
# preseeding is read.
#d-i preseed/early_command string anna-install some-udeb
# This command is run just before the install finishes, but when there is
# still a usable /target directory. You can chroot to /target and use it
# directly, or use the apt-install and in-target commands to easily install
# packages and run commands in the target system.
#d-i preseed/late_command string apt-install zsh; in-target chsh -s /bin/zsh
Using preseeding to change default values
It is possible to use preseeding to change the default answer for a
question, but still have the question asked. To do this the
seen flag must be reset to false
after
setting the value for a question.
d-i foo/bar string value
d-i foo/bar seen false
The same effect can be achieved for all questions by
setting the parameter preseed/interactive=true at
the boot prompt. This can also be useful for testing or debugging your
preconfiguration file.
If you are preseeding using boot parameters, you can make the installer ask
the corresponding question by using the ?=
operator, i.e.
foo/bar?=value.
This will of course only have effect for parameters that correspond to
questions that are actually displayed during an installation and not for
internal
parameters.
Chainloading preconfiguration files
It is possible to include other preconfiguration files from a preconfiguration
file. Any settings in those files will override pre-existing settings from
files loaded earlier. This makes it possible to put, for example, general
networking settings for your location in one file and more specific
settings for certain configurations in other files.
# More than one file can be listed, separated by spaces; all will be
# loaded. The included files can have preseed/include directives of their
# own as well. Note that if the filenames are relative, they are taken from
# the same directory as the preconfiguration file that includes them.
#d-i preseed/include string x.cfg
# The installer can optionally verify checksums of preconfiguration files
# before using them. Currently only md5sums are supported, list the md5sums
# in the same order as the list of files to include.
#d-i preseed/include/checksum string 5da499872becccfeda2c4872f9171c3d
# More flexibly, this runs a shell command and if it outputs the names of
# preconfiguration files, includes those files.
#d-i preseed/include_command \
# string if [ "`hostname`" = bob ]; then echo bob.cfg; fi
# Most flexibly of all, this downloads a program and runs it. The program
# can use commands such as debconf-set to manipulate the debconf database.
# More than one script can be listed, separated by spaces.
# Note that if the filenames are relative, they are taken from the same
# directory as the preconfiguration file that runs them.
#d-i preseed/run string foo.sh
It is also possible to chainload from the initrd or file preseeding phase,
into network preseeding by setting preseed/url in the earlier files.
This will cause network preseeding to be performed when the network comes
up. You need to be careful when doing this, since there will be two
distinct runs at preseeding, meaning for example that you get another
chance to run the preseed/early command, the second one happening after the
network comes up.