RHEL 8 Kernel Missing from /boot? How to Diagnose and Reinstall Safely
If DNF reports “Nothing to do” but the expected kernel image is missing from /boot, the server needs a closer check before its next reboot. DNF’s update result tells you whether it found an applicable package update through the enabled repositories and current configuration. It does not confirm that every kernel file expected on disk is present.
This guide shows how to compare the installed RPM records with the files and mount state, check common DNF update blockers, and use DNF to reinstall a kernel package when the package is recorded as installed but its files are missing. The examples target Red Hat Enterprise Linux (RHEL) 8. Other RPM-based distributions may use similar commands, but package versions, repositories, and vendor procedures can differ.
Before you start: Take a VM snapshot or verified backup according to your change process. Confirm that you have an approved maintenance window and a recovery path such as cloud console or out-of-band access before changing kernel packages or rebooting a production server.
Why can DNF say “Nothing to do” when a kernel file is missing?
DNF works from package metadata, installed package records, enabled repositories, and configured policies. A “Nothing to do” result means that DNF did not select an applicable update in that transaction. It is not a file-integrity check for paths such as /boot/vmlinuz-<kernel-version>.
Several conditions can lead to this mismatch. A file may have been removed outside the package manager, the separate /boot filesystem may not be mounted, an update may have been blocked by a repository or version policy, or a kernel installation script may not have produced the expected boot artifacts. Red Hat also documents a RHEL 8 case where kernel files are not deployed when /etc/machine-id is missing.
Treat these as separate checks. A failed package transaction may explain why an update did not complete, but it does not by itself prove that the RPM database is out of sync or explain why files from an already-installed kernel are absent.
1. Check the running kernel, installed packages, and /boot
Start with read-only checks. They help determine whether the server is running the intended kernel and whether the expected boot filesystem is mounted.
uname -r
cat /etc/redhat-release
findmnt -T /boot
df -h /boot
rpm -q kernel kernel-core kernel-modules
ls -lh /boot/vmlinuz-* /boot/initramfs-*.img 2>/dev/nullCompare the output from rpm -q with the filenames under /boot. On RHEL 8, kernel-core provides the kernel image and core files; kernel-modules provides additional modules; and kernel is a meta-package. The package names and version-release values should match for the kernel you plan to boot.
If /boot is a separate filesystem, confirm that it is mounted from the expected device. A missing mount can make the directory appear empty or show files from the underlying root filesystem. Also check available space before attempting a reinstall.
To verify the files recorded for one installed kernel package, substitute its exact version-release and architecture from the rpm -q output:
rpm -V kernel-core-<version-release.arch>RPM prints verification differences, including a “missing” marker when a tracked file is absent. If the package is not listed by rpm -q, it is not an installed package record; use the appropriate install procedure instead of dnf reinstall.
2. Check whether DNF can see the expected kernel version
Before changing packages, confirm that the right repositories are enabled and that the target kernel version is available:
dnf repolist --enabled
dnf list --showduplicates kernel kernel-core kernel-modulesReview package exclusions in the main DNF configuration and repository files:
grep -RniE '^(exclude|excludepkgs)=' /etc/dnf/dnf.conf /etc/yum.repos.d/If your environment uses the DNF versionlock plugin, check its policy as well:
dnf versionlock listThe command may be unavailable when the plugin is not installed. Do not remove an exclusion or version lock without checking your organization’s change controls. If policy permits, you can use DNF’s --disableexcludes=all option for a one-time comparison, then return to the approved repository configuration.
3. Reinstall the exact kernel package when RPM shows it installed
If rpm -q shows the affected kernel version as installed, its tracked files are missing, and the matching RPM is available from an approved repository, use DNF’s reinstall operation. Replace the placeholders below with the same exact version-release and architecture for the installed kernel packages. Review the proposed transaction before confirming it.
sudo dnf reinstall \
kernel-<version-release.arch> \
kernel-core-<version-release.arch> \
kernel-modules-<version-release.arch>DNF can reinstall only packages that are recorded as installed and available from an enabled repository. If the exact package version is unavailable, verify repository access and entitlement or use your organization’s approved package source. Avoid downloading kernel RPMs from an untrusted source.
After the reinstall completes, check the target files and boot entry before scheduling a reboot:
ls -lh /boot/vmlinuz-<version-release.arch> \
/boot/initramfs-<version-release.arch>.img
grubby --info=ALLIf DNF reports success but the files are still missing, stop and review the transaction details, the /boot mount, available space, and /etc/machine-id. Do not repeatedly reinstall or rebuild the initramfs without understanding the underlying error. For managed RHEL systems, consult Red Hat Support or your platform team when package scriptlets or boot artifacts continue to fail.
When all expected files and a usable boot entry are present, reboot during the approved window. After startup, verify the active kernel:
uname -rThe running version should match the kernel you intended to activate.
4. Handle PAM multilib conflicts carefully
A DNF transaction test can report file conflicts between architecture variants of a package, such as pam.i686 and pam.x86_64. If that happens, treat the conflict as a package-management issue to investigate. Do not assume that every 32-bit PAM package is unnecessary, and do not remove it simply because the server is 64-bit.
First inspect the exact installed packages and the removal transaction. The --assumeno option lets you review the proposed changes without accepting them:
rpm -q pam.i686 pam.x86_64
sudo dnf remove pam.i686 --assumenoIf a legacy application depends on 32-bit libraries, involve its owner before changing packages. Also check for inconsistent repository content or package versions. A failed transaction means that transaction did not complete; it is not evidence by itself that unrelated RPM database records were partially written.
5. Free /boot space with package-manager cleanup
If df -h /boot shows that the filesystem is full, review installed kernels and your retention policy before cleanup. Avoid deleting kernel images or initramfs files with rm; package-manager cleanup preserves RPM bookkeeping.
DNF provides an --oldinstallonly option for removing older install-only packages while retaining the running kernel and newer versions. Review the proposed transaction carefully and preserve the number of fallback kernels required by your operational policy:
sudo dnf remove --oldinstallonlyDo not reduce kernel retention simply to make an update pass if the server needs a tested fallback kernel. If the boot filesystem is consistently too small for the system’s kernel and initramfs files, plan a storage change through your platform’s supported process.
Quick troubleshooting checklist
| Finding | What to check next |
|---|---|
| DNF says “Nothing to do” | Enabled repositories, exclusions, version locks, and available kernel versions |
| RPM lists a kernel but files are missing | findmnt -T /boot, rpm -V kernel-core-<NEVRA>, and the last DNF transaction |
| DNF reports a PAM multilib conflict | Exact package versions, enabled repository consistency, and application dependencies |
/boot has little or no free space | DNF install-only kernel cleanup and the approved kernel retention policy |
| Reinstall succeeds but files remain absent | /etc/machine-id, package scriptlet output, mount state, and vendor support guidance |
Frequently asked questions
Does dnf update repair missing files from an installed kernel?
Not necessarily. An update checks for applicable package updates; use rpm -V to inspect package files and consider dnf reinstall when the exact installed package is available and its files are missing.
Should I remove pam.i686 to fix a kernel update?
Only if you have confirmed that the package is not required and the proposed DNF transaction is safe. A multilib conflict should be diagnosed from its exact error and dependencies.
Can I delete old kernel files manually to make room?
Use DNF’s install-only cleanup and review the transaction. Manual file deletion can leave package records and bootloader entries inconsistent.
Need help with Linux patching or kernel troubleshooting?
OS Assistance provides remote Linux administration and infrastructure support. Contact OS Assistance to discuss a server issue or learn about Linux Care.
Author: Thomas Cherian | OS Assistance
Reviewed: October 2026
