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/USB 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 generic 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. Preseeding from the kernel command line happens just after. It is thus possible to override configuration set in the initrd by editing the kernel command line (either in the bootloader configuration or manually at boot time for bootloaders that allow it). For file preseeding this is after the installation 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). A not so convenient way to avoid these questions from being asked is to preseed them through the boot parameters, as described in . In order to easily 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 usb-stick. If you want to include the file in an installation ISO image, you will have to remaster the 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.(e.g. grub.cfg) and adding the parameter as a new set line for the kernel.(e.g. grub.cfg) and adding the parameter to the end of the gnumach.gz line. 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.For grub this means setting the timeout to 0 in grub.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 - or preseed/url=tftp://host/path/to/preseed.cfg preseed/url/checksum=5da499872becccfeda2c4872f9171c3d - if you're booting a remastered installation image: 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, preseed/file to just file and preseed/file/checksum to just preseed-md5 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. This is enabled by using the Automated install boot choice, also called auto for some architectures or boot methods. In this section, auto is thus not a parameter, it means selecting that boot choice, and appending the following boot parameters on the boot prompt. See for information on how to add a boot parameter. 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/&releasename;/./preseed.cfg. The last part of that url (d-i/&releasename;/./preseed.cfg) is taken from auto-install/defaultroot. By default this includes the directory &releasename; 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/&releasename;/./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 choice is not yet defined on all arches. The same effect may be achieved by simply adding the two parameters auto=true priority=critical to the kernel command line. The auto kernel parameter is an alias for auto-install/enable and setting it to true delays 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. Note that these are simply short aliases for question names, and you always need to specify a value as well: for example, auto=true or interface=eth0. prioritydebconf/priority fbdebian-installer/framebuffer languagedebian-installer/language countrydebian-installer/country localedebian-installer/locale themedebian-installer/theme autoauto-install/enable classesauto-install/classes filepreseed/file urlpreseed/url domainnetcfg/get_domain hostname   netcfg/get_hostname interfacenetcfg/choose_interface protocolmirror/protocol suitemirror/suite modulesanna/choose_modules recommendsbase-installer/install-recommends taskstasksel:tasksel/first desktoptasksel:tasksel/desktop dmraiddisk-detect/dmraid/enable keymapkeyboard-configuration/xkb-keymap preseed-md5preseed/file/checksum Examples of boot prompt preseeding Here are some examples of how the boot prompt might look like (you will need to adapt this to your needs; also see ). # To set French as language and France as country: /install.amd/vmlinuz vga=788 initrd=/install.amd/gtk/initrd.gz language=fr country=FR --- quiet # To set English as language and Germany as country, and use a German keyboard layout: /install.amd/vmlinuz vga=788 initrd=/install.amd/gtk/initrd.gz language=en country=DE locale=en_US.UTF-8 keymap=de --- quiet # To install the MATE desktop: /install.amd/vmlinuz vga=788 initrd=/install.amd/gtk/initrd.gz desktop=mate-desktop --- quiet # To install the web-server task: /install.amd/vmlinuz initrd=/install.amd/initrd.gz tasksel:tasksel/first=web-server --- 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 isc-dhcp-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> The file should start with #_preseed_V1 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. Split lines will be joined into a single line with all leading/trailing whitespace condensed to a single space. For debconf variables (templates) used only 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. Start with #_preseed_V1 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: $ echo "#_preseed_V1" > 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. Details on how the different Debian Installer components actually work can be found in . Localization During a normal install the questions about localization are asked first, so these values can only be preseeded via the initrd or kernel boot parameter methods. Auto mode () includes the setting of auto-install/enable=true (normally via the auto preseed alias). This delays the asking of the localisation questions, so that they can be preseeded by any method. The locale can be used to specify both language and country and can be any combination of a language supported by &d-i; and a recognized country. If the combination does not form a valid locale, the installer will automatically select a locale that is valid for the selected language. To specify the locale as a boot parameter, use locale=en_US. Although this method is very easy to use, it does not allow preseeding of all possible combinations of language, country and locale Preseeding locale to en_NL would for example result in en_US.UTF-8 as default locale for the installed system. If e.g. en_GB.UTF-8 is preferred instead, the values will need to be preseeded individually. . So alternatively the values can be preseeded individually. Language and country can also be specified as boot parameters. # Preseeding only locale sets language, country and locale. d-i debian-installer/locale string en_US # The values can also be preseeded individually for greater flexibility. #d-i debian-installer/language string en #d-i debian-installer/country string NL #d-i debian-installer/locale string en_GB.UTF-8 # Optionally specify additional locales to be generated. #d-i localechooser/supported-locales multiselect en_US.UTF-8, nl_NL.UTF-8 Keyboard configuration consists of selecting a keymap and (for non-latin keymaps) a toggle key to switch between the non-latin keymap and the US keymap. Only basic keymap variants are available during installation. Advanced variants are available only in the installed system, through dpkg-reconfigure keyboard-configuration. # Keyboard selection. d-i keyboard-configuration/xkb-keymap select us # d-i keyboard-configuration/toggle select No toggling To skip keyboard configuration, preseed keymap with skip-config. This will result in the kernel keymap remaining active. 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 optical disc 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: kill-all-dhcp; netcfg The following debconf variables are relevant for network configuration. # Disable network configuration entirely. This is useful for cdrom # installations on non-networked devices where the network questions, # warning and long timeouts are a nuisance. #d-i netcfg/enable boolean false # 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 # To set a different link detection timeout (default is 3 seconds). # Values are interpreted as seconds. #d-i netcfg/link_wait_timeout string 10 # 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 #d-i netcfg/dhcpv6_timeout string 60 # If you prefer to configure the network manually, uncomment this line and # the static network configuration below. #d-i netcfg/disable_autoconfig 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. # # IPv4 example #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/get_nameservers string 192.168.1.1 #d-i netcfg/confirm_static boolean true # # IPv6 example #d-i netcfg/get_ipaddress string fc00::2 #d-i netcfg/get_netmask string ffff:ffff:ffff:ffff:: #d-i netcfg/get_gateway string fc00::1 #d-i netcfg/get_nameservers string fc00::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 # If you want to force a hostname, regardless of what either the DHCP # server returns or what the reverse DNS entry for the IP is, uncomment # and adjust the following line. #d-i netcfg/hostname string somehost # 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 # If non-free firmware is needed for the network or other hardware, you can # configure the installer to always try to load it, without prompting. Or # change to false to disable asking. #d-i hw-detect/load_firmware boolean true Please note that netcfg will automatically determine the netmask if netcfg/get_netmask is not preseeded. In this case, the variable has to be marked as seen for automatic installations. Similarly, netcfg will choose an appropriate address if netcfg/get_gateway is not set. As a special case, you can set netcfg/get_gateway to none to specify that no gateway should be used. Network console # Use the following settings if you wish to make use of the network-console # component for remote installation over SSH. This only makes sense if you # intend to perform the remainder of the installation manually. #d-i anna/choose_modules string network-console #d-i network-console/authorized_keys_url string http://10.0.0.1/openssh-key #d-i network-console/password password r00tme #d-i network-console/password-again password r00tme 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. Normally the installer will automatically use the correct value and there should be no need to set this. # 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 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 crypt(3) 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. Storing hashed passwords is considered secure unless a weak hashing algorithm like DES or MD5 is used which allow for bruteforce attacks. Recommended password hashing algorithms are SHA-256 and SHA512. # 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 a crypt(3) hash. #d-i passwd/root-password-crypted password [crypt(3) 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 a crypt(3) hash. #d-i passwd/user-password-crypted password [crypt(3) 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 set up to allow administrative activities or root login (for instance by using SSH key authentication or sudo). The following command (available from the whois package) can be used to generate a SHA-512 based crypt(3) hash for a password: mkpasswd -m sha-512 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 string ntp.example.com Partitioning Using preseeding to partition the harddisk is 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. Preseeding of advanced partition setups using RAID, LVM and encryption is supported, but not with the full flexibility possible when partitioning during a non-preseeded install. The examples below only provide basic information on the use of recipes. For detailed information see the files partman-auto-recipe.txt and partman-auto-raid-recipe.txt included in the debian-installer package. Both files are also available from the &d-i; source repository. Note that the supported functionality may change between releases. 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. Partitioning example # If the system has free space you can choose to only partition that space. # This is only honoured if partman-auto/method (below) is not set. #d-i partman-auto/init_automatically_partition select biggest_free # Alternatively, you may specify a disk to partition. If the system has only # one disk the installer will default to using that, but otherwise the device # name must be given in traditional, non-devfs format (so e.g. /dev/sda # and not e.g. /dev/discs/disc0/disc). # For example, to use the first SCSI/SATA hard disk: #d-i partman-auto/disk string /dev/sda # In addition, you'll need to specify the method to use. # The presently available methods are: # - regular: use the usual partition types for your architecture # - lvm: use LVM to partition the disk # - crypto: use LVM within an encrypted partition d-i partman-auto/method string lvm # You can define the amount of space that will be used for the LVM volume # group. It can either be a size with its unit (eg. 20 GB), a percentage of # free space or the 'max' keyword. d-i partman-auto-lvm/guided_size string max # 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 # The same applies to pre-existing software RAID array: d-i partman-md/device_remove_md boolean true # And the same goes for the confirmation to write the lvm partitions. d-i partman-lvm/confirm boolean true d-i partman-lvm/confirm_nooverwrite boolean true # You can choose one of the three predefined partitioning recipes: # - atomic: all files in one partition # - home: separate /home partition # - multi: separate /home, /var, and /tmp partitions d-i partman-auto/choose_recipe select atomic # Or provide a recipe of your own... # 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{ } \ # . # The full recipe format is documented in the file partman-auto-recipe.txt # included in the 'debian-installer' package or available from D-I source # repository. This also documents how to specify settings such as file # system labels, volume group names and which physical devices to include # in a volume group. ## Partitioning for EFI # If your system needs an EFI partition you could add something like # this to the recipe above, as the first element in the recipe: # 538 538 1075 free \ # $iflabel{ gpt } \ # $reusemethod{ } \ # method{ efi } \ # format{ } \ # . \ # # The fragment above is for the amd64 architecture; the details may be # different on other architectures. The 'partman-auto' package in the # D-I source repository may have an example you can follow. # This makes partman automatically partition without confirmation, provided # that you told it what to do using one of the methods above. d-i partman-partitioning/confirm_write_new_label boolean true d-i partman/choose_partition select finish d-i partman/confirm boolean true d-i partman/confirm_nooverwrite boolean true # Force UEFI booting ('BIOS compatibility' will be lost). Default: false. #d-i partman-efi/non_efi_system boolean true # Ensure the partition table is GPT - this is required for EFI #d-i partman-partitioning/choose_label string gpt #d-i partman-partitioning/default_label string gpt # When disk encryption is enabled, skip wiping the partitions beforehand. #d-i partman-auto-crypto/erase_disks boolean false Partitioning using RAID You can also use preseeding to set up partitions on software RAID arrays. Supported are RAID levels 0, 1, 5, 6 and 10, 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 functionality that receives relatively little testing from the developers of &d-i;. 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. # 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/sda /dev/sdb # 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. RAID levels 0, 1, 5, 6 and 10 are supported; # devices are separated using "#". # Parameters are: # <raidtype> <devcount> <sparecount> <fstype> <mountpoint> \ # <devices> <sparedevices> #d-i partman-auto-raid/recipe string \ # 1 2 0 ext3 / \ # /dev/sda1#/dev/sdb1 \ # . \ # 1 2 0 swap - \ # /dev/sda5#/dev/sdb5 \ # . \ # 0 2 0 ext3 /home \ # /dev/sda6#/dev/sdb6 \ # . # For additional information see the file partman-auto-raid-recipe.txt # included in the 'debian-installer' package or available from D-I source # repository. # This makes partman automatically partition without confirmation. d-i partman-md/confirm boolean true d-i partman-partitioning/confirm_write_new_label boolean true d-i partman/choose_partition select finish d-i partman/confirm boolean true d-i partman/confirm_nooverwrite boolean true Controlling how partitions are mounted Normally, filesystems are mounted using a universally unique identifier (UUID) as a key; this allows them to be mounted properly even if their device name changes. UUIDs are long and difficult to read, so, if you prefer, the installer can mount filesystems based on the traditional device names, or based on a label you assign. If you ask the installer to mount by label, any filesystems without a label will be mounted using a UUID instead. Devices with stable names, such as LVM logical volumes, will continue to use their traditional names rather than UUIDs. Traditional device names may change based on the order in which the kernel discovers devices at boot, which may cause the wrong filesystem to be mounted. Similarly, labels are likely to clash if you plug in a new disk or a USB drive, and if that happens your system's behaviour when started will be random. # The default is to mount by UUID, but you can also choose "traditional" to # use traditional device names, or "label" to try filesystem labels before # falling back to UUIDs. #d-i partman/mount_style select uuid 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. # Configure APT to not install recommended packages by default. Use of this # option can result in an incomplete system and should only be used by very # experienced users. #d-i base-installer/install-recommends boolean false # 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 &kernelpackage;-686 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, updates #d-i apt-setup/security_host string security.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 # If the provided key file ends in ".asc" the key file needs to be an # ASCII-armoured PGP key, if it ends in ".gpg" it needs to use the # "GPG key public keyring" format, the "keybox database" format is # currently not supported. # 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 boolean true # Uncomment this to add multiarch configuration for i386 #d-i apt-setup/multiarch string i386 Package selection You can choose to install any combination of tasks that are available. Available tasks as of this writing include: standard (standard tools) desktop (graphical desktop) gnome-desktop (Gnome desktop) xfce-desktop (XFCE desktop) kde-desktop (KDE Plasma desktop) cinnamon-desktop (Cinnamon desktop) mate-desktop (MATE desktop) lxde-desktop (LXDE desktop) web-server (web server) ssh-server (SSH server) 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, kde-desktop # Individual additional packages to install #d-i pkgsel/include string openssh-server build-essential # Whether to upgrade packages after debootstrap. # Allowed values: none, safe-upgrade, full-upgrade #d-i pkgsel/upgrade select none # 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 should be included on the first CD/DVD. #popularity-contest popularity-contest/participate boolean false Boot loader installation # Grub is the boot loader (for x86).# To install no bootloader, uncomment this #d-i grub-installer/skip boolean true # This is fairly safe to set, it makes grub install automatically to the UEFI # partition/boot record 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 UEFI partition/boot record, 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 # Due notably to potential USB sticks, the location of the primary drive can # not be determined safely in general, so this needs to be specified: #d-i grub-installer/bootdev string /dev/sda # To install to the primary device (assuming it is not a USB stick): #d-i grub-installer/bootdev string default # Alternatively, if you want to install to a location other than the UEFI # parition/boot record, 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,1) # To install grub to multiple disks: #d-i grub-installer/bootdev string (hd0,1) (hd1,1) (hd2,1) # 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] # Use the following option to add additional boot parameters for the # installed system (if supported by the bootloader installer). # Note: options passed to the installer will be added automatically. #d-i debian-installer/add-kernel-opts string nousb 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 # During installations from serial console, the regular virtual consoles # (VT1-VT6) are normally disabled in /etc/inittab. Uncomment the next # line to prevent this. #d-i finish-install/keep-consoles boolean true # 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 # This will power off the machine instead of just halting it. #d-i debian-installer/exit/poweroff boolean true 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. When the filesystem of the target system is mounted, it is available in /target. If an installation CD is used, when it is mounted it is available in /cdrom. # 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 immediately before the partitioner starts. It may be # useful to apply dynamic partitioner preseeding that depends on the state # of the disks (which may not be visible when preseed/early_command runs). #d-i partman/early_command \ # string debconf-set partman-auto/disk "$(list-devices disk | head -n1)" # 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. Note that the d-i owner should only be used for variables used in the installer itself. For variables belonging to packages installed on the target system, you should use the name of that package instead. See the footnote to . 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 (or owner: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. For more debugging information, use the boot parameter DEBCONF_DEBUG=5. This will cause debconf to print much more detail about the current settings of each variable and about its progress through each package's installation scripts. 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.