Pre-seed Package Answers with debconf-set-selections

Feed debconf-set-selections an answer file and it writes straight into the debconf database, skipping questions a package would otherwise ask. Allow about fifteen minutes to write a small preseed file, check its format, then apply it. You need a shell, the debconf package, and a package whose questions you actually intend to answer.

The examples use debconf 1.5.86ubuntu1, installed on this machine. The local manual documents --verbose and --checkonly; the installed command also reports --unseen. Treat that extra option as version-specific, and confirm it with debconf-set-selections --help before relying on it elsewhere.

1. Write a small answer file

Each active line has four parts: owning package, question name, its type, and the answer. A # starts a comment, blank lines are ignored, and the answer is everything after the third whitespace-separated field, so values with spaces stay on one line:

$ install -m 600 /dev/null /tmp/my-package-preseed
$ editor /tmp/my-package-preseed
# Example questions. Replace these with names documented by the package.
my-package my-package/feature boolean true
my-package my-package/mode select standard

The package and question names above are placeholders, not real ones. Pull the actual templates from the package's documentation or from a matching system, and never run this file unchanged against production.

Setting a value normally marks its question as seen, which stops debconf asking it interactively later. To touch only the seen state, use seen as the third field with true or false after it:

my-package my-package/feature seen false

Need to change a value without marking it seen? Use two lines: set the value, then explicitly set its seen state to false. A line can continue onto the next by ending with a backslash.

2. Inspect before applying

Read the file back and confirm every non-comment line names the package you expect. This catches the most distracting failure mode there is: editing a copy in one directory and applying a different file.

$ sed -n '1,120p' /tmp/my-package-preseed
# Example questions. Replace these with names documented by the package.
my-package my-package/feature boolean true
my-package my-package/mode select standard

3. Validate the format without saving changes

Run --checkonly first. It checks the file's format and saves nothing to the debconf database, so this stays an ordinary, unprivileged check as long as the file is readable:

$ debconf-set-selections --checkonly /tmp/my-package-preseed
$ printf '%s\n' "$?"
0

A zero status means the parser is happy. It does not prove the question exists, that the value suits this package's version, or that the package will actually behave the way you expect. Fix any diagnostic and rerun the check before going further.

4. Apply the answers deliberately

Once the file checks out, apply it by name. Writing the system database normally needs elevated privileges, so keep sudo for this one state-changing step:

$ sudo debconf-set-selections /tmp/my-package-preseed

The normal command stays quiet. Add --verbose when you want a record of what it is actually processing:

$ sudo debconf-set-selections --verbose /tmp/my-package-preseed
info: Trying to set 'my-package/feature' [boolean] to 'true'

Verbose output is good for spotting a misspelled question name or a value the package refuses, but it is not a substitute for actually checking the package's templates.

5. Keep answers unseen when the next install must ask

The installed command advertises --unseen, short form -u: it applies the preseed without setting the seen flag. Useful when a default should be available to the package but the frontend still needs to present the question:

$ sudo debconf-set-selections --unseen /tmp/my-package-preseed

This option is not in the local manual page even though the installed program accepts it. Check local help before relying on it in a portable script; if you need exact seen-state control, an explicit seen false line in the input file is easier to audit.

6. Verify the consumer, not just the seed command

A successful seed command only means debconf accepted the input. Install or reconfigure the actual package and watch whether it uses the answers, through its normal operation:

$ sudo apt-get install my-package
$ sudo dpkg-reconfigure my-package

For moving preseed data between hosts, the documented pipeline is debconf-get-selections feeding into this command elsewhere. That utility ships in debconf-utils, a separate package:

$ debconf-get-selections > host-a-selections
$ ssh newhost debconf-set-selections < host-a-selections

Common traps and recovery

• Wrong package or question. The line can parse cleanly while doing nothing useful. Compare the question name and type against the target package's own templates.
• Unexpected prompts. Check whether the value was marked seen, whether this release asks a different question, and whether your chosen frontend is even displaying it.
• Unwanted database state. Do not hand-edit debconf's database files. Change or remove the specific answer through the package's own debconf tools, or use debconf-communicate only after reading its documentation and the package's recovery procedure.
• Interrupted installation. Keep the original preseed file, check the package manager's reported state, and finish recovery with the package manager's normal repair commands rather than repeatedly applying a guessed answer file.