Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This has happened to me many times in the last 5 years: an upgrade broke my system. Each time I end up with this situation, I have to reinstall the whole system, which is really annoying.

Is there any way to roll back the most recent upgrade to be able to have a functional system without reinstalling? If not, which is the best way to suggest this as a top priority idea?

I read this idea was described in, but it feels it is dead... and the forums are full of examples of upgrades breaking things, that's why I feel something needs to be done about this topic. Thanks!

share|improve this question
I'm signing in just to vote up this question. The lack of a coherent roll-back tool in a 2011 Desktop OS is pathetic. Windows had System Restore 5+ years ago, that's a long way behind the curve. Users have been (correctly) trained to install security updates, but we're constantly punished for doing this by failing drivers. – Gates VP Dec 6 '11 at 8:20

Most of the time if your system is broken it is a kernel problem.

Simply boot an older kernel and reinstall the most recent packages (especially kernel packages) that probably didn't update correctly. Few notes:


is your friend to check what is the list of the recently updated/installed packages

sudo apt-get -f install

can most of the time fix half-installed packages

share|improve this answer

Unfortunately there is no way to do this yet. Filesystem level snapshot/rollback is one of the features of the upcoming btrfs, but it has a ways yet to become feature complete and stable enough to use as the default filesystem.

share|improve this answer
For filesystem snapshots, you could use LVM instead, with ext3 or ext4. – Flimm Nov 12 '12 at 12:20
@Flimm, now you can, though it does not work very well and requires that you set up LVM when you install in the first place. – psusi Nov 12 '12 at 16:02

In synaptics, you can at least control, what have been the recent updates: File-menu, history.

(if synaptic is startable, with the broken system). So with an apt-...-command, to revert their update, it shouldn't be too hard.

I guess there is a history-command for the command line too.

Maybe you have to delete the whole package, and install a specific version. Afaik, it is possible to install a specific version, but I never had the need to do so.

update: Looked up how to do with apt:

Find packages installed in the last 3x24h:

find /var/lib/dpkg/info/ -name \*.list -mtime -3 | sed 's#.list$##;s#.*/##' 

With apt-cache policy, you see available versions of a program:

sudo apt-cache policy PROGRAM:
 *** 3.6.7+build3+nobinonly-0ubuntu0.10.04.1 0
        500 lucid-updates/main Packages
        500 lucid-security/main Packages
        100 /var/lib/dpkg/status
     3.6.3+nobinonly-0ubuntu4 0

here 3.6.7 and 3.6.3 . Now you know what earlier version might be installed (often not the immediate predecessor):

sudo apt-get install PROGRAM=3.6.3

Then you need to do an apt-pinning, to prevent future updates:

Create a new file in /etc/apt/preferences.d/ (if >= 10.4) named after your program,

Package: program
Pin: version 3.6.3*
Pin-Priority: 1000
share|improve this answer
Thanks all for the info. I can't wait for ubuntu to manage zfs out of the box! – Marcelo Ruiz Apr 16 '11 at 3:27
I'm sorry - what has it to do with zfs? Does zfs manage rollbacks? Or do the updates break your zfs-install? Or does the zfs-update break something? – user unknown Apr 16 '11 at 3:31

When doing a major upgrade, I clone the disk using Clonezilla. Burn it on a CD, have a spare (external) HDD available and follow the instructions on the Clonezilla LiveCD. Choose the partition-image mode, this uses the least space.

If you think you've broken your system (or wish to revert any changes), simply boot in the Clonezilla LiveCD, select the image on your (external) HDD and restore it. As these images are a literal copy of every bit on your disk, this might take a few hours depending on your disk speed and connection speed (the connection between the data, usually an external USB HDD, and the computer).

By the way, this is called a backup method.

share|improve this answer

You can install an older version of a given package (downgrade) with apt or dpkg easily. Finding an older version of the package is the problem as these often disappear from the pool and mirrors as updates roll in.

If you install the package from an install CD or an outdated mirror or a cache, you will also need to keep it pinned to the old version so it won't be upgraded until you allow that. Which means you have to watch for updates and test them until your problem is fixed. This is of course a problem since meanwhile (maybe forever) you'll be left with the unfixed, possibly insecure package. That means every user with some kind of system issue will be left in some random state until they can resolve it.

