Fix Missing Boot Files on RHEL 8: The “Phantom Update” Trap | OS Assistance

Author: Thomas C
Category: Linux Operation
Target Systems: RHEL 8, Rocky Linux 8, AlmaLinux 8, Oracle Linux 8

Fix Missing Boot Files

During automated maintenance cycles across an enterprise server fleet, an administrator occasionally encounters an unsettling silent failure: a server reboots successfully, yet continues to execute an outdated kernel [2]. A quick inspection of the /boot directory reveals that the binaries for the patched kernel were never installed on disk—yet running dnf update simply responds with:

Dependencies resolved.
Nothing to do.
Complete!

This condition represents the “Phantom Update” trap. Below is an engineering analysis of why this failure occurs under Red Hat Enterprise Linux 8 and Rocky Linux 8, alongside a validated procedure to restore package-to-disk consistency.

1. Root Cause Analysis: The Multilib Transaction Failure

To identify why a patched kernel fails to materialize in /boot, one must trace the transactional execution pipeline of dnf:

1. Dependency Solver: Packages are matched, downloaded, and cached in local staging.
2. Transaction Test: File paths and multilib shared libraries are checked for collision against existing RPM headers.
3. Transaction Run: Binaries, configuration artifacts, and initramfs images are written to their target mount points.

If an environment hosts legacy 32-bit compatibility packages alongside standard 64-bit packages, updating a security-critical package such as Pluggable Authentication Modules (pam) frequently triggers a transaction conflict:

Error: Transaction test error:
  file /usr/share/man/man5/access.conf.5.gz from install of pam-1.3.1-40.0.1.el8_10.i686 conflicts with file from package pam-1.3.1-38.0.1.el8_10.x86_64
  file /usr/share/man/man5/limits.conf.5.gz from install of pam-1.3.1-40.0.1.el8_10.i686 conflicts with file from package pam-1.3.1-38.0.1.el8_10.x86_64
  ... (additional manual and config conflict lines)

Because the Transaction Test failed, execution terminated immediately. None of the downloaded packages in that batch—including the kernel—were unpacked onto the filesystem. However, if previous attempts were interrupted or partial metadata was recorded by secondary scripts, the local RPM database and DNF state tracker can desynchronize, registering the package as installed while /boot remains completely unpopulated.

Inspecting /boot on the affected host shows only older kernel images:

[root@Host23 ~]# ls -l /boot
total 182373
-rw-r--r--. 1 root root   202453 May 13 04:11 config-4.18.0-553.124.1.el8_10.x86_64
-rw-------. 1 root root 51656051 Jun  1 11:32 initramfs-4.18.0-553.124.1.el8_10.x86_64.img
-rwxr-xr-x. 1 root root 10891472 May 13 04:11 vmlinuz-4.18.0-553.124.1.el8_10.x86_64

2. Step-by-Step Resolution: Clearing the Block & Reinstalling

Step 1: Eliminate the Conflicting 32-Bit Package

Unless your node runs legacy proprietary 32-bit software requiring multilib compatibility, the i686 architecture variant of PAM should be purged:

sudo dnf remove pam.i686

Pre-execution check: Carefully audit the removal summary. Confirm that the solver is not removing core 64-bit production services as cascading dependencies.

Step 2: Force a Clean Kernel Reinstallation

Since the local database already considers the kernel package “installed,” standard dnf install or dnf update operations will bypass it. You must invoke an explicit reinstallation command to force DNF to download the RPMs, extract the binaries, and trigger Dracut to generate an initramfs:

sudo dnf reinstall kernel-core kernel-modules kernel

Step 3: Verify the Physical Kernel Artifacts

Confirm that both the compressed vmlinuz binary and the initramfs ramdisk exist in /boot prior to issuing a reboot instruction:

[root@Host23 ~]# ls -l /boot/vmlinuz-*
-rwxr-xr-x. 1 root root 10891472 May 13 04:11 /boot/vmlinuz-4.18.0-553.124.1.el8_10.x86_64
-rwxr-xr-x. 1 root root 10892520 Jun 15 14:02 /boot/vmlinuz-4.18.0-553.170.1.el8_10.x86_64

Once verified, cycle the node:

sudo reboot

Following startup, confirm active execution on the updated release:

[governor@Host23 ~]$ uname -r
4.18.0-553.170.1.el8_10.x86_64

3. Identifying Silent Blockers: Repositories and Version Controls

If you encounter situations where DNF skips kernel updates despite verified upstream availability, review these two common administrative restrictions:

A. Exclusion Directives in /etc/yum.repos.d/

Look for active package exclusion rules configured inside /etc/dnf/dnf.conf or per-repository configuration files under /etc/yum.repos.d/*.repo:

grep -rn "exclude=" /etc/yum.repos.d/ /etc/dnf/dnf.conf

If an entry such as exclude=kernel* is present, DNF will mask upstream kernel updates. You can temporarily override this behavior to confirm by appending the flag --disableexcludes=all:

sudo dnf check-update --security --disableexcludes=all

B. Active DNF Versionlock Profiles

The versionlock plugin is frequently used to freeze specific application tiers. Check whether the package has been pinned at a historical version:

sudo dnf versionlock list

If obsolete kernel strings appear, unpin them using:

sudo dnf versionlock delete "kernel-core-*"

4. Managing Storage Constraints in /boot

A filled /boot filesystem is the primary catalyst for corrupted transactions and missing kernel files. Because Dracut requires temporary uncompressed space to compile your ramdisk, insufficient capacity causes silent execution rollbacks.

Safe Kernel Housekeeping

Never run manual rm commands against raw boot directories. Instead, command DNF to cleanly remove older installation iterations while maintaining your current operating kernel and one reliable fallback:

sudo dnf remove --oldinstallonly --setopt installonly_limit=2 kernel

Persist this ceiling permanently by updating /etc/dnf/dnf.conf:

[main]
installonly_limit=2

Why Resizing /boot with LVM Is Rarely Recommended

Standard storage design on RHEL systems provisions /boot onto a standard MBR or GPT physical partition (typically /dev/sda1) rather than a Logical Volume. This ensures legacy BIOS and modern UEFI bootloaders can read kernel definitions directly without initializing device-mapper or volume group filters [2].

Because the physical sectors immediately following /boot are allocated to the primary LVM Physical Volume (PV), resizing /boot requires shrinking the primary filesystem, shrinking the LVM PV, and physically moving disk partition start boundaries [3, 4]. In production environments, this carries an unacceptable risk of data corruption [5]. Enforcing kernel retention ceilings via installonly_limit provides a far safer, zero-risk maintenance posture.

---

Summary Checklist

Symptom	Diagnostic Command	Remediation
Transaction Test Conflict	dnf update output	Remove o