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
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
the boot prompt. This can also be useful for testing or debugging your
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 Section B.2.2, “Using boot parameters to preseed questions”.
If you are preseeding using boot parameters, you can make the installer ask
the corresponding question by using the “?=” operator, i.e.
This will of course only have effect for parameters that correspond to
questions that are actually displayed during an installation and not for
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.