How to Fix AlmaLinux Kernel Panic on Boot: 7 Quick Steps From a NOC Engineer

Let’s skip the small talk. Your server won’t boot, the screen is black, or you’re stuck at a kernel panic message before the login prompt even shows up. This is how you fix an AlmaLinux kernel panic on boot — ordered from the quickest fix to the deepest one. Follow them in order, don’t skip ahead.

Before we touch any command, remember one thing: a kernel panic isn’t the end of the world. It’s just the kernel saying “I can’t keep going safely, so I’m stopping.” Think of it like your car dying at a red light — annoying as hell, but almost always restartable once you know what killed it.

Here’s what a lot of people miss: a kernel panic at boot isn’t a single problem, it’s a bunch of different problems that all look the same on screen. That’s why the single most important step is reading the error message first. Don’t just reboot on autopilot. Rebooting over and over without diagnosing is like pressing the TV power button repeatedly hoping the channel will change by itself.

What Is a Kernel Panic and Why Does It Happen on AlmaLinux?

A kernel panic on AlmaLinux happens when the kernel can’t continue doing its job and stops completely. You’ll usually see something like “Kernel panic – not syncing” or “Unable to mount root fs”. The server hangs during boot, there’s no login prompt, and you have to restart it manually.

From handling hundreds of servers, the most common causes of kernel panic at boot on AlmaLinux look roughly like this:

• /boot is full — the new kernel file was written halfway and got corrupted.
• Kernel update failed — initramfs wasn’t built properly.
• Root filesystem not found — UUID changed, storage driver didn’t load.
• Hardware driver trouble — usually a GPU or NIC on physical machines.
• Bad RAM or disk — the kernel failed reading a certain area.
• Broken GRUB config — the boot entry points at the wrong kernel.

The impact is no joke if this is a production server. Every minute of downtime is lost revenue, a pileup of queued emails, angry clients on the phone, and management typing at you in all caps. That’s why you need a quick but safe fix procedure — and that’s exactly what I’ll walk you through below.

Step 1: Read the Error Message First

The key to fixing an AlmaLinux kernel panic is reading the message on screen before you restart. Snap a photo or write it down. Use this table to match it right away:

Of all of these, the two that show up most in production are “Unable to mount root fs” and “Fatal exception”. If you get either one, skip to Step 2 — you’ll most likely finish in a few minutes.

Step 2: Boot Into the Previous Kernel From GRUB

If the kernel panic appeared right after a kernel update, the fastest move is booting an older kernel. When the server starts, pick Advanced options for AlmaLinux in the GRUB menu, then choose the previous kernel version — the last one that booted normally.

No GRUB menu showing up? Hammer Esc or Shift as the server starts. On KVM VPS instances the timing can be a bit picky, but Esc works most of the time.

Why does this matter? If you can boot an older kernel, the root cause is almost certainly the new kernel or its initramfs. And here’s the kicker — this is usually a failed kernel update whose files were written halfway because /boot ran out of space.

Step 3: Check Whether /boot Is Full

Boot into the old kernel first, then check:

df -h /boot
ls -lh /boot

If usage is at 100% or close to it — there’s your culprit. A kernel update needs room to write the new vmlinuz, initramfs, and symlinks. No room = corrupted files = kernel panic on boot. A classic case that still happens way too often.

The fix is removing old, unused kernels. But before you remove anything, make sure you’re not booted into the kernel you’re about to delete:

uname -r

That’s the kernel that’s currently running — leave it alone. Everything else with an older version is fair game. List what’s installed:

dnf list installed kernel-core

Now, before removing anything, remember:

Example: your running kernel is 4.18.0-553 and you want to remove 4.18.0-513:

dnf remove kernel-core-4.18.0-513*

Then rebuild the initramfs to keep things clean:

dracut -f

Step 4: Rebuild Initramfs or Reinstall the Kernel

If /boot has space but the new kernel still panics, try rebuilding the initramfs. The initramfs is the first-aid kit the kernel uses at boot — it holds the drivers and tools needed to mount the root filesystem. If it’s corrupted or outdated, the root won’t mount, and hello panic.

dracut -f --regenerate-all

Still no luck? Reinstall the problematic kernel-core. This rewrites the kernel and initramfs from scratch using the official AlmaLinux repos:

dnf reinstall kernel-core kernel-modules

Then regenerate the GRUB config. For BIOS boot mode:

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

For UEFI, the path is slightly different:

