How to Rollback Package Updates/Installation on Fedora Sun, Jan 22. 2006
One of the least-known secrets about rpm is that it can rollback (undo) package changes. It can take a fair bit of storage space to track the information necessary for rollback, but since storage is cheap, it's worthwhile enabling this feature on most systems. This is a feature I've used several times while writing the book Fedora Linux.
Here's cut-to-the-chase directions on using this feature:
To configure yum to save rollback information, add the line tsflags=repackage to /etc/yum.conf.
To configure command-line rpm to do the same thing, add the line %_repackage_all_erasures 1 to /etc/rpm/macros.
Install, erase, and update packages to your heart's content, using pup, pirut, yumex, yum, rpm, and the yum automatic update service.
If/when you want to rollback to a previous state, perform an rpm update with the --rollback option followed by a date/time specifier. Some examples: rpm -Uhv --rollback '9:00 am', rpm -Uhv --rollback '4 hours ago', rpm -Uhv --rollback 'december 25'.
#1 - liquidat said:
2006-01-22 16:56 - (Reply)
I thought I already know quite a lot, but that's really surprising!
However, you should point out that the macros file should be created if not there - the average (but interested) user could be troubled by all the macros you find there and would stumble over the different names.
And, it seems not to be clear how it is liked by the rpm developers themselves:
https://lists.dulug.duke.edu/pipermail/yum/2005-October/007730.html
But thank you very much for this information! 
liquidat
#2 - Chris Tyler 2006-01-22 17:19 - (Reply)
There's differing opinions on whether this is a stable feature. It's been around for a while, but is not completely documented. Besides the support in yum and and rpm, the up2date command includes --undo and --list-rollbacks options (though up2date is depreciated).
#3 - Leslie Satenstein 2006-01-22 20:48 - (Reply)
Chris,
It is great for a 1 by 1 roll back facility. However, there are many other better schemes.
Take the idea of putting the patches / updates into a subdirectory ahead in the search path of the directory into which the executable resides. We install the patches there, and thus, it should load first, in place of the module being replaced.
(I am thinking of the path statement functionality).
Should the patch prove out, then it would be copied into the production directory. If it did not work out, it would be deleted or copied out, as appropriate. I like that approach as one change restores the operation of the system.
It would mean a restructuring of some of the linux directory trees
What is wrong with this alternate approach? Is it too late in the life of Linux to do something like that?.
(Another approach is to backup the target directories before executing YUMEX, YUM or PUP), fully, apply the patches, and if the patches fail, copy back the older modules. Here again, more than one directory and module would have to be managed.
#4 - Chris Tyler 2006-01-22 23:12 - (Reply)
It is possible to play around with environment variables, shadow directories, and so forth -- but that approach is extremely limited.
For example, /usr/bin/firefox is actually a shell wrapper script. If you relocate the binaries, you also have to edit the wrapper script.
For something like Apache, it gets far worse -- you have the Apache binaries, shared objects, loadable modules, init script, sample CGIs, error pages, sample HTML, and configuration files -- they'd all have to be relocated, and then you'd have to edit internal references so that they all resolved properly. It's a nightmare, because you're dealing with dozens of directories and many different kinds of search paths (binaries, shared objects, man pages, data files, and so forth).
Since the RPM repackage/rollback system saves the state of all removed/updated software, it can safely restore to that state even if the software or configuration files are modified from the original installation. It's not perfect, but it works for almost all situations, unless a package scriptlet is poorly written.
(Another possibility is to create a writable LVM snapshot volume, edit /etc/fstab to swap the snapshot for the original filesystem, reboot, install and test the software, and thenrestore the original /etc/fstab. When you reboot again, the system will be perfectly restored to its original state, with complete amnesia regarding the changes that took place while the snapshot was substituting for the original volume. Since snapshots use copy-on-write, the snapshot volume requires only a fraction of the storage space of the original volume in most cases. However, this approach is not suited to most production environments).
#5 - Jarrad 2007-02-26 22:55 - (Reply)
checked out your article on onlamp, you left out a - in the --rollback command. otherwise, useful article.
#6 - Chris Tyler said:
2007-02-27 00:19 - (Reply)
Sorry about that!-- something in the blog software at onlamp changed the double-dash to an emdash (it's wider than a single dash).
#7 - Wil Cooley said:
2007-04-18 00:30 - (Reply)
You can also install individual packages directly from /var/spool/repackage.
Note that if you've changed any files, even config files, the modified files will be repackaged and the header for the package created with the original checksum, which will be wrong. In order to actually install a package made by re-packaging, you have to use '--nomd5'.
#8 - Rob 2007-09-11 11:59 - (Reply)
Hey Chris,
I am trying to apply this to FC7. In my /etc/rpm, I do not have macros. I have macros.jpackage, macros.prelink and macros.specspo.
Can you help me apply this to FC7?
Thanks!
#9 - Chris Tyler 2007-09-12 08:11 - (Reply)
You can create additional files in /etc/rpm -- so just create /etc/rpm/macros (or /etc/rpm/macros.rollback, if you prefer) and put the line in there.
To test that the configuration is being picked up by rpm, issue this command:
rpm --eval "%_repackage_all_erasures"
The output should be "1" if it is configured.
#10 - Rob 2007-09-12 12:39 - (Reply)
Sweet! This will save my bacon down the road... I'd bank on it!
Thanks for the help!
Rob
#11 - jai 2008-01-31 03:15 - (Reply)
Is there rollback option to be directly used with yum which will install the packages from /var/spool/repackage?
#12 - Bob Jones 2008-02-20 13:55 - (Reply)
Thankyouthankyouthankyou. I ran across this one day and decided to enable it, figuring it might be useful. The other day I updated PAM and it locked me out of everything except runlevel 1, with no internet access. I would have been well and truly bricked if not for being able to roll back.
#13 - JessMagz 2008-03-11 02:51 - (Reply)
Sir:
I use F6 now. It's okay before. But CUPS is not working well so i decided to YUM REMOVE CUPS. Then all its dependencies were removed also. The things that were removed were something like openoffice.org, firefox, httpd, gaim, and a lot more. After that operation, my desktop was a total mess, with unknown icons etc...
How can I resolve this and get back to the old state? I tried to reinstall Fedora Core 6 using the CD and chosing UPGRADE but X is no longer functioning... I only have Xterm running in a TWM window.
Please help me sir. I want to save my drupal site in this box. ThANK YOU.
Regards,
Jess
#14 - Chris Tyler said:
2008-03-11 09:36 - (Reply)
Jess, about the only thing you can do is re-install the affected packages via Yum (unless you had repackaging turned on before you removed cups). Sorry!
You may be able to save some time by installing software groups using Pirut instead of selecting packages one-by-one.
#15 - Skurk 2008-08-02 18:22 - (Reply)
First of all, Chris - Thank you so much for you effort in the community.
JessMagz,
When you accidently get a broken installation, you can see everything handled by yum in /var/log/yum.log; e.g. "cat /var/log/yum.log"
Yum may then re-install all the removed packages from that particular date that broke the installation. This will however only work if you used yum, and not for using rpm directly.
#16 - Shreedhan 2008-11-03 13:36 - (Reply)
Hi,
I keep on installing removing 'things' from yum, and many times I get my linux crashed. So, I thought this is a good thing to have rollback.
I'm using FC9 and I added those lines in /etc/yum.conf and /etc/rpm/macros. So, just for testing purpose, I installed a game using yum. Then I tried
# yum --rollback '11:50 pm'
but the error was
Command line error: no such option: --rollback
Am I supposed to include any other things ?
I think I did it correctly.
#17 - Chris Tyler said:
2008-11-03 13:50 - (Reply)
You need to use the rpm command to perform the rollback (even if you used yum to install or remove packages) -- see the examples above for syntax.
#18 - Wil Cooley said:
2008-11-06 20:20 - (Reply)
Note that rollback has been removed in the upcoming release of RPM (which will ship with Fedora 10):
http://rpm.org/wiki/Releases/4.6.0
