Reconfigure an Installed Debian Package Safely with dpkg-reconfigure

You will revisit the configuration questions for an installed Debian package, choose which questions are shown, and verify the result without confusing package reconfiguration with package installation. Allow about ten minutes for a familiar package, or longer if its prompts affect networking, locale, time zone or a running service.

You need a shell, an installed package that uses debconf, and an account that can use sudo when the package's configuration files require root. The examples use the locally installed debconf package version 1.5.86ubuntu1 and the installed tzdata package as a concrete example. Your prompts and defaults can differ.

1. Check the command and package first

Start with read-only checks. This confirms the command on your PATH and makes sure the package name is installed before you hand it to a privileged command:

$ command -v dpkg-reconfigure
/usr/sbin/dpkg-reconfigure
$ dpkg-query -W -f='\${Status} \${Version}\n' tzdata
install ok installed 2026c-0ubuntu0.24.04.1
$ dpkg-reconfigure --help
Usage: dpkg-reconfigure [options] packages
...

The help text shows the command shape: options followed by one or more package names. Do not use dpkg-reconfigure for a package that is absent, half-installed or not designed to ask debconf questions. Check its package state before trying to repair anything.

Checkpoint: replace tzdata with your target package and run the dpkg-query command again. Continue only when it reports install ok installed. The version is useful evidence when comparing a prompt or default with another host.

2. Understand what the ordinary command will do

The basic form is:

$ sudo dpkg-reconfigure PACKAGE_NAME

Replace PACKAGE_NAME with an installed package name, for example:

$ sudo dpkg-reconfigure tzdata

This asks the package to revisit its configuration questions, much like the questions shown during installation. By default, dpkg-reconfigure shows all questions, including ones that have already been answered, and normally includes low-priority questions. That is why a familiar package can suddenly ask more than you remember.

There is a real state change here. A completed prompt sequence can rewrite configuration files and may run the package's configuration scripts. For tzdata, a new time zone can affect timestamps and applications that read the system time zone. Do not run a reconfiguration during a change window unless you know which services and users depend on the result.

Warning: do not press through prompts by guessing. Read the proposed value, record the old setting first, and stop if the question is unclear. A package's configuration is not automatically restored by rerunning the same command.

3. Choose the frontend deliberately

The frontend controls how debconf asks questions. The installed manual documents -f TYPE and --frontend=TYPE. On a local terminal, the default normally gives an interactive dialog. A text-only session can use the readline frontend explicitly:

$ sudo dpkg-reconfigure --frontend=readline tzdata

If a graphical or dialog frontend cannot start, forcing a frontend that needs a display will fail or leave you with an unusable session. Choose a frontend supported by the terminal you are actually using. The frontend does not decide the package's answers; it decides how those questions are presented.

A confusing special case is the noninteractive default. The manual states that dpkg-reconfigure uses the dialog frontend instead when debconf is normally configured for noninteractive operation, so that reconfiguration remains interactive. Do not assume a noninteractive system-wide default means this command will silently accept every answer.

Checkpoint: if you need to see the prompts in a plain SSH terminal, use --frontend=readline and keep the session open until the command returns. If you need to automate answers, stop and design that separately; this guide does not turn interactive package policy into an unattended script.

4. Limit the questions when you have a clear reason

Use --priority=VALUE or its short form -pVALUE to set the minimum question priority that is displayed:

$ sudo dpkg-reconfigure --frontend=readline --priority=medium tzdata

Higher minimum priorities show fewer questions. This can make a long session manageable, but it can also hide the setting you meant to change. The normal command deliberately shows low-priority questions, so do not add --priority=medium merely to make the screen shorter.

--default-priority uses the configured default question priority instead of forcing the normal low-priority behaviour:

$ sudo dpkg-reconfigure --default-priority tzdata

These are different choices. Use a threshold when you have decided that lower-priority questions are out of scope. Use --default-priority when you want the host's configured debconf policy to decide. If you need to see every question, leave both options out.

5. Revisit only unseen questions when that is the intent

--unseen-only, or -u, asks only questions that have not yet been seen. It is useful for completing an interrupted first configuration, but it is the wrong option when you are trying to revisit an old answer:

$ sudo dpkg-reconfigure --frontend=readline --unseen-only PACKAGE_NAME

Do not combine --unseen-only with an expectation that every setting will be offered again. If the package has already marked the relevant question as seen, the command can finish without showing it. For a deliberate review, omit --unseen-only and read all of the prompts.

If you only want to inspect current debconf values rather than start a reconfiguration, use debconf-show PACKAGE_NAME as suggested by the manual:

$ debconf-show tzdata

This is a read-only inspection step. Its output is not a replacement for checking the package's effective configuration files or the running service that consumes them.

6. Verify the result and recover carefully

When the command returns, record its status immediately:

$ printf 'dpkg-reconfigure status: %s\n' "$?"
dpkg-reconfigure status: 0

Status 0 means the command completed successfully. It does not prove that you selected the intended answer or that every dependent service has reloaded it. Re-check the package's documented configuration, then check the specific consumer. For the time zone example, use:

$ timedatectl status
$ date

The exact output depends on the host. Look for the expected time zone and a sensible local time. Do not treat a successful exit status as proof that an application has already re-read its configuration.

If you chose the wrong value, rerun sudo dpkg-reconfigure tzdata and select the previous value. That is the normal undo path for this example. For another package, use its own documented configuration procedure or restore a known-good configuration backup. Do not delete files from /var/cache/debconf or pass --force as a first recovery step.

Use --force only when you have confirmed that the package is inconsistent or broken and you understand the risk. The manual warns that it forces reconfiguration in that state. Likewise, --no-reload prevents template reloading and can stop the command repairing a broken templates database. It is intended for constrained environments where rewriting templates is expensive, not as a general speed option.

7. Keep the operation narrow

You can name more than one package, but do so only when the packages form one change you have planned:

$ sudo dpkg-reconfigure --frontend=readline PACKAGE_ONE PACKAGE_TWO

Multiple packages mean multiple opportunities to change system state and lose track of which prompt caused a later effect. Reconfigure one package first, verify it, and then continue. Keep the terminal output in your change record when the setting affects a production host.

If the command reports that a package is broken, stop and inspect the package manager state before adding --force. A forced configuration can make a difficult recovery harder. Resolve the underlying dependency or package error through your normal Debian package-management procedure, then retry the ordinary command.