All software also isn't forwards compatible, so an older version of something may well not behave right when fed with newer configuration or data files. Obviously this is impossible to solve unless you also roll back all user data to a state before the upgrade was done.

It would be great if there was a way to do this, but it is massively problematic. Anyone who thinks there is a coherent solution should write a proposal and invite comments or, better yet, make a proof of concept solution (code, script, document). Trolling and whining is not constructive.

Because there is no clean technical solution, most software is developed (and integrated) with "the only way is forward" mentality. Trying to manage outdated versions is a waste of everyone's time. Found problems are fixed in newer versions ASAP. As a minor solution, I would like to see an archive of previous package versions kept somewhere for the occasional temporary workaround.

Meanwhile you can report bugs and don't expect bleeding edge software to never fail. A fix, once found, should be in the next update. Devs are humans (mostly), and therefore fallible. Computers are fiddly and full of insane variety and detail. Defensively maintained systems using well-supported components and stable integrated software distribution can be very stable without becoming insecure or non-upgradeable despite this.

share|improve this answer

I have a similar problem, I have been installing and removing several packages in 10.04, because the installation has several problems. Some are common in Ubuntu as I could see in the forums, like misbehavior after suspend, other are due to something I did wrong.

Anyway, by trial and error, I got one stable and fast configuration, but trying to go beyond that, I messed something removing packages that I thought were causing the mouse move erratically.

I did a lot of changes, recorded on synaptic history, but synaptic lacks a way to rollback to some point in the past. Or maybe I ignore how to do it. The other problem is that I installed TeXlive from the DVD, I do not see that LaTeX is installed in synaptic.

My LaTeX system works very well, but I installed other programs in the same way, and I do not know if one of them is causing the problem.

For that experience, I think that synaptic should have a rollback option based on the history recorded by synaptic. BUT it may also be capable to detect other software installed in the system. I suppose that the first change to synaptic is relatively straightforward, I have no idea if the other is possible to achieve, because I do not know if there is a standard directory set where to search the installation status of every program, maybe in /etc maybe in /usr, but I guess that something can be done, because programs not installed form .deb files follow some standard, like ./configure;make;sudo make install which I think is part of autoconf.

Other programs are simply copied to /usr/bin, those are more difficult to find, in part they could be detected by comparing the installed files in synaptic with the directories in the path, that could take too much time, and is not infallible because some strange programs may call libraries or other programs searching in non standard configuration files, certainly those are a very strange case, so strange that it may be the case that such kind of problematic non standard programs are written just for a local installation, by people like me that does not know how to use autoconf or build .deb packages. So those cases should not be a real trouble in practice.

In synthesis: It would be practical to have two functions in Synaptic:

  1. rollback based on history and
  2. the search and registration of software not installed via .deb packages.
share|improve this answer

Mostly you can consult /var/log/apt/history.log for changes done by apt/synaptic. It's just a little forensic and alot of cut/paste to do.

Go back to the date when your system was still working fine.

First take all packages that got installed since then and put them together in an uninstall script. When the script has finished, start re-adding all removed packages again.

An example case:

Start-Date: 2014-05-28  21:28:11
Commandline: synaptic
Install: libfglrx-amdxvba1:amd64 (13.12-3kali1, automatic), libgl1-fglrx-glx:amd64 (13.12-3kali1), glx-alternative-fglrx:amd64 (0.4.1kali1, automatic), libfglrx:amd64 (13.12-3kali1, au$
Remove: fglrx-glx-ia32:amd64 (12-6+point-3)
End-Date: 2014-05-28  21:28:27

you can see,

libfglrx-amdxvba1:amd64 libgl1-fglrx-glx:amd64 glx-alternative-fglrx:amd64 & libfglrx:amd64 

got installed by Synaptic. as like libfglrx:amd64 got removed by Synaptic.

We went the reverse order, so first we remove the newly installed packages and we re-add the packages that got removed.

A working command for this case could looks like:

sudo apt-get remove -y libfglrx-amdxvba1:amd64 libgl1-fglrx-glx:amd64 glx-alternative-fglrx:amd64 libfglrx:amd64 && sudo apt-get install -y libfglrx:amd64

Maybe it wouldn't be the best idea to go without the -y switch - to have more control about the process (to avoid broken dependencies). Most of you wouldn't break their finger while do a few verification "y"

In most cases a rollback is possible this way, but if dependencies are already broken - you may run into a even bigger issue.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.