Inspect a Package's Debconf Answers with debconf-show

When a package behaves as if it remembers an answer you never gave it, debconf-show is how you see what debconf actually has on file. It is read-only: nothing gets reconfigured and no new answer gets written. You will also learn how to find a question's owner and pick a database explicitly when the default view falls short.

Allow about five minutes. You need a shell and the debconf package. The examples use the locally installed debconf version 1.5.86ubuntu1. Run these as your normal user first; if a database turns out to be protected, the command may report warnings or incomplete information, and elevated privileges should only come out for a specific reason to inspect that database.

1. Confirm the command and package

command -v debconf-show
dpkg-query -W debconf

Expect a path such as /usr/sbin/debconf-show or /usr/bin/debconf-show, followed by the installed package record. There is no documented --version option, so do not reach for one: the package database is the reliable local source for the version.

2. Show one package's recorded answers

Pass the Debian package name as the first argument. Start with debconf itself for a harmless example:

debconf-show debconf

• A leading * marks a question that has already been asked.
• No * means it is still in the database but has not been presented in the normal way.
• An empty value is still evidence. It is different from a missing question entirely.

For a real package, swap in its exact name:

debconf-show PACKAGE_NAME

Replace PACKAGE_NAME with something installed or known to have debconf entries. This is a database query, not a package inventory: a package that owns no questions in the selected database simply produces no useful lines.

3. Read the markers without changing anything

Save a copy of the output when you need it for a support case, redacting secrets first:

debconf-show debconf > debconf-answers.txt
sed -n '1,80p' debconf-answers.txt

The redirection creates a local text file and touches debconf not at all. But debconf values can carry machine-specific detail that should never leave the system, so review the file before sending it anywhere. To remove the temporary copy afterwards:

rm -- debconf-answers.txt

4. List the owners of all questions

debconf-show --listowners

This prints owner names, which normally line up with Debian package names, and it is the way to find which package registered a question you already know exists. The list can run long, so filter it after the query rather than guessing a package name up front:

debconf-show --listowners | grep -Fx 'debconf'

No output from the filtered command is not proof the package is absent. It may simply have no questions in the database you queried, or its owner name may not match what you typed.

5. Discover available databases

debconf-show --listdbs

On this machine that lists configdb, configdb/config, and configdb/passwords. The main database is the default for an ordinary query. Do not assume every name listed is readable by an unprivileged user: the passwords database in particular may be locked down.

Query a specific database with --db=, options going before the package name:

debconf-show --db=configdb debconf

An invalid name fails outright rather than quietly falling back to the main database:

debconf-show --db=does-not-exist debconf

That produces an error saying the database is unknown. Treat it as a discovery problem and go back to --listdbs; do not create or rename database files just to make the command move forward.

Common traps

• Confusing ownership with installation. --listowners reports registered question owners, not a complete list of installed packages.
• Reading a warning as an answer. A permission warning from a database driver is diagnostic output, not a debconf value. Only rerun with more privilege if you are actually authorised to see that data.
• Expecting repair from a read-only tool. debconf-show only queries. Use a package's own documented configuration workflow to change an answer, and take a backup first.
• Forgetting which database you queried. Two queries against different databases can show different answers; record the exact command, --db= included, in any bug report.
• Sharing sensitive values. Check captured output for passwords, tokens, and hostnames before it goes into a ticket.