Can I rollback an apt-get upgrade if something goes wrong?

Is there a way, before starting an aptitude upgrade or apt-get upgrade, to set up something so that you can “easily” rollback your system to the “apt” state it was before the actual upgrade, if something goes wrong?

That is, for example, reinstall the old version of the packages that were upgraded during the process.

(EDIT) A few hints: I know that etckeeper for example uses some hook on apt so that it is notified whenever apt installs or uninstalls a package. I suppose there could be some kind of script that could save the list of newly installed package and their previous version number to be able to reinstall them from the apt cache (/var/cache/apt/archives). There is also checkinstall which can keep track of file modifications…

Any details on how to achieve that properly?

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

I just now had to figure out an answer to this, because the last apt-get upgrade on a Debian server made it impossible to boot the most recent kernel beyond a busybox, failing to mount the zfs root partition. At least an older kernel could still boot, but was incompatible with other software. Thus the need for a rollback.

The short answer – you could use the following command:

$ apt-get -s install $(apt-history rollback | tr 'n' ' ')

if it does what you want remove the -s and run it again. Here are the steps I took to get this working properly:

1. I temporarily trimmed my /var/log/dpkg.log to leave just today’s upgrade
2. I installed the tiny script apt-history from here into ~/.bashrc and ran

   $ apt-history rollback > rollback.txt
   ...
   libzfs2:amd64=0.6.4-4~wheezy 
   zfsutils:amd64=0.6.4-4~wheezy 
   zfs-initramfs:amd64=0.6.4-4~wheezy
   ...

3. This provides a nicely formatted list of versioned packages to roll-back to by feeding it into apt-get install. Trim this list as needed in a text editor and then run (with -s for dry-run first):

   $ apt-get -s install $(cat rollback.txt | tr 'n' ' ')
   $ apt-get install $(cat rollback.txt | tr 'n' ' ')

Apt will warn about the downgrades which is expected. To prevent this rollback to be overwritten by the next upgrade, the packages will need to be pinned, until the original issue is resolved. For example with: apt-mark hold zfsutils libzfs2 ...

function apt-history(){
    case "$1" in
      install)
            cat /var/log/dpkg.log | grep 'install '
            ;;
      upgrade|remove)
            cat /var/log/dpkg.log | grep $1
            ;;
      rollback)
            cat /var/log/dpkg.log | grep upgrade | 
                grep "$2" -A10000000 | 
                grep "$3" -B10000000 | 
                awk '{print $4"="$5}'
            ;;
      *)
            cat /var/log/dpkg.log
            ;;
    esac
}

Method 2

The log files /var/log/apt/history.log and /var/log/apt/term.log are the closest things available to your description:

I suppose there could be some kind of script that could save the list of newly installed package and their previous version number

history.log gives a summary list of every action that apt takes in the following format:

Start-Date: 2013-06-21  16:05:05
Commandline: apt-get install rdiff-backup
Install: python-pyxattr:i386 (0.5.0-3, automatic), rdiff-backup:i386 (1.2.8-6), python-pylibacl:i386 (0.5.0-3, automatic
), librsync1:i386 (0.9.7-7, automatic)
End-Date: 2013-06-21  16:05:42

In particular, it gives a list of newly installed packages, or of removed packages.
Additionally, term.log shows what actually appeared on the terminal during the action, so that would show the old and new versions of packages. A random sample from my history.log:

Preparing to replace gnupg 1.4.10-4 (using .../gnupg_1.4.10-4+squeeze1_i386.deb) ...
Unpacking replacement gnupg ...
Processing triggers for install-info ...
Processing triggers for man-db ...
Processing triggers for doc-base ...
Processing 1 changed doc-base file(s)...
Registering documents with scrollkeeper...
Setting up gnupg (1.4.10-4+squeeze1)

Trying to roll back apt automatically is not recommended, but if you use the logs, then it should be possible to do it manually unless the failed action has broken something that interferes with apt‘s actions, e.g. an inconsistent dpkg database. In that case, you will have to fix the problem before proceeding.

Method 3

No, apt doesn’t make that easy.

The best option is some type of snapshot. Either filesystem snapshots through lvm/zfs/btrfs or instance snapshots if you’re using a VM of some kind.

The only other option is to take an inventory of installed packages (dpkg -l) before and after. If you wan to “roll back” you have to explicitly install the previous version.

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0