Rollback with pkg(5) User Images
By ckamps on May 04, 2009
Right now, one has to either:
- Uninstall the package(s) that you don't want and reinstall the older version. The older version is available in the GUI by using the View|Show All Versions menu choice. From the command line, this can be done by specifying on the install command after first uninstalling the current version. While not atomic, this has the same effect as a "patchrm" in SVR4.
- If using a ZFS file system, run "zfs snapshot" on your image directory before doing the update. If you don't like the update, you can rollback to the snapshot.
- Create a backup of the image directory before doing the update.
Restore from the backup if you don't like the update.
A few notes:
- Currently there is no notion of an "update" defined in Update Center, i.e., all we have are installs of new versions of packages. So if you install new versions of 3 packages yesterday and 2 packages today, there isn't any way to identify that as 2 "updates". Rather, it is merely 5 installs of new package versions. The operational history does record the operations that are done, so one would be able to figure out from the history that two "update" operations were done. But there isn't anything in the GUI or CLI that takes advantage of this.
- From the CLI, installing an older version of a package
doesn't downgrade the package. So if you have version 2 of a package
installed and you do "pkg install some-package@1", it will output a
message saying that "No updates are available for the image".
Technically, there isn't any reason why IPS can't calculate what it
takes to go backward directly, although there could be some trickiness
relative to dependency calculations, but so far there hasn't been
emphasis on that. This is primarily because the OpenSolaris team
depends on ZFS for rollback of operating system updates. So rollbacks
of user image updates has not received as much attention. Eventually, I
would like to see the CLI support something like a "pkg rollback"
operation that would take a list of older package versions, and the
result would be that the image software would be restored to that
previous version of the packages.
a package also requires uninstalling the packages that depend on it. So
accomplishing the first option can be difficult when dependencies are
involved. If there were a "pkg rollback" command, it could take care of
this by possibly rolling back updates to the packages that depend on
the one being rolled back.
- The second option requires root access, which generally is not
required for user images.
- When a rollback is done with the second and third option, all other history in that image not related to the update is also lost. For example, with a database in the image, any updates that were made between the update and the rollback would be lost. Generally, when people think of patch backout with SVR4 packages, they assume that data changes made while the patch was there are not lost. This actually presents problems sometimes if the patch allows new data structures to be introduced or causes data reformatting, and then the old code has to deal with the new data (and sometimes it can't). These rollbacks are fool proof because they literally get you back to where you were, but that might not be where you want to be.