A Linux machine that drops into initramfs or emergency mode has reached a useful diagnostic point. The error may concern a missing root device, an incorrect UUID, a filesystem check, or failing storage. These symptoms share a boot failure, but they require different repairs. Reinstalling GRUB or forcing a writable mount before identifying the cause can obscure the evidence.
Read the error and map the storage
Photograph or save the exact message before rebooting. Use a compatible live environment when the installed system cannot provide the tools below. Map partitions, filesystem types, UUIDs, and mounted devices before choosing a repair target.
lsblk -o NAME,SIZE,FSTYPE,UUID,MOUNTPOINTS
sudo blkid
findmnt
sudo dmesg --level=err,warnAn encrypted partition must be unlocked before its inner filesystem is visible. LVM volumes may also require activation. The outer LUKS container or LVM physical volume is not the filesystem to pass to e2fsck. Confirm each layer and record the actual root device.
Put storage failure ahead of filesystem repair
Repeated I/O errors, resets, or a disappearing drive change the priority. Preserve important data or make an image to healthy storage before attempting repairs. A filesystem tool can modify metadata; it cannot fix an unreliable disk or controller. Avoid repeated full checks on a device that is visibly deteriorating.
For a running system, compare disk-space and inode exhaustion with filesystem errors. If logs survive, inspect the prior boot with journalctl -b -1. A read-only root filesystem may be a deliberate response to corruption, rather than an ordinary permissions problem.
findmnt -no SOURCE,FSTYPE,OPTIONS /
df -h
df -i
journalctl -b -1 -p warningCheck ext4 only while it is unmounted
The following example is for ext2/ext3/ext4 only. Replace the placeholder with the verified filesystem device. Do not run it on a mounted root filesystem, an entire partitioned disk, or an encrypted container.
ROOT_FS=/dev/mapper/REPLACE_WITH_VERIFIED_ROOT_VOLUME
findmnt --source "$ROOT_FS"
sudo e2fsck -n "$ROOT_FS"Run the check only after confirming that findmnt shows no mount for that device. The -n pass refuses repairs and helps assess damage; inspect its output and exit status. Once data is protected and the device is healthy, an interactive repair lets you review proposed changes:
sudo e2fsck -f "$ROOT_FS"Exit status 0 means no errors, 1 means corrected errors, and 2 means corrections requiring a reboot; 4 includes errors left uncorrected. Exit codes can be combined. Do not assume a completed command means the filesystem is ready. XFS, Btrfs, and ZFS require their own recovery procedures.
Even mounting ext4 read-only can replay its journal. If preserving an original for forensic or damaged-media recovery matters, work from an image and use the appropriate no-recovery mounting procedure.
Repair boot configuration only when the evidence points there
Compare the root UUID in the boot command line and installed /etc/fstab with blkid. If an older installed kernel boots correctly, use it to inspect the failed update. On Ubuntu or Debian, rebuilding the initramfs can address missing early-boot components once the installed root, separate /boot, and any required EFI partition are mounted correctly.
sudo update-initramfs -u -k all
sudo update-grubThese commands are for the installed Ubuntu/Debian environment, including a correctly prepared chroot when needed. Running them against the live USB’s own filesystem updates the wrong installation. A GRUB installation command also depends on UEFI versus BIOS and the target disk; do not guess those values.
Verify after the first successful boot
Check mounts, kernel logs, disk health, space, and the applications that write important data. Confirm that recovery persists through another controlled reboot. Save the root-device mapping and the failure cause with the recovery notes. A successful boot is valuable, but recurring I/O or filesystem errors mean the underlying problem remains.