How To Install the Latest Kernel on Linux Mint

Linux Mint gives you two sane ways to run a newer kernel, and they solve different problems. The Update Manager ships Ubuntu’s supported kernel series, tested against Mint and patched for years, which is what you want when new hardware needs a fresher driver. The Mainline tool installs upstream kernel.org builds the day they appear, which is what you want for testing a scheduler change, confirming a bug fix, or chasing a driver that has not been backported yet.

Original content from computingforgeeks.com - post 9303

This guide covers both: the built-in kernel manager in Update Manager, and installing the latest kernel on Linux Mint with the Mainline tool, including the two separate failures that break kernel 7.x installs on Mint 22 today, run-parts in the hook scripts and a missing gcc-15 in the DKMS rebuild, with a tested fix for each. Everything below was run on Linux Mint 22.3 Cinnamon in August 2026, ending with mainline kernel 7.2 booted and a DKMS module rebuilt against it; the run-parts failure and the rollback were also reproduced on Ubuntu 24.04, and the tool itself verified on Ubuntu 26.04.

Check the Kernel You Are Running

Before touching anything, note your starting point:

uname -r

A fully updated Mint 22.3 reports the Ubuntu HWE kernel it inherited from the noble base:

6.14.0-37-generic

Keep that version written down. If a new kernel misbehaves, this is the one you boot back into. On a desktop you care about, take a Timeshift snapshot first; kernel experiments are exactly what it exists for.

Update the Kernel with Mint’s Update Manager

The supported path lives in Update Manager under View > Linux Kernels. Mint shows a warning about proprietary drivers first, along with rollback instructions (hold Shift at boot, pick the old kernel under Advanced options). Click Continue and you get the kernel series picker:

Two things in this window catch people out. First, the banner is blunt about support status: our fully patched 6.14 HWE kernel is already flagged End of Life, because Ubuntu rolls the hardware-enablement series forward and retires the old one. Second, the left column lists kernel series (7.1, 7.0, 6.17, 6.14, 6.11, 6.8 at the time of testing), but only some entries inside them are supported. Select the newest series and look at the right column:

The 7.0 series carries the support contract: kernel 7.0.0-29 is marked Supported until May 2029. That is the one to install from this window. Select it, queue the action, and reboot. The 7.1 entry you can see in the first screenshot only appears because we installed it with the Mainline tool below; Mint labels it Unsupported, which is accurate, since upstream point releases get no Ubuntu security backports.

The same supported kernel exists as a plain apt package. On Mint 22 and Ubuntu 24.04 it hangs off the HWE meta package:

apt-cache policy linux-generic-hwe-24.04

The candidate line shows the rollover to the new major series:

linux-generic-hwe-24.04:
  Installed: 6.14.0-37.37~24.04.1
  Candidate: 7.0.0-29.29~24.04.2

So sudo apt install linux-generic-hwe-24.04 followed by a reboot lands you on the supported 7.0 kernel with zero third-party tooling. We verified this on Ubuntu 24.04 as well, where the same command pulled in vmlinuz-7.0.0-29-generic. If that kernel is new enough for your hardware, stop here. It usually is.

Install the Mainline Tool

For anything newer than the HWE series, use Mainline, a maintained fork of the old ukuu that installs the official Ubuntu mainline builds from kernel.ubuntu.com. It comes from a PPA (the add-apt-repository command ships with Mint by default):

sudo add-apt-repository -y ppa:cappelikan/ppa
sudo apt update
sudo apt install mainline

Mint reports its own codename to some tools, which breaks PPAs that key on it. Not this one. The repository file lands correctly mapped to the Ubuntu base:

ls /etc/apt/sources.list.d/ | grep cappelikan

On Mint 22.3 the file is tied to noble, the Ubuntu 24.04 base:

cappelikan-ppa-noble.list

The PPA also publishes builds for Ubuntu 26.04 (resolute), so the tool works unchanged there. You get both a CLI (mainline) and a GTK app (mainline-gtk) from the single package.

Install the Latest Mainline Kernel

Ask the tool what the newest installable build is:

mainline check

It reports the latest mainline release with a completed build, plus the newest point update for the series you are running:

Latest update: 7.2
Latest point update: 6.14.11

One detail worth trusting here: kernel.org already listed a newer 7.1 point release when we tested, but the Ubuntu mainline build farm had no amd64 packages for it yet, and the most recent builds sometimes fail outright. Mainline hides versions without a usable build instead of letting you wget your way into a half-broken install. The GTK app shows the same list with install status:

