Redhat Linux Patching

— ny_wk

Red Hat Linux patching is the routine of applying vendor-tested updates — kernel fixes, security errata and bug fixes — to keep a RHEL server stable, supported and secure. Done well it is a low-risk, repeatable change; done carelessly it can break an application, a database, or boot itself. This guide walks through the full workflow a system administrator follows: pre-checks, backups, applying updates with yum or dnf, verifying the result, rolling back, and patching air-gapped servers offline.

What patching actually means on Red Hat Linux

A patch is a packaged correction to software already installed on the system — a security fix, a bug fix, or a feature update that ships before the next full release. The original meaning of “patch” is a text diff (the delta between two source files, created with diff and applied with patch), but on a production RHEL box you almost never apply raw source diffs. Instead, Red Hat distributes pre-built, signed RPM packages through its update channels, and you apply them with the package manager.

Applying periodic updates is one of the core duties of every Linux administrator. Patching improves security and reliability, but on rare occasions a new kernel or library can disturb an application or database. That is exactly why the disciplined process below — backup, change window, verify, and a known rollback path — matters more than the single update command itself.

Which package manager: yum vs dnf

• RHEL 5, 6, 7 use yum as the front end and rpm underneath.
• RHEL 8 and 9 use dnf (the modern rewrite of yum). On these releases yum is a symlink to dnf, so old commands still work, but you should learn dnf.
• Important: RHEL 5, 6 and 7 have all reached End of Maintenance. Run them only under Red Hat’s paid Extended Life-cycle Support (ELS) or migrate to RHEL 8/9. The legacy steps here are documented because thousands of such servers still exist, but the modern equivalents are called out throughout.

The Red Hat Linux patching process, step by step

This is the end-to-end change a sysadmin runs during a maintenance window. Follow it in order — the value of Red Hat Linux patching comes from the surrounding discipline, not just yum update.

1. Identify the host — physical or virtual. Your backup and rollback strategy depends on this.
   dmidecode -s system-product-name
dmidecode -t system
lspci | grep -i vmware
   A physical HP server reports a product name like ProLiant DL385 G5; a VM reports VMware Virtual Platform (or KVM/VirtualBox).
2. Take a backup or snapshot. For a VM, take a hypervisor snapshot so you can revert instantly. For physical hosts, rely on your enterprise backup (for example IBM Spectrum Protect / TSM) or an LVM snapshot of the root volume group. Never patch a server you cannot restore.
3. Acknowledge monitoring. Silence or acknowledge alerts in your monitoring tool (Nagios, Zabbix, Prometheus Alertmanager) so the reboot does not page the on-call team.
4. Stop the application and database cleanly. Shut the app and DB tiers down in the correct order so nothing is mid-write when the kernel changes.
5. Reboot once before you patch. A clean pre-patch reboot proves the box already boots and has no pending filesystem checks — so if it fails to come back after patching, you know the patch caused it.
6. Update the kernel (install, do not replace). A kernel update should be installed alongside the current kernel, never overwritten, so the old kernel stays in the GRUB menu as a fallback. The package managers do this by default: yum update kernel (or dnf update kernel) installs the new kernel and keeps the previous one bootable.
7. Apply the remaining updates. Run the full update for security errata and bug fixes (commands below).
8. Reboot into the new kernel. systemctl reboot (RHEL 7+) or init 6.
9. Verify. Confirm the running kernel and release, and that no updates are still pending: uname -r, cat /etc/redhat-release, yum check-update (or dnf check-update).
10. Start the app/DB and exit maintenance. Bring services back up, confirm they are healthy, then take the host out of maintenance mode in your monitoring tool.
11. Roll back only if needed. If the application breaks, use yum history undo / dnf history undo (see the rollback section) or revert the VM snapshot.

Pre-patching: capture the system state first

Before you change anything, record the current configuration so you can compare before-and-after and prove nothing else drifted. Write everything into one timestamped directory so it is easy to find later.

1. Create a dated working directory:
   mkdir -p /tmp/patching_$(date +%Y%m%d)
cd /tmp/patching_$(date +%Y%m%d)
2. Capture disk, mount and LVM layout:
   df -Ph > df.bkp
cat /etc/fstab > fstab.bkp
pvs > pvs.bkp; vgs > vgs.bkp; lvs > lvs.bkp
3. Capture kernel, boot loader and hardware facts:
   uname -r | tee kernel.bkp
cat /boot/grub2/grub.cfg > grub.bkp (RHEL 7+; on RHEL 5/6 use /etc/grub.conf)
   cat /proc/cpuinfo > cpu.bkp; cat /proc/meminfo > mem.bkp
