Troubleshooting Red Hat 8 Kernel Updates: New Kernel Files Exist But Not Booting

Jul 28, 2025 by ADMIN 81 views

Troubleshooting Kernel Updates on Red Hat 8: New /boot/vmlinuz and /boot/initramfs Exist, but Kernel Listing Doesn't Show the New Install

Hey everyone! Ever run into a situation where you've updated your kernel on Red Hat 8, and everything seems to go smoothly, but after a reboot, your system stubbornly sticks to the old kernel? You're not alone! This can be a real head-scratcher, especially when you see the new /boot/vmlinuz and /boot/initramfs files sitting there, but the bootloader just isn't picking them up. Let's dive into how to troubleshoot this issue and get your system booting with the latest kernel.

Understanding the Problem

Before we get our hands dirty with troubleshooting, let's make sure we understand what's going on. When you run a dnf update (or yum update on older systems), the package manager does a lot behind the scenes. For kernel updates, it not only downloads and installs the new kernel files (/boot/vmlinuz-* and /boot/initramfs-*) but also updates the bootloader configuration (usually GRUB2) to include an entry for the new kernel. So, what could go wrong?

There are several potential culprits:

Bootloader Configuration Issues: The GRUB2 configuration might not have been updated correctly. This could be due to errors during the update process, manual modifications to the GRUB2 configuration, or even a corrupted GRUB2 configuration file.
Insufficient Disk Space: If your /boot partition is full, the new kernel files might not have been fully written, or the GRUB2 configuration couldn't be updated.
Incorrect GRUB2 Configuration: It's possible that the GRUB2 configuration is pointing to the wrong partition or device for the kernel and initramfs files.
Dracut Issues: Dracut is the tool responsible for creating the initramfs image. If there are issues with Dracut, the initramfs image might be incomplete or corrupted.
File System Errors: Errors on the /boot partition can prevent the bootloader from reading the kernel and initramfs files.

Let's say you've just run a dnf update, and it seemed to go off without a hitch. You were expecting to boot into kernel version 4.18.0-553.56.1.el8_10.x86_64 after the reboot, but your server is still running the old kernel. Frustrating, right? This is the exact scenario we're going to tackle.

Step-by-Step Troubleshooting

Okay, let's get down to the nitty-gritty and figure out how to solve this. We'll go through a series of checks and fixes, starting with the most common issues and moving towards the more complex ones. Remember, it's always a good idea to have a backup or a way to access your system remotely in case something goes wrong.

1. Verify the Installation

First, let's double-check that the new kernel is indeed installed on your system. You can do this by listing the kernel packages:

rpm -qa | grep kernel

This command will show you all the kernel packages installed. You should see the new kernel version in the list. If you don't see it, then the update might not have been successful, and you might need to try the update again. This is the first step, guys, making sure that the kernel is there in the first place.

2. Check /boot Contents

Next, let's peek into the /boot directory and make sure the vmlinuz and initramfs files for the new kernel are present and accounted for. Use the following command:

ls -l /boot

You should see files like vmlinuz-4.18.0-553.56.1.el8_10.x86_64 and initramfs-4.18.0-553.56.1.el8_10.x86_64.img. If these files are missing, it indicates a problem during the kernel installation. Maybe there wasn't enough space, or something else went wrong. We'll need to dig deeper if they're not there. If they are present, we can move on to the next check.

3. Examine GRUB2 Configuration

This is where things get a little more interesting. GRUB2 is the bootloader, and it's responsible for presenting you with the kernel choices at boot time. We need to see if GRUB2 knows about our new kernel. The main GRUB2 configuration file is /boot/grub2/grub.cfg (or /boot/efi/EFI/redhat/grub.cfg on UEFI systems). However, you shouldn't edit this file directly! It's generated automatically. Instead, we'll use GRUB2 tools to check and update the configuration.

First, let's see what kernels GRUB2 knows about:

grub2-mkconfig -o /dev/null | grep menuentry

This command simulates generating the GRUB2 configuration and filters the output to show the menu entries. Look for the entry corresponding to your new kernel. If it's not there, GRUB2 hasn't picked up the new kernel yet. This is a crucial step, so pay close attention!

4. Regenerate GRUB2 Configuration

If the new kernel isn't in the GRUB2 menu, we need to regenerate the configuration. This will tell GRUB2 to scan for installed kernels and add them to the boot menu. Use the following command:

grub2-mkconfig -o /boot/grub2/grub.cfg

(or grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg on UEFI systems). This command will regenerate the grub.cfg file. Now, let's check again if the new kernel is listed using the command from step 3. If it's there, great! We're making progress.

