Rolling back updates?

Latest response

Red hat says you can roll back package updates using "yum history''? I have experimented with this and it doesn't always work. Imagine patching your rhel server with hundreds of updates. And the system becomes unresponsive after reboot. Ok here comes "yum history" to the rescue. Unfortunately, "yum history" was a fake rescuer.

Red hat has to do something better for effectively rolling back. Better yet, copy boot environments and live upgrade technology from Solaris.

Heck RHEL is awesome, but if you can't role back, its terrible. Oh yes, there is satellite server. But I don't want to use that. Give us effective rolling back. Call oracle to get boot environments and live upgrade.

Sorry guys I am frustrated.

Thanks

Responses

Hi Arrey,

I understand your frustration and now personally include virtual machine snapshotting in patching workflow when deploying large amounts of patches to provide a rollback point. My recent experience with package functionality regression lead to the manual rollback of package + dependencies which was tedious.

I know Red Hat have focused some energy on this problem in the form of rpm-OSTree which is used in Project Atomic. This provides process of install / switch / rollback similar to what you may have used in Solaris.
http://www.projectatomic.io/docs/os-updates/

Unfortunately I haven't seen any word of this being rolled out to RHEL, but it would definitely fit your use case if it were to be available.

I believe the expected 'future state' is the 'cattle' approach used in the containerised world. Deploying servers as 'cattle' that can be destroyed if an upgrade/patch fails, and the environment can be torn down and rebuilt/deployed to a previous build version (or ideally the failed patch is found by automated testing before the environment is moved to the new upgraded instances). This unfortunately doesn't solve your immediate rollback problem (which is still a serious problem), it's just a different approach to provisioning that means the patching problem largely goes away... this also doesn't really solve the problem for the bigger enterprise products... but thought i'd mention it anyway!

On a server with LVM rootfs you could try LVM snapshots.

This freezes the parent LV and writes only new changes into a temporary snapshot LV. You do need to reserve some space in the root VG, either at install time or by shrinking existing things in the VG.

Even if the server is unresponsive you can get into Rescue Mode, find the LVs, discard the snapshot volume, and boot back up as if you'd never run the update.

If everything works, merge the snapshot into the parent.

This is covered at How can I deploy a system and use LVM snapshot/merge to be able to restore an earlier state of the root filesystem?

There is also an (unsupported) yum plugin which appears to do this automatically, though I've never used it myself.

Hope this helps!

Thanks guys for all the info. Much appreciate. I wish red hat will come up with something as simple as boot environments and liveupgrade in solaris.

Thanks again

It's currently not implemented in RHEL, though other operation systems, like archlinux, opensuse, SLES and even OEL does support this feature. Btrfs, as in documentation, is currently in technology preview mode. File a ticket (RFE) with redhat , hope they will implement it in some of RHEL 7.x releases , adding snapper and yum plugin for snapshotting btrfs in tech preview mode. Thanks.

PS: side note, there's "yum fssnapshot" command in rhel7
PS: another article in RH kb An Introduction to Btrfs

Some further comments:
- the most bulletproof approach to this: redeploy the system with the earlier patchlevel and use configmanagement ontop. Establishing this has also other advantages, i.e. you can in a simple way redeploy your production environment as a test environment to test something.
- the lvm snapshot/merge procedure is still a bit complicated due to /boot beeing on a partition. This is not likely to change in the near future. Probably, btrfs with snapshots reaches production stability earlier, and is providing similiar features then.

Chris

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.