Transactions and Rollback with RPM

When an upgrade works, you get a few more features or better performance. When an upgrade fails, you're in for a weekend of pain. Now, here's how to back off to the old version and keep the system up.
How to Use RPM Transactional Rollbacks

You may be thinking this process is complicated, but using transactional rollbacks actually is rather easy. As a simple example, let's install a single RPM and roll it back. The most crucial point you have to remember is that whenever you do an upgrade or simple erase, you must tell RPM to repackage the old package before it is erased. To do this, use the --repackage option:

# rpm -Uvh --repackage foo-1-2.noarch.rpm
Preparing...   ############################# [100%]
Repackaging...
   1:foo        ############################# [100%]
Upgrading...
   1:foo        ############################# [100%]

Using this option, RPM first repackaged the old package and then upgraded the new one. On an erase, you also need to use the --repackage option, like this:

# rpm -e --repackage foo

RPM does not show any output from an erase, but if you look in the repackage directory after an erase, a repackaged package is there.

To roll back this RPM transaction, use the --rollback option followed by the rollback target. The rollback target can be an actual date or something like one hour ago (the date specifier allows the same date formats as the cvs(1) command's -D option). So, if an hour after upgrading foo, you decide you don't want it, you could type:

# rpm -Uvh --rollback '2 hours ago'
Rollback packages (+1/-1) to
Thu Jul 31 23:26:52 2003 (0x3f29ddfc):
Preparing...  ########################### 100%]
   1:foo       ########################### [ 33%]

The output Rollback packages (+1/-1) shows that RPM is going to add one package, the previous version, and erase one package, the currently installed version.

How to Set Up a System for Rollbacks

Transactional rollbacks are only as good as your local repackaged packages repository. One quick way of making them fail is to upgrade or erase something without using the --repackage option. From my experience, it is pretty easy to forget to use this option. Therefore, if you are going to use transactional rollbacks, you want to configure RPM to repackage all erasures automatically. Do this by setting the %_repackage_all_erasures macro to 1 in your /etc/rpm/macros file. If the file does not exist simply create it:

%_repackage_all_erasures 1

By default, RPM does not roll back a newly installed package; that is, it does not erase packages that were not on the system at the time of your upgrade. You probably don't want this to be the default behavior, so you need to tell RPM to allow for this. To do this, set the macro %_unsafe_rollbacks to the date beyond which you do not want to allow an RPM to be completely erased on a rollback. A good value for this is some time after your system's initial install. This date should be in seconds since epoch. To convert a date to seconds since epoch, use the date command:

date --date="8/1/2003" +%s
1059710400

If you wanted to tell RPM not to remove packages completely that were installed on or before 8/1/2003 (the date in the above example), you would add the following to the /etc/rpm/macros file:

%_unsafe_rollbacks 1059710400

The only other thing you may want to configure is where RPM puts the repackaged packages. One reason for doing this is to ensure they are placed in a partition that has ample space. To change the repackage directory, set the %_repackage_dir macro to the directory where you wish to store the repackaged packages:

%_repackage_dir /my_rp_repository

Now you have a system that automatically repackages all erasures (so you or someone else does not forget), erases newly installed packages on a rollback (but won't erase your whole system) and places the repackaged packages where you want to store them.

Using up2date to Roll Back RPM Transactions

In Red Hat 9, up2date supports rollbacks using RPM's transactional rollback mechanism. Configuring it to support transactional rollbacks is as simple as running up2date-config, clicking the Retrieval/Installation tab and then clicking the Enable RPM rollbacks check box (see Figure 1). You have to configure RPM itself as described in the previous section. When you upgrade your system using up2date, once you have configured both RPM and up2date, RPM creates the repackaged packages of RPMs you are updating before it upgrades those packages.

Figure 1. Enabling RPM Rollbacks in up2date

To list the different known rollback targets, type:

up2date --list-rollbacks

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Empty rpms when I use rpm -Uvh --test with transational rollback

Bryan's picture

When I have repackage_all_erasures on and then do a rpm -Uvh --test it creates empty .rpm files in the /var/spool/repackage area. Has anyone else noticed this? Not sure if this is a bug or a feature.
I just checked whether this affects what happens when I first do a rpm -Uvh --test foo.rpm and then actually do a rpm -Uvh. It doesn't seem to affect anything, the empty foo.rpm is replaced by the real foo.rpm in /var/spool/repackage.

Re: Transactions and Rollback with RPM

Anonymous's picture

Watch out for the situation where you already have rollback rpms in the repackage directory with the same name.
ie. upgrade prog-1.0-1 to 1.1-1 and create a prog-1.0-1.i386.rpm file in the rollback package directory. Perform an up2date --undo, which backs out version 1.1 and puts version 1.0 back. It leaves the rollback RPMS hanging around and if you don't delete them, your next upgrade of prog-1.0 will fail to generate the rollback packages with an error like.
--------------------------------------------------------------------
Warning: The following packages are being updated, but these packages
have already been repackaged and this is currently not supported.
Repackage support for this transaction has been disabled.
--------------------------------------------------------------------
And now you have no rollback available, but the previous rollback packages have been removed!!
So remember, manually remove your rollback packages after you have performed a rollback.

This is fixed, but I forget in which version...

James Olin Oden's picture

I fixed this in the HEAD of rpm about a your ago. That said, I don't know which official versions have this fix. Basically, the rollback needed to remove the repackaged packages that it used in the rollback. If your current version of RPM does not do this, I can probably produce a patch pretty quickly.

Finally, just so you know, the latest version of RPM will have several fixes for transactional rollbacks (all done by Jeff Johnson), and will have the latest autorollback patches in it. This will be the 4.4.3 release of rpm. There are many other fixes and features.

Cheers...james

Re: Transactions and Rollback with RPM

Pedro Algarvio's picture

Couldn't this rollback feature automaticly remove the rolled back package?

Anyone, a patch?

I would do it if I could....

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState