Previous Page
Next Page

5.4. Rolling Back a Package Installation, Upgrade, or Removal

RPM has the ability to save datafiles before erasing them, permitting installations, updates, and removals to be undone through a rollback operation. Since it can take a substantial amount of space to save data necessary for a rollback, this feature is not enabled by defaultbut it's well worth sacrificing some disk space in most cases.

5.4.1. How Do I Do That?

In order to enable rollbacks, it is necessary to enable repackaging during the upgrading and removal of software. This can be enabled using command options, but the options have to be used consistently, and it's easy to forget them. Therefore the best approach is to configure both rpm and yum to use repackaging all the time.

To configure rpm, create the file /etc/rpm/macros and place this line in it:

%_repackage_all_erasures 1

To configure yum, edit /etc/yum.conf and add the tsflags (transaction set flags) line shown in bold here:

[main]
cachedir=/var/cache/yum
debuglevel=2
logfile=/var/log/yum.log
pkgpolicy=newest
distroverpkg=redhat-release
tolerant=1
exactarch=1
retries=20
obsoletes=1
gpgcheck=1
exclude=*xorg* *xfree* *XFree* *kernel*
tsflags=repackage

# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d

The tsflags line may appear anywhere after the [main] tag.

Once you have set this up, any package removal or upgrade (which is actually an installation and a removal performed together) will create a backup of the old data.

You can then roll back to a particular point in time by performing an upgrade with rpm and specifying the --rollback option with the time you wish to revert to:

# rpm -Uhv --rollback '10 minutes ago'
Rollback packages (+1/-0) to Sat Oct 29 15:23:40 2005 (0x4363cc3c):
Preparing...                ########################################### [100%]
   1:abe                    ########################################### [ 50%]
Cleaning up repackaged packages:
        Removing /var/spool/repackage/abe-1.0-5.i386.rpm:

Notice that the rollback installed one package and removed no packages (+1/-0), and that the rollback data was deleted after the rollback.

The format for --rollback values is quite flexible; most reasonable dates and times are interpreted correctly. Here are some examples:

# rpm -Uhv --rollback 'last Monday'
# rpm -Uhv --rollback '2 hours ago'
# rpm -Uhv --rollback '10 Jan 2007 16:30'
# rpm -Uhv --rollback 'march 17'
# rpm -Uhv --rollback '9:00 am'
# rpm -Uhv --rollback '4:30 pm last Monday'
# rpm -Uhv --rollback 'yesterday'

5.4.2. How Does It Work?

When repackaging is enabled and RPM package updates or removals are performed, the metadata for the package to be removed is combined with the current state of the package's files to create a new RPM package. This is different from the original package used to install the software because it reflects any changes that were made to the package's files. Configuration changes, deleted files, high scores, changes in sample data, and script modifications are all included in the repackaged file. This permits the package to be restored in exactly the same form as it was when it was removed.

However, files that were not in the archive portion of the original RPM package are neither repackaged nor erasedso if you install a package such as MySQL and create files with it (databases, in the case of MySQL), those files will not be removed when MySQL is removed, and they won't be restored if the package removal is rolled back.

Repackaged files are in standard RPM format, with two exceptions: the transaction ID (date and time of the transaction in seconds since the start of 1970) is recorded in the RPM, and the signatures and hashes are usually invalid because the repackaged files are different from the original files (at least the modification time of the files has changed, and in many cases the contents of one or more files, as well).

5.4.3. What About...

5.4.3.1. ...rolling back a package installation?

Installing a package does not create a repackaged RPM because there are no files already on the system that need to be repackaged. However, the package installation is recorded in the RPM database, and that is enough information for rpm to roll back the transaction: it just erases the package.

5.4.3.2. ...rolling back a rollback?

Sorry, there are just too many variables to roll back a rollback! To prevent confusion rpm deletes repackaged files once they have been used for rollback.

5.4.3.3. ...seeing what will happen during a rollback, before I decide to do it?

rpm's --test option is very useful for this:

# rpm -Uhv --test --rollback "1 minute ago"
Rollback packages (+1/-0) to Sat Oct 29 22:47:27 2005 (0x4364343f):
Preparing...                ########################################### [100%]
Cleaning up repackaged packages:
        Removing /var/spool/repackage/abe-1.0-5.i386.rpm:

From the output, you can see that this rollback will result in one package being reinstalled and no packages being removed (+1/-0). The package being reinstalled can be identified from the clean-up line: it's abe.

To proceed with the rollback, execute the command again without the --test option:

# rpm -Uhv --rollback "1 minute ago"

5.4.3.4. ...the disk space used by the rollback files?

Repackaged files are stored in /var/spool/repackage. The total amount of disk space used is displayed by this command:

# du -sh /var/spool/repackage
15M     /var/spool/repackage

If you are certain that you won't need to perform a rollback, you can delete these files to free up some disk space:

# rm -rf /var/spool/repackage
               

The repackage repository can grow to be fairly large. If you want to store it on another mounted disk, you can configure its directory by adding this line to /etc/rpm/macros:

_repackage_dir     /bigdisk/repackage
               

This will use /bigdisk/repackage for future repackaging.

However, I prefer to use a symbolic link (see Lab 4.3, "Managing Files"), so that when I look in the default location I'll know where the files have been moved:

# mv /var/spool/repackage /bigdisk/repackage
# ln -s /bigdisk/repackage /var/spool/repackage
# ls -la /var/spool/repackage
lrwxrwxrwx  1 root root 18 Oct 31 14:47 /var/spool/repackage -> /bigdisk/repackage

5.4.4. Where Can I Learn More?

  • The manpage for rpm (which covers the --repackage option but not --rollback)

  • The Linux Journal article "Transactions and Rollback with RPM": http://www.linuxjournal.com/article/7034

  • The manpage for cvs; see the date format for -D for information on the date/time formats accepted by rpm's --rollback option


Previous Page
Next Page