Tutorial

Recovering from a Pop!_OS Kernel Panic on System76

Step-by-step recovery for a Pop!_OS kernel panic after an interrupted update.

3 min read intermediate
Linux

Prerequisites

  • Basic Linux command line familiarity
  • Physical access to the machine
Table of Contents

If your Pop!_OS system drops into a kernel panic after an interrupted update, you can recover the system safely using the steps below.

For background on why this happens and the engineering mindset behind Linux recovery, see the companion blog post.

Note

These instructions assume:

  • LUKS-encrypted root partition
  • EFI boot partition
  • Pop!_OS recovery mode is available

1. Boot into Recovery

Tip

To access the boot menu: press Spacebar during startup for systemd-boot, or hold Shift (BIOS) / press Esc or F2 (UEFI) for GRUB.

From the boot menu, select:

Advanced Options → Recovery Mode

This lands you in a minimal rescue shell with root access.

2. Identify Your Block Devices

lsblk

You’ll see output like:

NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
nvme0n1     259:0    0 953.9G  0 disk
├─nvme0n1p1 259:1    0   512M  0 part            # EFI
├─nvme0n1p2 259:2    0     4G  0 part            # recovery
└─nvme0n1p3 259:3    0 949.4G  0 part            # encrypted root

Identify:

  • nvme0n1p1 → EFI partition (usually 512MB, FAT32)
  • nvme0n1p3 (or similar) → encrypted root filesystem

Tip

Your device names may differ. Use lsblk -f to see filesystem types and labels.

3. Check Your crypttab Entry

Warning

Check /etc/crypttab after entering the chroot, not before: the file is on the installed system’s filesystem.

cat /etc/crypttab

Confirm the expected LUKS mapping name. Pop!_OS typically uses cryptdata.

4. Unlock the Encrypted Volume

cryptsetup luksOpen /dev/nvme0n1p3 cryptdata

Enter your LUKS passphrase when prompted. Replace nvme0n1p3 with your actual encrypted partition.

Note

If your system uses LVM on LUKS, you need to activate the volume group after opening the LUKS container: cryptsetup luksOpen /dev/sdXn crypt_root followed by vgchange -ay to activate all logical volumes. Then mount the logical volume (e.g., mount /dev/mapper/vgname-root /mnt/root).

5. Mount the Root Filesystem

mkdir -p /mnt/root
mount /dev/mapper/cryptdata /mnt/root

Then mount the EFI partition:

mount /dev/nvme0n1p1 /mnt/root/boot/efi

6. Bind Necessary System Directories

These bind mounts give the chroot environment access to essential kernel interfaces:

mount --bind /dev  /mnt/root/dev
mount --bind /proc /mnt/root/proc
mount --bind /sys  /mnt/root/sys
mount --bind /run  /mnt/root/run

7. Enter the Chroot Environment

chroot /mnt/root

You’re now operating inside your actual system, not the recovery environment.

8. Update and Repair the System

Update package lists and complete any interrupted upgrades:

apt update
apt full-upgrade

Rebuild the initramfs for all installed kernels:

update-initramfs -c -k all

Update the bootloader configuration:

Note

Pop!_OS uses systemd-boot by default instead of GRUB. For Pop!_OS, use kernelstub -v to view the current boot configuration and sudo kernelstub -k /boot/vmlinuz-$(uname -r) -i /boot/initrd.img-$(uname -r) to update it. For GRUB-based systems, use update-grub or grub-mkconfig -o /boot/grub/grub.cfg.

# Pop!_OS (systemd-boot)
kernelstub -v
sudo kernelstub -k /boot/vmlinuz-$(uname -r) -i /boot/initrd.img-$(uname -r)

# GRUB-based systems
update-grub

9. Exit and Reboot

exit
umount -R /mnt/root
reboot

Your system should now boot normally.

Troubleshooting

”Cannot open root device” after reboot

The crypttab or GRUB configuration may reference the wrong UUID. Inside the chroot:

blkid /dev/nvme0n1p3
cat /etc/crypttab

Ensure the UUIDs match. If not, update /etc/crypttab and run update-initramfs -c -k all again.

”No such file or directory” when mounting

Double-check your partition names with lsblk. NVMe drives use nvme0n1pX naming; SATA drives use sdaX.

GRUB menu doesn’t appear

Hold Shift during boot (BIOS) or press Esc repeatedly (UEFI) to force the GRUB menu to appear.

Further Reading