Documentation< Previous | Contents | Next >
Handling Problems after an Upgrade
In spite of the Kali/Debian maintainers’ best efforts, a system upgrade isn’t always as smooth as we would hope. New software versions may be incompatible with previous ones (for instance, their default behavior or their data format may have changed), or bugs may slip through the cracks despite the testing performed by package maintainers and Debian Unstable users.
Leveraging Bug Reports You might sometimes find that a new version of software doesn’t work at all. This generally happens if the application isn’t particularly popular and hasn’t been tested enough. The first thing to do is to have a look at the Kali bug tracker3 and at the Debian bug tracking system4 at https://bugs.debian.org/package , and check whether the problem has already been reported. If it hasn’t, you should report it yourself (see section 6.3, “Filing a Good Bug Report” [page 129] for detailed instructions). If it is already known, the bug report and the associated messages are usually an excellent source of information related to the bug. In some cases, a patch already exists and has been made available in the bug report itself; you can then recompile a fixed version of the broken package locally (see section 9.1, “Modifying Kali Packages” [page 222]). In other cases, users may have found a workaround for the problem and shared their insights about it in their replies to the report; those instructions may help you work around the problem until a fix or patch is released. In a best-case scenario, the package may have already been fixed and you may find details in the bug report.
3http://bugs.kali.org 4https://bugs.debian.org
Downgrading to a Working Version When the problem is a clear regression (where the former version worked), you can try to downgrade the package. In this case, you will need a copy of the old version. If you have access to the old version in one of the repositories configured in APT, you can use a simple one-liner command to downgrade (see section 8.2.2.2, “Installing Packages with APT” [page 177]). But with Kali’s rolling release, you will usually only find a single version of each package at any one time.
You can still try to find the old .deb file and install it manually with dpkg. Old .deb files can be found in multiple places:
• in APT’s cache in /var/cache/apt/archives/
• in the pool directory on your usual Kali mirror (removed and obsolete packages are kept for three to four days to avoid problems with users not having the latest package indices)
• in http://snapshot.debian.org if the affected package was provided by Debian and not by Kali; this service keeps historical versions of all Debian packages
Dealing with Broken Maintainer Scripts Sometimes the upgrade gets interrupted because one of the package maintainer scripts fails (usually, it is the postinst). In those cases, you can try to diagnose the problem, and possibly work around it, by editing the problematic script.
Here we rely on the fact that maintainer scripts are stored in /var/lib/dpkg/info/ and that we can review and modify them.
Since maintainer scripts are usually simple shell scripts, it is possible to add a set -x line just after the shebang line and arrange them to be rerun (with dpkg --configure -a for postinst) to see precisely what is happening and where it is failing. This output can also nicely complement any bug report that you might file.
With this newly gained knowledge, you can either fix the underlying problem or transform the failing command into a working one (for example by adding || true at the end of the line).
Note that this tip does not work for a failing preinst since that script is executed even before the package gets installed so it is not yet in its final location. It does work for postrm and prerm although you will need to execute a package removal (respectively upgrade) to trigger them.