Fixing a Kernel Panic on Boot After a Bad Driver or Module Update

A system that boots fine, then panics or hangs immediately after a kernel update or a driver package update, is one of the most recoverable failure categories in Linux — precisely because modern distributions keep the previous, working kernel installed alongside the new one specifically for this situation, and GRUB’s boot menu is the tool that gets you back to it without needing rescue media at all.

First: boot the previous kernel, don’t troubleshoot the broken one yet

Before diagnosing anything, get the system back to a bootable state. At the GRUB menu (hold Shift during boot on BIOS systems, or Esc/hold a key on some UEFI setups, depending on distribution defaults), select “Advanced options” and choose the previous kernel version explicitly rather than the newest default entry:

Advanced options for Ubuntu
  Ubuntu, with Linux 6.8.0-31-generic
  Ubuntu, with Linux 6.8.0-29-generic   <- the one that worked before

If this boots successfully, that confirms definitively that the problem is specific to the new kernel or a driver/module tied to it, not a broader hardware or filesystem issue — which immediately narrows the entire investigation.

Reading the actual panic message

Once back in a working boot, the panic message from the failed boot attempt is usually still available via the kernel ring buffer from the previous boot attempt, or, more reliably, by re-triggering the panic while capturing console output. If the system supports it, booting the broken kernel with nomodeset and without quiet splash (removing those from the kernel command line via GRUB’s edit mode, pressing e at the menu) forces verbose text output during boot rather than a graphical splash screen hiding the actual messages:

linux /boot/vmlinuz-6.8.0-31-generic root=UUID=... ro nomodeset

This single change — dropping the splash screen and forcing verbose output — is frequently the difference between “the system just hangs with no information” and “the exact panic message and the module/driver name responsible are right there on screen.”

Common culprit: a proprietary or third-party kernel module

The single most frequent cause of this exact symptom — boots fine, then panics right after a kernel update — is a third-party kernel module (proprietary GPU drivers being the classic example, but any DKMS-built module is a candidate) that hasn’t been rebuilt against the new kernel’s headers, or that has a genuine incompatibility with a kernel ABI change in the new version.

Checking whether DKMS modules actually built successfully against the new kernel is the direct diagnostic:

dkms status

A module showing as failed to build (rather than installed) for the new kernel version is a strong, direct signal — that module likely isn’t loaded correctly (or isn’t loaded at all, silently, if the distribution’s boot process tolerates a missing module) and may be the panic’s actual cause if the panic message references it, or if the system otherwise depends on that module loading successfully at boot (a display driver being essential for the boot process to complete on some configurations, for instance).

Rebuilding a failed DKMS module

If a specific module failed to build against the new kernel headers, the fix is usually reinstalling the correct headers package for the new kernel version and re-triggering the DKMS build explicitly:

apt install linux-headers-$(uname -r)
dkms autoinstall

(substitute the equivalent package-manager commands for non-Debian-derived distributions — dnf/yum with kernel-devel on Fedora/RHEL-family systems). If the build still fails, the DKMS build log (/var/lib/dkms/<module>/<version>/build/make.log) contains the actual compiler error, which is necessary for determining whether this is a genuinely incompatible module (needing an upstream update from the vendor) or a locally fixable build environment issue.

When it’s not a third-party module: kernel command-line and hardware-specific issues

If no DKMS module is implicated, the panic message itself — captured via the verbose-boot approach above — usually names a specific kernel subsystem or driver. A panic referencing storage controller drivers, ACPI, or specific hardware initialization is more likely a genuine kernel regression affecting a specific hardware configuration than a locally-fixable module problem, and the practical path forward is: continue running the previous, working kernel (which distributions keep available specifically for this reason) while checking the distribution’s kernel bug tracker for the specific kernel version and hardware combination, rather than attempting a workaround blind.

Pinning the working kernel while investigating

For a production or otherwise important system, explicitly pinning the last-known-good kernel as the default GRUB boot entry (rather than relying on remembering to manually select it every boot) prevents an unattended reboot from landing back on the broken kernel:

grub-reboot "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-29-generic"
grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-29-generic"

grub-set-default changes the persistent default for all future boots; grub-reboot changes only the next boot without altering the persistent default, which is useful when you want to test the new kernel again once (after a fix attempt) without committing to it as the ongoing default if that test also fails.

Preventing a repeat: holding kernel updates until verified

For systems where an unverified kernel update causing a boot failure is a genuinely costly outage, holding automatic kernel updates and instead testing new kernels deliberately (in a staging environment, or manually on the production system during a maintenance window with console access readily available) is the practical mitigation — the previous-kernel-boots-fine safety net that GRUB provides is a real recovery mechanism, but relying on it as the only line of defense against kernel update regressions is a choice worth making deliberately rather than by default, especially for systems where console/rescue access during an actual boot failure isn’t trivially available.