Start by booting the older entry from GRUB, not by deleting the new package. If you need an Ubuntu revert to a previous kernel, choose Advanced options for Ubuntu, select the older normal kernel, and confirm the system is stable. Then decide whether to keep the newer kernel for testing, make the older one the default, or remove the faulty packages. That order avoids turning a recoverable boot problem into a reinstall.

Last updated: 2026-07-31

The safest Linux rollback has three stages:

• Boot the previous kernel.
• Prove the kernel caused the problem.
• Remove or disable the faulty kernel only after the older one works.

A kernel rollback does not undo every package installed by a Linux update. It changes the kernel and its boot entry. A full system restore needs package downgrades, filesystem snapshots, or a backup.

How do you revert Ubuntu to a previous kernel?

Use the GRUB menu first. Ubuntu normally keeps older kernels installed so you can test them without changing packages. Older entries may appear under Advanced options for Ubuntu or Previous Linux versions, depending on the GRUB layout. (help.ubuntu.com)

1. Restart the machine.
2. Show the GRUB menu. On many BIOS systems, hold Shift during startup. On UEFI systems, press Esc repeatedly after the firmware screen.
3. Select Advanced options for Ubuntu.
4. Choose an older kernel without the recovery mode suffix.
5. Let Ubuntu boot normally.
6. Confirm the running kernel:

uname -r

That output tells you which kernel is active. Do not trust the menu position alone. Kernel entries move as packages are installed and removed.

If the older kernel fixes the graphics problem, network failure, storage fault, or boot hang, you have a strong regression test. Leave the newer kernel installed for now. It may receive a fix before you finish the investigation, and deleting your only fallback is a poor way to gain disk space.

Canonical's Ubuntu kernel rollback documentation describes a different operation: reverting kernel packages in Ubuntu's archive. That process is for Ubuntu maintainers. On your machine, the correct first move is the GRUB boot entry, not archive tooling. (ubuntu.com)

What does booting a previous kernel prove?

Booting an older kernel proves that the problem is tied to the newer boot environment. It does not prove the kernel source itself is broken.

The failure may be in a related component:

• A graphics driver built with Dynamic Kernel Module Support (DKMS)
• A missing module in the initial RAM filesystem
• A changed boot parameter
• Firmware that the newer kernel handles differently
• A systemd service or userspace package upgraded at the same time

Run these checks after booting the older kernel:

uname -r
dkms status
journalctl -b -p err
journalctl -b -k

dkms status shows whether external modules built for the active kernel. journalctl -b -k shows kernel messages from the current boot. If a module failed to load, the kernel may be innocent and the module needs rebuilding.

If you booted the older kernel after a failed boot, inspect the previous boot:

journalctl -b -1 -k -p err
dmesg -T | tail -50

The -b -1 flag selects the previous boot. That tells you what happened before the working kernel started. Read the first useful error, not the final cascade of failed services.

Should you remove the newer Ubuntu kernel?

Usually, no. Keep it installed until the older kernel has survived normal work and the newer package is clearly the cause.

Removing the package has a few costs:

• You lose an easy comparison point.
• A later security fix may target that kernel line.
• Ubuntu's kernel metapackage may be removed with it.
• A mistaken purge can leave /boot without a usable fallback.

The right temporary rollback is often to boot the older kernel and wait for the next update. That is especially true on a desktop where the newer kernel still boots but breaks Wi-Fi, graphics, suspend, or a proprietary driver.

Remove the newer kernel when it fails consistently, consumes scarce space in /boot, or prevents package operations from completing. Before you do, confirm that you are not running it:

uname -r

If the output matches the kernel you plan to remove, reboot into the working entry first. Ubuntu's own documentation makes the same point for kernel changes: another kernel must be installed and selected before removal, or the machine can become unbootable. (documentation.ubuntu.com)

How do you remove a faulty Ubuntu kernel safely?

List the installed kernel packages and note the exact names:

dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' \
 'linux-image*' 'linux-modules*' 'linux-headers*' 2>/dev/null |
 grep '^ii'

The output shows installed image, module, and header packages. Compare those names with the result of uname -r. Keep every package belonging to the running kernel.

Then purge only the packages belonging to the faulty version:

sudo apt purge \
 linux-image-<bad-version> \
 linux-modules-<bad-version> \
 linux-modules-extra-<bad-version> \
 linux-headers-<bad-version>