grub2-mkconfig -o /boot/efi/EFI/almalinux/grub.cfg

Step 5: Check the UUID and /etc/fstab

The “Unable to mount root fs” error also shows up when the UUID referenced in fstab or the kernel’s GRUB parameter no longer matches the current disk layout. This can happen after re-attaching a disk, cloning a VPS, or resizing.

blkid
cat /etc/fstab

Compare the UUIDs in fstab against the blkid output. For a visual overview of your disks:

lsblk -f

If they differ, update the UUID in fstab (or the root= parameter in GRUB). And when in doubt about which partition is which, hold off and double-check rather than mounting the wrong thing.

Step 6: Rescue Boot With Kernel Parameters

If none of the above worked, boot into rescue mode from the AlmaLinux rescue ISO. On a KVM VPS you can reach GRUB through the VNC console. At the GRUB menu, press e to edit the entry, find the line starting with linux, and append to the end of it:

rd.break

This drops you into the ramdisk before the root is mounted — extremely useful for debugging fstab. If you suspect a GPU or video driver is causing the panic, add this too:

nomodeset

And to keep the server from rebooting into an endless panic loop, set a timeout:

panic=30

Save your changes with Ctrl+X. This mode isn’t persistent, but it’s enough to boot once and read the logs.

Step 7: Diagnose From the Kernel Logs

Once the server boots after the steps above, check the failed boot log right away. journalctl keeps boot history, so you can inspect the previous boot that panicked:

journalctl -b -1 -k -p err --no-pager

Here’s a real log sample from a server that failed to boot because the root UUID changed. Watch the pattern line by line:

Aug 02 02:13:41 server-01 kernel: sd 2:0:0:0: [sda] No Caching mode page found
Aug 02 02:13:41 server-01 kernel: sd 2:0:0:0: [sda] Assuming drive cache: write through
Aug 02 02:13:41 server-01 kernel: dracut: Mounted root filesystem /dev/sda2
Aug 02 02:13:41 server-01 kernel: dracut: Switching root
Aug 02 02:13:41 server-01 kernel: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Aug 02 02:13:41 server-01 kernel: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-362.24.1.el9_3.x86_64
Aug 02 02:13:41 server-01 kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Aug 02 02:13:41 server-01 kernel: Call Trace:
Aug 02 02:13:41 server-01 kernel: dump_stack+0x5f/0x80
Aug 02 02:13:41 server-01 kernel: panic+0x17e/0x340
Aug 02 02:13:41 server-01 kernel: mount_block_root+0x1a4/0x2a0
Aug 02 02:13:41 server-01 kernel: prepare_namespace+0x143/0x180
Aug 02 02:13:41 server-01 kernel: kernel_init_freeable+0x236/0x260
Aug 02 02:13:41 server-01 kernel: kernel_init+0x1a/0x130

Reading the pattern:

• Lines 3-4: The initramfs (dracut) mounted a temporary root and is about to “Switch root”. Totally normal.
• Line 5: ERROR — “Unable to mount root fs on unknown-block(0,0)”. This is the line that matters: the kernel failed to switch to the real root because it couldn’t find the device.
• Lines 6-14: Standard panic call trace — don’t stare at it for too long, line 5 is your answer.

From here the diagnosis path is clear: check the root= parameter in GRUB and the UUIDs in fstab against blkid. In this case the root cause was a clone that changed the disk UUID while fstab still pointed at the old one.

Pro Tips: So It Never Happens Again

• Always keep at least 500MB free in /boot. Set up disk usage monitoring so you know before the next kernel update.
• After a kernel update, don’t reboot immediately. Verify the kernel and initramfs were written completely: ls -lh /boot | grep 5.14
• If the server is on KVM, always have a snapshot or backup before touching the kernel. Way cheaper than panicking at 2 AM.
• Set the GRUB default to a known-stable kernel before a big update. Check it with grub2-editenv list, then adjust saved_entry as needed.

Related Articles

• Troubleshooting a KVM VPS Boot Loop: Step-by-Step
• 7 Commands to Check a Full Disk Partition on Linux
• Monitoring Production Servers: A NOC Guide
• How to Update the AlmaLinux Kernel Safely

That’s honestly it. Read the message, boot an old kernel, check /boot, rebuild the initramfs, and only then start suspecting hardware. Before you close the ticket, make sure you’ve checked: 1) error logs, 2) /boot space, 3) root UUID. All clear? Case closed. Done.