5. Check Default Kernel

Even if the new kernel is in the GRUB2 menu, it might not be the default one. To check the default kernel, use:

grub2-editenv list

Look for the saved_entry variable. This tells you which menu entry GRUB2 will boot by default. If it's not pointing to the new kernel, we need to change it. There are a couple of ways to do this:

Using grub2-set-default: This command lets you set the default kernel by its menu entry number. You'll need to figure out the correct number from the output of grub2-mkconfig command in step 3.
```
grub2-set-default 'menuentry_number'
```
Replace 'menuentry_number' with the actual number. For example, 0 for the first entry, 1 for the second, and so on.
Using grub2-editenv: This is a more direct way to set the saved_entry variable.
```
grub2-editenv set saved_entry='menu_entry_name'
```
Replace 'menu_entry_name' with the full name of the menu entry for your new kernel, which you can find in the output of grub2-mkconfig.

After setting the default kernel, it's a good idea to update the GRUB2 configuration again:

grub2-mkconfig -o /boot/grub2/grub.cfg

(or grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg on UEFI systems).

6. Check /boot Partition Space

As we mentioned earlier, a full /boot partition can cause issues. Let's check the disk space usage:

df -h /boot

If the /boot partition is close to 100% full, you might need to remove old kernels to free up space. You can remove old kernel packages using rpm -e:

rpm -e --nodeps kernel-old_version

Replace kernel-old_version with the full package name of the kernel you want to remove. Be careful not to remove the currently running kernel or the new kernel you're trying to boot into! After removing old kernels, regenerate the GRUB2 configuration.

7. Dracut Issues

If the initramfs image wasn't created correctly, it can prevent the kernel from booting. Let's try regenerating the initramfs image for the new kernel:

dracut -f /boot/initramfs-new_kernel_version.img new_kernel_version

Replace new_kernel_version with the full kernel version (e.g., 4.18.0-553.56.1.el8_10.x86_64). This command will force Dracut to recreate the initramfs image. If there are any errors during this process, it might indicate a deeper issue with Dracut or your system configuration.

8. File System Check

File system errors on the /boot partition can also cause problems. Let's run a file system check:

xfs_repair /dev/your_boot_partition

Replace /dev/your_boot_partition with the actual device name of your /boot partition (e.g., /dev/sda1). You might need to unmount the /boot partition first if it's currently mounted read-write. Running xfs_repair (or fsck for other file systems) can help fix any errors on the file system.

Example Scenario and Solution

Let's say you've updated to kernel 4.18.0-553.56.1.el8_10.x86_64, but after rebooting, you're still on the old kernel. You've checked the /boot directory, and the vmlinuz and initramfs files are there. You've run grub2-mkconfig, and the new kernel shows up in the menu entries. However, when you check the default kernel using grub2-editenv list, you see that saved_entry is pointing to the old kernel.

The solution? You need to set the default kernel to the new one. Let's say the menu entry for the new kernel is "4.18.0-553.56.1.el8_10.x86_64". You would run:

grub2-editenv set saved_entry='4.18.0-553.56.1.el8_10.x86_64'

Then, update the GRUB2 configuration:

grub2-mkconfig -o /boot/grub2/grub.cfg

Now, reboot your system, and you should be booting into the new kernel!

Best Practices for Kernel Updates

To minimize the chances of running into these issues, here are some best practices for kernel updates on Red Hat systems:

Keep Your System Updated: Regularly update your system using dnf update to get the latest security patches and bug fixes.
Monitor Disk Space: Keep an eye on the disk space usage of your /boot partition. If it's getting full, remove old kernels.
Test in a Non-Production Environment: If possible, test kernel updates in a non-production environment before applying them to production systems.
Have a Backup Plan: Always have a backup plan in case something goes wrong during the update process.
Read Release Notes: Before updating, read the release notes for the new kernel to be aware of any potential issues or changes.

Conclusion

Troubleshooting kernel updates can be a bit tricky, but by following these steps, you should be able to diagnose and resolve most common issues. Remember to take it one step at a time, and don't be afraid to ask for help if you get stuck. The Red Hat community is full of knowledgeable people who are willing to lend a hand. Kernel updates are a crucial part of keeping your system secure and stable, so it's worth the effort to get them right. Keep your systems up-to-date, guys, and you'll be in good shape! Remember to always double-check your work and have a backup plan in place. Happy troubleshooting!

I hope this comprehensive guide helps you guys out! If you've got any other tips or tricks for troubleshooting kernel updates, feel free to share them in the comments below. Let's help each other keep our systems running smoothly!