Replace the placeholders with names that actually appeared in your package list. Do not copy a wildcard into apt purge and hope the shell guesses correctly. It will guess correctly right up until it does not.

Read the removal plan before accepting it. If apt proposes removing a package such as linux-generic, linux-image-generic, or the matching hardware-enablement metapackage, stop and review the list. Those metapackages pull in future kernel updates. Removing one can make the system stop tracking new kernels.

After the purge, rebuild the GRUB menu:

sudo update-grub

Then check what remains:

dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' \
 'linux-image*' 'linux-modules*' 2>/dev/null |
 grep '^ii'

Do not delete files such as /boot/vmlinuz-* or /boot/initrd.img-* by hand. The package database, initramfs hooks, and GRUB configuration must agree. Manual deletion creates a boot menu that lies, which is a poor debugging partner.

If the package manager is already wedged, repair the package state before removing kernels:

sudo dpkg --configure -a
sudo apt --fix-broken install

For a deeper cleanup, see the guide on why Apt autoremove leaves old kernels behind. apt autoremove is maintenance, not a kernel diagnosis tool. It does not know which kernel caused your outage.

How do you make the older kernel the permanent GRUB default?

Use a saved GRUB entry instead of guessing an entry number. Menu positions change whenever kernels are added or removed.

First list the generated menu entries:

grep -E "^(menuentry|submenu) " /boot/grub/grub.cfg

Find the exact submenu and kernel entry for the version that works. Then edit the GRUB defaults:

sudoedit /etc/default/grub

Set:

GRUB_DEFAULT=saved

Regenerate the configuration:

sudo update-grub

Now save the working entry as the default. Replace the text inside the quotes with the exact entry shown in your GRUB configuration:

sudo grub-set-default 'Advanced options for Ubuntu>Ubuntu, with Linux <good-kernel>'

Check that GRUB saved it:

sudo grub-editenv list

The output should show a saved entry. Reboot, then confirm the result:

uname -r

For a one-time test, use grub-reboot instead:

sudo grub-reboot 'Advanced options for Ubuntu>Ubuntu, with Linux <good-kernel>'
sudo reboot

That changes the next boot without permanently changing the default. It is useful on a remote server where you want one controlled test before committing to the older kernel.

Never edit /boot/grub/grub.cfg directly. update-grub will overwrite it later, and your change will disappear when you need it most.

What changes for Debian, Arch, Manjaro, and Fedora?

The diagnosis is the same across distributions. The package commands are not.

Arch Linux

Arch is a rolling distribution, so forcing a package downgrade is more fragile than using an alternate kernel. Install and boot linux-lts when you need a stable escape hatch:

sudo pacman -S linux-lts linux-lts-headers

Then reboot and select the long-term-support kernel from GRUB. This gives you a different kernel line without trying to reconstruct an old package transaction from memory.

If you must downgrade the regular kernel, use a matching package from the local package cache or an appropriate Arch archive. Confirm that the kernel, headers, and external modules match. A partial downgrade is how a boot problem becomes a module problem.

Manjaro

For the Manjaro remove old kernels workflow, identify the running and installed kernels first:

mhwd-kernel -li

That output tells you which kernel is active and which others remain installed. Remove only an inactive kernel:

sudo mhwd-kernel -r linux<series>

Headers and extra modules may be separate packages. Remove them only if mhwd-kernel -li or pacman -Q shows they exist:

pacman -Q | grep -E 'linux<series>'
sudo pacman -R linux<series>-headers
sudo pacman -R linux<series>-extramodules

Manjaro warns against removing the kernel currently in use. Its kernel management guide also documents the mhwd-kernel workflow and the extra packages that may accompany a kernel. (wiki.manjaro.org)

Fedora and RHEL

Fedora normally keeps install-only kernels so you can select an older entry while troubleshooting. List the installed kernel packages:

rpm -q kernel-core

After booting the known-good kernel, remove the exact faulty release and any matching module packages shown by the package query:

sudo dnf remove kernel-core-<bad-release> \
 kernel-modules-<bad-release> \
 kernel-modules-extra-<bad-release>

Review the transaction before accepting it. Do not remove every package matching kernel*. The point is to remove one bad release while keeping a working fallback and the package path for future updates.

For a full Fedora package transaction, dnf history and dnf history undo may help. They are not a substitute for a kernel rollback. A transaction can include packages whose newer versions are now required by other software.