4. Capture networking, services and processes:
   ip addr > ipaddr.bkp (modern replacement for ifconfig -a)
   ip route > route.bkp (replaces netstat -nr)
   ss -tunap > sockets.bkp (replaces netstat)
   systemctl list-unit-files > services.bkp (replaces chkconfig --list)
   ps -ef > ps.bkp
5. Capture SAN multipathing if present:
   multipath -ll > multipath.bkp
powermt display dev=all > powermt.bkp (EMC PowerPath hosts only)
6. Record the exact list of installed packages — the single most useful rollback reference:
   rpm -qa | sort > installed_rpms.bkp

On RHEL 5 and 6 the boot loader file is /etc/grub.conf; on RHEL 7, 8 and 9 it is GRUB 2 (/boot/grub2/grub.cfg). On the legacy releases you may still rely on ifconfig, netstat and chkconfig, but on RHEL 7+ prefer ip, ss and systemctl because the net-tools package is no longer installed by default.

Patching: the core update commands

Once the system state is captured and the change window is open, apply the updates. The table maps the classic yum commands to their modern dnf equivalents.

A few practical notes:

• Patch RPMs are signed. Keep GPG checking on so only Red Hat-signed packages install — it is the default and you should not disable it on production.
• To install a fresh package use yum install <pkg> / dnf install <pkg>. The old raw RPM verbs still exist: rpm -i installs, rpm -U upgrades, rpm -e erases, and rpm -qa | grep <name> queries what is installed. Prefer the package manager over raw rpm so dependencies resolve automatically.
• Apply only security fixes when a full update is too risky: dnf update --security patches just the vulnerabilities, leaving feature updates for later.

Post-patching verification

After the reboot, confirm the patch took effect and nothing regressed. This step is where you catch a half-applied update or a failed remount before users do.

1. Confirm the new kernel is running: uname -mrs. The version string should be higher than the one you saved in kernel.bkp.
2. Confirm the OS release: cat /etc/redhat-release — e.g. a 7.0 host that took a full update now reports 7.2 (Maipo) or later.
3. Confirm no updates are still pending: yum check-update / dnf check-update should return nothing (exit code 0).
4. Re-mount and compare filesystems: mount -a then df -Ph, and diff it against df.bkp to be sure every filesystem mounted.
5. Confirm storage and services are healthy: multipath -ll, systemctl --failed, and your application/DB service status.
6. Diff the package list to see exactly what changed: rpm -qa | sort | diff installed_rpms.bkp -.

Rollback: undoing a Red Hat Linux patch

If an update breaks an application, you need a fast, reliable way back. Your options depend on the RHEL version.

Snapshot revert (fastest, VMs and LVM)

If you took a VM snapshot or an LVM root snapshot in the pre-patch steps, reverting it is the cleanest rollback — it returns the entire system, including the kernel and every package, to its exact pre-patch state.

yum / dnf history (RHEL 6, 7, 8, 9)

Modern package managers keep a transaction history, so you can undo a specific patching transaction without touching anything else.

1. List transactions and find the patch you ran: yum history (or dnf history). Each row has an ID, the date, the action and how many packages were altered.
2. Inspect a transaction before reverting: yum history info <ID>.
3. Undo that exact transaction (reinstall the old versions, remove what it added): yum history undo <ID> / dnf history undo <ID>.
4. Or roll the system back to the state it had after a given transaction: yum history rollback <ID>.

Caveat: history-based rollback only works if the old package versions are still available in a repository (or were kept in the package cache). On a kernel update it is usually simpler and safer to just boot the previous kernel from the GRUB menu, since the old kernel is still installed.

Legacy RHEL 5 (rpm repackage)

RHEL 5 had no yum history. Administrators enabled RPM’s old repackage-on-erase feature so removed packages were saved and could be reinstated. In /etc/rpm/macros they added %_repackage_all_erasures 1, set tsflags=repackage in /etc/yum.conf, then rolled back with the time-based syntax rpm -Uvh --rollback '1 hour ago' (also '1 day ago', '1 week ago', or a date like 'March 20'). This mechanism was unreliable, is gone from modern RPM, and is documented here only for the few remaining RHEL 5 ELS hosts — on anything newer use dnf history or a snapshot.

Offline (air-gapped) patching for RHEL 7, 8 and 9

Red Hat recommends connecting systems to its CDN or a Satellite/Capsule server. But many secure environments keep servers off the public internet entirely. For those hosts you can patch offline by turning the official installation ISO into a local repository. Note that the binary DVD only takes a host to the latest minor version it contains (for example RHEL 7.0 to 7.2), so for cumulative patching most teams build a full mirror with reposync instead of a single ISO — but the ISO method is perfect for a one-off minor upgrade.

1. With a valid Red Hat subscription, download the Binary DVD ISO for the target minor release from the Red Hat Customer Portal and copy it to the server.
2. Mount the ISO read-only:
   mkdir /repo