Install the newest build (swap in whatever version mainline check reported for you):

sudo mainline install-latest

On Linux Mint 22 and Ubuntu 24.04, installing any kernel 7.x build fails today, through no fault of the tool. Ubuntu 26.04 does not hit this.

Error: “run-parts: missing operand” installing kernel 7.x

The install dies in the package maintainer scripts:

run-parts: missing operand
Try `run-parts --help' for more information.
dpkg: error processing archive /root/.cache/mainline/7.1.5/linux-image-unsigned-7.1.5-070105-generic_7.1.5-070105.202607241434_amd64.deb (--install):
 new linux-image-unsigned-7.1.5-070105-generic package pre-installation script subprocess returned error exit status 1

The cause sits in the kernel packaging, not in Mint. Kernel 7.x maintainer scripts call run-parts with two hook directories at once (/etc/kernel/postinst.d and /usr/share/kernel/postinst.d). The run-parts shipped on the noble base that Mint 22 and Ubuntu 24.04 share accepts exactly one directory and bails out. Ubuntu 26.04 carries a newer debianutils that takes multiple directories without complaint, so the same scripts pass there. We confirmed both sides on live systems:

run-parts --version

Mint 22.3 and Ubuntu 24.04 print the release that cannot take two directories, Ubuntu 26.04 the one that can:

Debian run-parts program, version 5.17     (Mint 22.3 / Ubuntu 24.04)
Debian run-parts program, version 5.23.1   (Ubuntu 26.04)

This is tracked upstream as Launchpad bug #2148348 and was still unresolved when we published. Until the packaging is fixed, a small shim un-breaks it: root’s default PATH puts /usr/local/bin ahead of /usr/bin, so a wrapper there can split the directories and hand them to the real run-parts one at a time. Create it:

sudo vim /usr/local/bin/run-parts

Add the following script:

#!/bin/sh
# noble's run-parts 5.17 accepts one directory; kernel 7.x scripts pass two.
opts=""; dirs=""
for a in "$@"; do
  case "$a" in
    -*) opts="$opts $a" ;;
    *) dirs="$dirs $a" ;;
  esac
done
st=0
for d in $dirs; do
  [ -d "$d" ] || continue
  /usr/bin/run-parts $opts "$d" || st=$?
done
exit $st

Make it executable:

sudo chmod +x /usr/local/bin/run-parts

If you hit the error before adding the shim, clear the half-installed packages, then run the install again:

sudo dpkg --configure -a
sudo mainline uninstall 7.1.5
sudo mainline install 7.1.5

With the shim in place the hook scripts run and GRUB picks up the new entry. On a machine with no DKMS modules registered, that is the whole story:

 * dkms: running auto installation service for kernel 7.1.5-070105-generic
   ...done.
Setting up linux-image-unsigned-7.1.5-070105-generic (7.1.5-070105.202607241434) ...
Setting up linux-headers-7.1.5-070105-generic (7.1.5-070105.202607241434) ...
mainline: done

Delete the shim once Ubuntu fixes the packaging: sudo rm /usr/local/bin/run-parts. While it exists it also fronts cron’s run-parts calls (cron.daily and friends); those pass a single directory, which the shim forwards unchanged, but there is no reason to keep it around longer than needed.

Error: “gcc-15: not found” when DKMS modules rebuild

The shim clears run-parts, but on any machine that already has a DKMS module registered (NVIDIA drivers, VirtualBox, broadcom-sta, v4l2loopback and the rest) the install still ends in a dpkg error. The kernel packages themselves are fine. The module rebuild is what dies:

/bin/sh: 1: gcc-15: not found
make[4]: *** [/usr/src/linux-headers-7.2.0-070200-generic/scripts/Makefile.build:289: cfghello.o] Error 127
dkms autoinstall on 7.2.0-070200-generic/x86_64 failed for cfghello(10)
run-parts: /etc/kernel/postinst.d/dkms exited with return code 11
dpkg: error processing package linux-image-unsigned-7.2.0-070200-generic (--install):
 installed linux-image-unsigned-7.2.0-070200-generic package post-installation script subprocess returned error exit status 11

The headers package names the compiler that built the kernel, literally, in its top-level Makefile:

grep -nE '^(CC|HOSTCC)[[:space:]]' /usr/src/linux-headers-7.2.0-070200-generic/Makefile

Both lines point at a binary that does not exist on a noble base:

460:HOSTCC	= gcc-15
540:CC		= $(CROSS_COMPILE)gcc-15

Ubuntu builds these kernels on the current development release, which has already moved to GCC 15, and the compiler name travels with the headers. Mint 22 and Ubuntu 24.04 stop at gcc-14 and ship no gcc-15 in any pocket, so every out-of-tree module build against 7.x headers dies at Error 127. Ubuntu 26.04 has gcc-15 by default and never hits it. Kernel 7.1 and 7.2 builds are both affected, and the reason a fresh test machine looks like it passed is that it has no DKMS modules to rebuild in the first place.

The matching compiler is packaged for noble in the Ubuntu toolchain PPA:

sudo add-apt-repository -y ppa:ubuntu-toolchain-r/test
sudo apt install -y gcc-15

Then finish the install dpkg left half configured:

sudo dpkg --configure -a

The rebuild compiles, signs and installs, and the kernel packages configure cleanly. We registered a throwaway one-file DKMS module for this test on purpose, because a box with nothing to rebuild reports success either way:

make -j4 KERNELRELEASE=7.2.0-070200-generic KVER=7.2.0-070200-generic...
Signing module /var/lib/dkms/cfghello/1.0/build/cfghello.ko
Running module version sanity check.
 - Installation
   - Installing to /lib/modules/7.2.0-070200-generic/updates/dkms/
depmod...
dkms autoinstall on 7.2.0-070200-generic/x86_64 succeeded for cfghello

One thing the compiler fix will not buy you: a module whose source predates the kernel API it is being built against. On the same machine v4l2loopback 0.12.7 compiled far enough to fail on its own code, too few arguments to function 'v4l2_fh_add', because 7.2 changed that signature. Read the error before reaching for the toolchain. Error 127 on a missing binary is the compiler. A C error with a file and line number is the module, and the fix there is a newer module release or a kernel it still supports.

Error: “linux-modules depends on wireless-regdb” on minimal installs

On a Mint desktop this never fires, but on a minimal Ubuntu server image the 7.x modules package refuses to configure because wireless-regdb is missing. One package fixes it:

sudo apt install wireless-regdb
sudo dpkg --configure -a

Boot the New Kernel and Verify

Reboot. With the stock GRUB_DEFAULT=0, GRUB boots the highest version installed, so no menu digging is needed:

sudo reboot

Back at the desktop, confirm the running kernel:

uname -r

Our Mint 22.3 test machine came up on the mainline build:

7.1.5-070105-generic

You can also list every kernel the tool knows about on the system:

mainline list-installed

Both the distro kernel and the mainline one stay side by side, which is precisely what makes rolling back painless:

Installed Kernels:
linux-image-6.14.0-37-generic
linux-image-generic-hwe-24.04
linux-image-unsigned-7.1.5-070105-generic

Two caveats before you settle in. Mainline images are unsigned, so a machine with Secure Boot enabled will refuse to boot them until you disable Secure Boot or sign the kernel with your own MOK key; the manual mainline install guide for Ubuntu walks through that in detail. And mainline kernels receive no Ubuntu security patching, so treat them as test rides, not daily drivers on exposed systems. If you are curious what the new series actually changes, see what shipped in the kernel 7.1 line, and if you need a config Ubuntu does not build at all, compiling the kernel from source is the remaining option.

Roll Back or Remove a Kernel

If the new kernel misbehaves, boot the old one first. Hold Shift (BIOS) or press Esc (UEFI) during boot to reach GRUB, then pick the previous kernel under Advanced options. The entries on our test system:

Linux Mint 22.3 Cinnamon, with Linux 7.1.5-070105-generic
Linux Mint 22.3 Cinnamon, with Linux 7.1.5-070105-generic (recovery mode)
Linux Mint 22.3 Cinnamon, with Linux 6.14.0-37-generic
Linux Mint 22.3 Cinnamon, with Linux 6.14.0-37-generic (recovery mode)

Once you are back on the distro kernel, remove the mainline one:

sudo mainline uninstall 7.1.5

The tool removes the image, modules and headers in one pass and regenerates the GRUB menu. It refuses to touch the kernel you are currently running, so you cannot saw off the branch you are sitting on. Kernels installed through Update Manager are removed from the same Linux Kernels window instead (the Remove Kernels button), and sudo mainline uninstall-old clears out old mainline builds in bulk once you have accumulated a few. Whichever lane you picked, keep at least one known-good kernel installed next to the one you are testing. Debian users have a close equivalent of the whole workflow in the newer kernel install guide for Debian.