You need a fast, reliable fix when a recent rollback Linux kernel update leaves your system unstable or unbootable. I know that sinking feeling—graphics glitches, broken drivers, or a server that won’t accept SSH can halt work fast.

We’ll show a clear path to get you back to a known-good version without losing future security updates. First, you’ll test another version from the GRUB “Advanced options” menu to confirm the kernel caused the issues.

Next, we cover practical steps for Debian/Ubuntu, Arch, and Fedora—how to remove a problematic package or prefer an alternative. For cloud servers like AWS EC2, we explain using a rescue instance or the serial console to mount, chroot, adjust GRUB, and set a stable default before rebooting.

Key Takeaways

• Test another kernel version from GRUB first to isolate the problem.
• Follow distro-specific commands—apt, pacman, or dnf—to remove or prefer kernels safely.
• On servers, use rescue tools or EC2 serial console to recover a non-booting system.
• Set the known-good entry as the GRUB default so the system boots reliably.
• Balance stability and security—keep records and verify the running version after changes.

Before you roll back: risks, backups, and what “kernel update” means today

Before you change the running environment, pause and weigh risks, backups, and what a modern kernel update touches in your operating system. The core controls drivers, modules, and how hardware talks to software, so small changes can surface large problems fast.

We start by assessing risk—rolling to an older release can restore stability, but kernel updates often include security fixes. For production systems, plan a maintenance window and a clear rollback plan.

Make sure you snapshot disks and copy key configs before you test. Many distros keep multiple kernels installed, so you can boot an earlier one to confirm the source of issues without removing packages immediately.

• Document the current version, boot params, and module list — these notes speed recovery.
• Know common post-update issues: graphics glitches, network drops, storage driver faults, and intermittent panics.
• Remember: application or library bugs can mimic kernel problems; isolate the culprit before you remove anything.

Diagnose quickly: boot an older kernel from the GRUB menu

When a recent kernel causes trouble, the fastest way to rule it out is to boot a prior version from GRUB and watch how the system behaves.

Access the GRUB menu on reboot and use Advanced options

If the menu is hidden, hold Shift while the machine starts to access grub menu. From there pick “Advanced Options for [Distro]” to reveal a list of installed boot entries.

Select an older or recovery kernel version to confirm the issue

Scan the list — you’ll usually see the newest entry first, followed by older entries and a recovery option. Choose an older kernel to test normal operation.

• Hold Shift during reboot if the boot loader is hidden, then open Advanced options to view all entries.
• Look for multiple versions by version number; pick an older non-recovery option to boot a prior image.
• Avoid recovery mode at first — a standard option gives a fair test of daily use.
• Note the kernel version you tested and any change in stability or hardware behavior.
• Some systems list only one entry; if so, use recovery to get a shell and inspect logs.
• Example: “Advanced Options for Ubuntu” → “Linux 5.x.y-zz-generic” — select the prior entry to verify the fault.

If the problem disappears after booting the older kernel, you’ve isolated the regression and can plan the next step without removing packages yet.

How to rollback Linux kernel update on popular distros

Quick, precise steps for Debian/Ubuntu, Arch Linux, and Fedora help you remove a faulty kernel package or prefer a stable alternative. Only act while booted into the version you want to keep.

Debian / Ubuntu

First, list installed kernel packages to get exact names. Run the following command and note the package and version:

apt list –installed | grep linux-image

Then remove the problematic package with the exact package name. Use the following command while running the good version:

sudo apt remove <kernel-name>

Re-list installed kernel packages to confirm you removed only the intended entry.

Arch Linux

On a rolling distro I prefer swapping to an alternative kernel, like linux-lts or linux-zen, instead of a risky downgrade.

If you must remove a kernel package, run:

sudo pacman -R <kernel-name> <kernel-name>-headers

To sync to a specific version use the following command pattern (check Arch Package Search for exact versions):

sudo pacman -S <kernel-name>=x.x.x <kernel-name>-headers=x.x.x

Fedora

List installed core packages to find the offending version:

rpm -qa kernel-core

Then remove the bad entry precisely:

sudo dnf remove kernel-core-x.x.x-xxx.fcxx.x86_64

Fedora keeps older entries by default, so you can usually boot a newer or older version while you troubleshoot.

• Always operate as root or with sudo and confirm the name before removal.
• Test an older GRUB entry first, then remove the faulty package by exact name.
• Verify via re-listing that only the intended kernel packages remain.

Rebuild GRUB configuration and set your default kernel

I recommend setting the known-good entry as default, then rebuilding the boot menu so the system boots predictably.

Which method you use depends on your bootloader version and distro. Below I give concise, copy-paste commands so you can apply the right grub workflow quickly.