Is a Linux kernel rollback the same as a full update rollback?

No. A kernel rollback changes one boot component. A full Linux update rollback may involve libraries, services, drivers, configuration files, and package dependencies.

Use the method that matches the failure:

• Kernel regression: Boot an older kernel from GRUB.
• One broken package: Reinstall or downgrade that package.
• A failed package transaction: Repair dpkg or inspect the DNF transaction history.
• A Snap update problem: Use snap revert <snap-name>.
• A release upgrade problem: Restore a filesystem, virtual machine, or cloud snapshot.
• A damaged boot partition: Use live media or a provider rescue environment.

On Ubuntu, inspect available package versions before attempting a downgrade:

apt-cache policy <package-name>

If the required version is still available, install it explicitly:

sudo apt install <package-name>=<known-good-version>

This works only when the repository or package cache still contains that version. It also handles dependencies poorly if you downgrade a large group without a plan.

Snapshots are the stronger Linux rollback method for system-wide changes. A Btrfs, ZFS, LVM, virtual machine, or cloud snapshot can restore the filesystem state before the update. The trade-off is blunt: changes made after the snapshot may disappear, including data you forgot to copy elsewhere.

Do not call a release upgrade reversible because the package manager has an undo command. A transaction history can restore package versions, but it cannot recreate every configuration decision or fix a bootloader that was already damaged.

What should you do if Ubuntu has no older kernel?

If GRUB shows only one kernel, there is no local previous kernel to select. You need to install another supported kernel or recover the system from outside the installed boot.

Start from Ubuntu live media or your provider's rescue environment. Mount the root filesystem, mount a separate /boot or EFI partition if the machine uses one, bind /dev, /proc, and /sys, then enter a chroot. From there, inspect the installed packages and reinstall the supported kernel metapackage.

The exact mount commands depend on the disk layout. Check lsblk -f before mounting anything. If the machine uses encryption, LVM, RAID, or a separate EFI system partition, guessing at device names is how you overwrite the wrong filesystem.

On a cloud server, use the provider's serial console if available. If the console cannot reach the bootloader, attach the root volume to a rescue instance and repair it there. The principle is the same: mount the real root filesystem, preserve its /boot layout, repair packages, rebuild initramfs if needed, and regenerate GRUB.

For boot failures caused by kernel modules or an incomplete initramfs, the guide on fixing failed kernel module load jobs covers the next diagnostic layer.

What are the trade-offs of keeping an old kernel?

Keeping an older kernel is usually the right short-term choice after a regression. It gives you a known-good boot path while you wait for a fix or identify the real failure.

The costs are real:

• The older kernel may lack later security fixes.
• New hardware may work only with the newer kernel.
• DKMS modules may be built for one version but not the other.
• Future updates may change the default entry again.
• A full /boot partition can block later kernel installation.

Keep the faulty kernel installed while you collect logs unless it prevents booting or fills /boot. Once the next kernel arrives, test it deliberately:

uname -r
journalctl -b -k -p err

If the new kernel works, make it the default again and remove only versions you no longer need. If the failure remains, stop calling it a kernel regression. Check the driver, firmware, initramfs, and userspace logs instead.

FAQ

Can you remove a Linux update from Ubuntu?

You can remove a kernel package from Ubuntu, but there is no universal undo button for every update. Use GRUB for a kernel problem, explicit package downgrades for a single package, and a snapshot restore for a broad system change.

Should I use recovery mode to test the previous kernel?

No. Start with the normal older kernel entry. Recovery mode changes the environment by limiting services and tools, so it is useful for repair but poor for testing ordinary desktop or server behavior.

How do I stop Ubuntu from booting the faulty kernel again?

Set GRUB_DEFAULT=saved, run update-grub, and save the known-good menu entry with grub-set-default. Then verify the saved entry with grub-editenv list. If the package remains installed, GRUB can still boot it manually for later testing.

Is xxxfcxx a Linux rollback command?

No. xxxfcxx is not a standard Ubuntu, Linux, GRUB, APT, or kernel-management command. Treat it as a typo or an unrelated search fragment unless it came from a specific error message.

How do I know the rollback worked after rebooting?

Run uname -r and compare it with the kernel entry you selected. Then read journalctl -b -k for kernel errors from the current boot. If the machine works but the same error appears in the journal, the rollback changed the symptom without fixing the cause.

Related on this blog

• How to Update Linux Kernel Safely by Distro