VPS Won't Boot After a Kernel Update? How to Recover It

You rebooted the VPS after a routine kernel update and it never came back. SSH times out, ping gets nothing, and your monitoring is screaming. Before you panic and open a support ticket, there's a good chance you can fix this yourself in ten minutes using your provider's web console - no SSH required, since SSH is exactly what's not working right now.

Symptom: What "Won't Boot" Actually Looks Like

"Won't boot" covers a few different failure modes, and which one you're looking at tells you where to start:

• SSH connection refused or times out, but the provider dashboard still shows the VPS as "running" - the OS is stuck somewhere before the network stack comes up.
• Dropped into a grub rescue> prompt when you open the web console - GRUB can't find a valid kernel or filesystem to boot.
• Kernel panic text scrolling and the boot loops or halts - the new kernel loaded but can't mount the root filesystem or is missing a driver it needs.
• Stuck at an (initramfs) prompt asking you to fix things manually - usually an fsck failure or a filesystem it can't find.
• Long pause then a login prompt that never accepts input - sometimes it did boot, just slower than usual, and the real problem is somewhere else (check this first, it's the easy case).

Open your provider's web console before doing anything else - DigitalOcean calls it Droplet Console, Vultr calls it View Console, Linode has Lish, AWS EC2 has Serial Console/EC2 Instance Connect. Whatever it's called, that's the only way to see what's actually happening when SSH itself is the thing that's down.

Cause: Why a Kernel Update Takes Down the Boot

None of this is random - it's almost always one of five things:

1. /boot filled up mid-update

Every kernel install drops a new vmlinuz, initrd.img, and System.map into /boot, which is usually a small, separate partition. If old kernels were never cleaned up, the partition runs out of space partway through installing the new one - the initramfs gets written incomplete or truncated, and GRUB has no idea.

2. GRUB config never got updated

The kernel package installs fine, but the post-install hook that runs update-grub fails silently (often because of the /boot issue above), so GRUB's menu still points at file names that no longer match what's actually in /boot.

3. fstab UUID mismatch after the update

Rare, but it happens after a disk resize or when a rescue tool reformats a volume: the UUID in /etc/fstab no longer matches the partition, so mounting root or a data volume hangs the boot with no nofail option to fall back on.

4. Missing driver in the new kernel

Cheaper or older VPS templates sometimes need a specific virtio or paravirt driver compiled in. A generic kernel update can occasionally ship a build missing that module, and the new kernel panics trying to find its own root disk.

5. Automatic reboot after unattended-upgrades

If unattended-upgrades is set to auto-reboot, the failing kernel gets installed and the box restarts into it at 3 a.m. with nobody watching the console to catch the problem the second it happens.

Fix: Recovering the VPS Step by Step

Do this from the web console, not SSH - SSH won't come up until the box actually boots.

1. Open the console and read the last screen of output. A grub rescue> prompt, a kernel panic trace, or an (initramfs) shell all point you to a different fix below, so don't skip this.
2. If you're at grub rescue>, find your boot partition and set it manually:

   ls
   set root=(hd0,gpt1)
   linux /boot/vmlinuz-OLDVERSION root=/dev/vda1
   initrd /boot/initrd.img-OLDVERSION
   boot

   Use ls (hd0,gpt1)/boot/ to see what kernel files actually exist before you guess the version number.
3. If GRUB loads but you see a menu, press a key to stop the auto-boot countdown, choose Advanced options, and pick the previous, previously-working kernel entry instead of the newest one. This gets you back in without fixing anything yet - that's fine, do the fix once you're logged in.
4. Once you're in (on the old kernel), check /boot space first:

   df -h /boot
   ls -lh /boot

   If it's at or near 100%, that's very likely your root cause.
5. Remove old kernels to free space, then finish the interrupted install:

   # Debian/Ubuntu
   sudo apt --fix-broken install
   sudo apt autoremove --purge
   sudo dpkg --configure -a
   
   # RHEL/AlmaLinux/CentOS
   sudo dnf remove $(dnf repoquery --installonly --latest-limit=-2 -q)
   sudo dnf update

6. Rebuild the GRUB config so it actually matches what's in /boot now:

   # Debian/Ubuntu
   sudo update-grub
   
   # RHEL/AlmaLinux/CentOS
   sudo grub2-mkconfig -o /boot/grub2/grub.cfg

7. Check fstab if the failure looked like a hung mount rather than a missing kernel file. Add nofail to any non-root entry so a bad or stale UUID degrades gracefully instead of blocking the whole boot:

   UUID=xxxxxxxx  /data  ext4  defaults,nofail  0  2

8. Reboot from the console and watch it happen live this time, rather than closing the tab and hoping. If it comes up clean, only then reconnect over SSH and confirm services are actually running, not just that the login prompt appeared.

Prevention: Stop the Next Update From Doing This

• Clean up old kernels on a schedule instead of letting them pile up in /boot. On Ubuntu/Debian, sudo apt autoremove --purge after updates keeps this in check; most distros default to keeping 2-3 old kernels, which is usually safe if /boot has reasonable headroom.
• Turn off automatic reboots in unattended-upgrades and reboot manually during a window when you're watching the console:

  echo 'Unattended-Upgrade::Automatic-Reboot "false";' | sudo tee /etc/apt/apt.conf.d/52unattended-upgrades-manual-reboot

  We covered the full unattended-upgrades setup in an earlier automatic security updates guide if you haven't configured it yet.
• Take a snapshot before a major kernel or distro version jump. Most providers let you restore a snapshot in a couple of minutes - far faster than debugging a broken boot from scratch.
• Add nofail to non-root fstab entries up front, so a future disk resize or volume detach degrades gracefully instead of hanging the whole server.
• Confirm you can actually reach your provider's console before you need it. Log in and open it once, today, so you're not fumbling through account recovery at 3 a.m. during an actual outage.

Quick Reference: Symptom to Fix

Most of these incidents trace back to one thing: /boot quietly running out of space long before anyone noticed. Clear old kernels on a schedule and watch a manual reboot after any kernel update, and you'll rarely need this guide again.