mount -o loop rhel-server-7.2-x86_64-dvd.iso /repo
3. Record the current versions for comparison: cat /etc/redhat-release and uname -mrs (e.g. Linux 3.10.0-123.el7.x86_64).
4. Move aside any existing repo files so they do not interfere (you can restore them later): mkdir /etc/yum.repos.d/backup && mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/.
5. Create a local repo definition at /etc/yum.repos.d/local.repo pointing at the mounted ISO:
   [local-dvd]
name=RHEL Local DVD
baseurl=file:///repo
enabled=1
gpgcheck=1
gpgkey=file:///repo/RPM-GPG-KEY-redhat-release
6. List the repo to confirm the package count looks right: yum repolist (it should show your local-dvd repo with several thousand packages).
7. Clear stale metadata: yum clean all.
8. Run the update: yum update -y (use dnf update -y on RHEL 8/9). Because the system is not registered to Red Hat Subscription Management, it pulls exclusively from the DVD.
9. Reboot: init 6 (or systemctl reboot).
10. Verify the upgrade: uname -mrs now shows the newer kernel (e.g. 3.10.0-327.el7.x86_64) and cat /etc/redhat-release shows the new minor version (e.g. Red Hat Enterprise Linux Server release 7.2 (Maipo)).

Leaving gpgcheck=1 with the Red Hat GPG key is important even offline — it guarantees the packages on the ISO are genuine and untampered. The older habit of setting gpgcheck=0 works but silently disables that protection, so avoid it on production.

Common pitfalls when patching Red Hat Linux

• Overwriting the running kernel. Always install a new kernel alongside the old one (the default). If you force a replace and the new kernel will not boot, you have no fallback.
• No backup or snapshot. Patching without a tested restore path turns a small problem into an outage. Snapshot VMs; back up physical hosts first.
• Skipping the pre-patch reboot. If you do not reboot before patching, you cannot tell whether a post-patch boot failure was caused by the patch or by a pre-existing issue.
• Forgetting third-party and kernel modules. Out-of-tree drivers (storage HBAs, GPU, multipath, antivirus) may need a matching rebuild after a kernel update. Check vendor compatibility before the window.
• Disabling GPG checks. Setting gpgcheck=0 to make an install “just work” removes the guarantee that packages are Red Hat-signed.
• Patching unsupported releases blindly. RHEL 5/6/7 are past End of Maintenance; without ELS they receive no new security errata, so “fully patched” still leaves known CVEs open. Plan a migration to RHEL 8/9.
• Not exiting maintenance mode. Leaving alerts suppressed after the work is done means a real failure later goes unnoticed.

Key Takeaways

• Red Hat Linux patching is a process, not a single command: identify the host, back up, stop services, patch, reboot, verify, then exit maintenance.
• Use yum on RHEL 5/6/7 and dnf on RHEL 8/9; yum update -y and dnf update -y apply all errata, while --security applies only security fixes.
• Always install a new kernel alongside the old one so the previous kernel remains bootable from GRUB as your fastest rollback.
• Roll back with a VM/LVM snapshot or dnf history undo <ID>; the legacy RHEL 5 rpm --rollback trick is obsolete.
• Air-gapped servers can be patched offline by mounting the binary ISO as a local repo — keep gpgcheck=1 so packages stay verified.

Frequently Asked Questions

What is the difference between yum and dnf for patching?

dnf is the modern rewrite of yum with faster, more reliable dependency resolution and a cleaner API. RHEL 5, 6 and 7 use yum; RHEL 8 and 9 use dnf, where yum is just a symlink to it. The everyday commands (update, install, history, check-update) are identical, so your patching steps carry over.

How do I roll back a Red Hat patch if it breaks something?

The fastest rollback is reverting the VM or LVM snapshot you took before patching. Otherwise use yum history / dnf history to find the transaction ID and run dnf history undo <ID>. For a bad kernel, simply reboot and pick the previous kernel from the GRUB menu, since it is still installed.

How can I patch a RHEL server with no internet access?

Download the Red Hat binary DVD ISO with a valid subscription, copy it to the server, and mount it (mount -o loop rhel-...-dvd.iso /repo). Create a local .repo file with baseurl=file:///repo and gpgcheck=1, run yum clean all, then yum update -y (or dnf update -y). For ongoing patching, mirror the channels with reposync or use Red Hat Satellite.

How often should you patch Red Hat Enterprise Linux?

Apply critical security errata as soon as they are tested — typically monthly for security-only updates. Schedule full updates (packages plus kernel) on a regular maintenance cadence, commonly quarterly or twice a year for stable production systems, always behind a change window with a tested rollback.

For more Linux and system administration walkthroughs, subscribe on YouTube at @explorenystream.