Is there any way to roll back the most recent upgrade?

Question

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 brainstorm.ubuntu.com, 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!

Answer 1

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:

• /var/log/dpkg.log 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

Cheers

Answer 2

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.

Answer 3

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 http://de.archive.ubuntu.com/ubuntu/ lucid-updates/main Packages
        500 http://security.ubuntu.com/ubuntu/ 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

Answer 4

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.

Answer 5

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.

Answer 6

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.