Legacy GRUB (GRUB1)

Change the default index directly in /boot/grub/grub.conf. If the stable option sits at position 1, run the following:

sed -i ‘/^default/ s/0/1/’ /boot/grub/grub.conf

GRUB2: Debian, Ubuntu, AL2 and RHEL7

Edit /etc/default/grub to save the chosen entry, then regenerate the boot menu and pick the next boot.

• sed -i ‘s/GRUB_DEFAULT=0/GRUB_DEFAULT=saved/g’ /etc/default/grub
• Run update-grub (Debian/Ubuntu) or grub2-mkconfig -o /boot/grub2/grub.cfg (RHEL7/AL2).
• Set the next boot with grub-set-default 1 or grub2-set-default 1.

If os-prober blocks the rebuild, add GRUB_DISABLE_OS_PROBER=true to /etc/default/grub and rerun the command.

GRUB2 on RHEL8, CentOS8 and AL2023 (BLS + grubby)

Use grubby to list boot entries and set the default by path. Find versions:

grubby –info=ALL

Then set the default with the exact vmlinuz path:

grubby –set-default=/boot/vmlinuz-<version>

Validate your choice with grubby –default-kernel so you confirm the default matches the intended version.

• Keep at least one known-good kernel installed before removing others.
• Test booting the selected option once to ensure the system starts as expected.
• Be minimal — change the default grub setting and rebuild grub configuration, then verify.

Cloud and servers: recover on Amazon EC2 when the system won’t boot

I know a dead EC2 instance feels urgent. Start with the EC2 Serial Console if it’s enabled — it gives console access when networking is down and often lets you set a working boot entry or edit the default grub choice directly.

Use EC2 Serial Console to access the instance without network

If the console is available, open it and interrupt boot. You can set the default grub entry or load a known-good image and reboot. This avoids detaching the root volume in many cases.

Rescue instance workflow: detach root volume, mount, and chroot safely

If console access is not possible, snapshot the root volume, stop the instance, and detach the root device (for example /dev/xvda). Attach that volume to a rescue host (for example /dev/sdf).

On the rescue host run the following commands: sudo -i, lsblk, mount -o nouuid /dev/xvdf1 /mnt. Then bind mount /dev, /proc, /run, and /sys and run chroot /mnt to work inside the broken system.

Update GRUB defaults and set a stable kernel

Inside the chroot edit grub settings. For Ubuntu set GRUB_DEFAULT=saved, run update-grub, then grub-set-default 1. On RHEL7/AL2 run grub2-mkconfig and grub2-set-default 1. For RHEL8/CentOS8/AL2023 use grubby –info=ALL and grubby –set-default=/boot/vmlinuz-<version> to choose the stable kernel.

Exit the chroot, unmount in reverse, detach and reattach the volume to the original instance as root, and start it. After boot, verify the kernel version and confirm system recovery before removing any images or extra kernels.

Verify, stabilize, and prevent future kernel issues

Once the system runs well on the older image, verify active versions and make that state persistent.

Confirm the running kernel version and boot order

First, make sure the system is using the release you expect. Run uname -r to confirm the active kernel version.

Next, check GRUB’s saved default entry. Use grub-set-default or grubby –info=ALL on RHEL8+ to verify the chosen default matches the older kernel you want.

Make the older kernel the permanent default and rebuild GRUB

If the older kernel is stable, set it as the default kernel and regenerate the boot menu.

On Debian/Ubuntu set GRUB_DEFAULT=saved, run update-grub, then use grub-set-default to lock the choice. On RHEL8-style systems use grubby –set-default=/boot/vmlinuz-<version>.

Pin, hold, or version-lock kernel packages to control updates

To prevent surprise changes, pin the kernel package in your package manager.

• Debian/Ubuntu — use apt-mark hold <package-name> to keep a specific version.
• Fedora — use dnf versionlock to pin a release while applying other security updates.
• Arch Linux — prefer linux-lts or an alternative rather than downgrading the installed kernel.

Finally, document the versions and commands you ran. Reboot during a low-impact window to confirm the default persists and monitor the system for regressions.

You’re back on a stable kernel—next steps and maintenance tips

With the system back on an older kernel, keep that version as the default until a tested fix appears. I recommend scheduling a short test window and booting a newer kernel from the GRUB menu once — observe behavior, then revert if problems return.

Double-check /etc/default/grub and your grub configuration so a single test boot does not change the long-term default. Document the working kernel version and any symptoms you saw — that list speeds future triage and compliance checks.

Keep security patches for other packages applied and retain at least two installed kernels: one active, one standby. On Arch Linux prefer an LTS option during extended stabilization. When ready to promote a newer kernel, test in staging first and then make it the default.