Fixing a Failed /boot Mount in Emergency Mode on Ubuntu 24.04 LTS After a Kernel Update

Why a kernel update can drop you into emergency mode because /boot won’t mount

A fresh kernel can change the initramfs or the boot‑loader’s config, and if the loader can’t find the /boot partition the system drops into that classic emergency shell:

Emergency shell (root=rw) – press Ctrl‑D to continue

Below is a no‑fluff, hands‑on walk‑through that keeps the commands you need, the trade‑offs, and a few security reminders.


1. Inspect the emergency environment

First, make sure the culprit is really the /boot mount. In the emergency shell run:

# What caused the system to go into emergency mode?
journalctl -xb | grep -iE 'boot|mount|fstab'

# Show the current fstab
cat /etc/fstab

You’ll usually see something like:

Failed to mount /boot: No such file or directory

If the error says “permission denied” or something else, the root cause is different, but the rest of this guide still applies.


2. Verify the block device that should contain /boot

Run blkid and lsblk to see all devices and their UUIDs. Compare the UUID in /etc/fstab with what the system actually has.

blkid
lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,UUID

A typical /etc/fstab entry for a separate /boot partition looks like:

UUID=1234-ABCD   /boot   ext4   defaults   0   2

If the UUID in fstab isn’t listed, the partition was renamed, moved, or deleted. If the UUID matches but the device is missing (for example, a missing NVMe drive), you can’t mount it.

Trade‑off: UUIDs survive device renames, but on a system with only a handful of partitions you could just use /dev/sda1 or /dev/nvme0n1p1. UUIDs are safer for production.


3. Fix the fstab entry

a. Correct a wrong UUID

If the UUID is stale, grab the right one and edit /etc/fstab:

nano /etc/fstab

Replace the old UUID with the new one from blkid. Save and exit.

b. Add a missing entry

If /boot is missing from fstab entirely, add it. For a standard ext4 partition:

UUID=1234-ABCD   /boot   ext4   defaults   0   2

If you’re using Btrfs or another filesystem, tweak the options accordingly.

c. Handle LVM or encrypted partitions

If /boot lives on an LVM logical volume or an encrypted container, make sure you have the matching entries in /etc/crypttab and that the logical volume is available at boot. Check with:

vgdisplay
lvdisplay

If the logical volume is gone, you’ll need to restore it from backup or rebuild the LVM metadata.


4. Re‑build the initramfs (if the kernel upgrade broke it)

Sometimes the new kernel is installed without updating the initramfs. In the emergency shell rebuild it for all kernels:

update-initramfs -u -k all

If you use a custom initramfs script, double‑check that it still references the right root and initrd paths. The initrd= line in /boot/grub/grub.cfg (or the systemd‑boot loader entry) must point to the new initrd file.


5. Test the mount manually

After you’ve fixed fstab and rebuilt the initramfs, try mounting /boot yourself:

mount /boot

If it works, unmount and reboot:

umount /boot
reboot

If it still fails, read the error. Common issues:

  • Permission denied: The partition may be read‑only or have the immutable flag set. Remove the flag:

    chattr -i /boot
    
  • Filesystem errors: Run a quick check (replace /dev/sda1 with your device):

    fsck -f /dev/sda1
    

    Caution: Don’t run fsck on a mounted partition—unmount it first.


6. Security considerations

  1. Keep /boot read‑only after boot. Mount it with ro in fstab to avoid accidental writes:

    UUID=1234-ABCD   /boot   ext4   defaults,ro   0   2
    

    When you need to update kernels, remount it temporarily:

    mount -o remount,rw /boot
    
  2. Use signed kernels. Ubuntu 24.04 ships with kernel signing by default. Verify the signature before booting:

    sudo mokutil --sb-state
    

    With Secure Boot enabled, unsigned kernels will be rejected.

  3. Restrict access to /boot. The default drwxr-xr-x is usually fine, but tighten it if you want:

    chmod 755 /boot
    

    Don’t give write permission to non‑root users.


7. Automate the check for future upgrades

Add a small script that runs at boot and logs any mount failures:

#!/usr/bin/env bash
if ! mountpoint -q /boot; then
  echo "$(date): /boot not mounted" >> /var/log/boot-check.log
fi

Save it as `/usr/local/bin/check-boot


See also