Repair Debian Installation After Power Outage

A sudden power outage can interrupt disk writes, package configuration, and bootloader updates at the worst moment. On Debian, that often shows up as emergency mode, a manual fsck prompt, GRUB rescue, kernel panic, or dpkg was interrupted—not always all at once.

This guide is a symptom-first recovery path: identify what broke, apply the matching fix, and stop when the problem looks like hardware failure (where in-place repair can make things worse). Commands follow Debian’s broken-system recovery and common Bookworm/Trixie practice on amd64.

Target environment: Debian 12 (Bookworm) and Debian 13 (Trixie); amd64.

What power loss can break (and what repair cannot promise)

Power failure damage lands at different layers. Match your symptom to the layer before you run a generic “live USB + fsck + grub-install” script—that sequence helps some cases and wastes time (or causes harm) in others.

The Debian installation manual is explicit: rescue mode is a working environment, not a guarantee every broken system can be repaired online.

Before you repair: identify the failure

Read the first error on screen or in the journal—that usually routes you faster than guessing.

From a partial boot, these commands (when available) narrow the cause:

journalctl -xb -p err
systemctl --failed
findmnt /
dmesg | tail -50

Boot Debian rescue mode or a live USB

You need an offline environment whenever root must be unmounted for fsck, or when the installed system will not boot far enough for a shell.

Option A: Debian installer rescue mode (preferred when media is handy)

1. Boot the Debian netinst or full installer ISO (same architecture as the installed system).
2. At the boot menu, choose Rescue mode (or append rescue/enable=true to the kernel command line).
3. Complete language and disk detection; select your existing root partition when prompted.
4. If the installer mounts it cleanly, you get a shell inside that filesystem. If mount fails, accept the installer shell and mount manually under /target (see below).

Rescue mode reuses installer hardware detection—it does not reinstall Debian over your disk unless you choose that later.

Option B: Debian live ISO

Use Debian live when you want a full desktop or more tools than the rescue environment provides. Boot Live, open a terminal, then mount disks manually.

Option C: Already in emergency mode on the broken system

If Debian reaches emergency mode, you may have a root shell with / mounted read-only. That is enough to inspect fstab and logs, but not the right place for a full e2fsck on /. For filesystem repair, still prefer installer rescue or live media so root is unmounted.

Mounting the installed system for chroot repairs

Replace sdXN with your root partition from lsblk and blkid:

lsblk -f
sudo blkid

Where to mount: use /mnt when booting a Debian live ISO. In installer rescue mode, if the installer drops you to its own shell without chrooting, mount under /target instead—the same bind mounts and chroot steps apply, only the path changes.

LUKS, LVM, or mdraid before mounting root

If root is not a plain partition on lsblk -f, prepare devices before mount:

LUKS — unlock using the mapper name from /etc/crypttab (often luks-<UUID>):

sudo cryptsetup luksOpen /dev/sdXN luks-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
ls /dev/mapper/

LVM — activate volume groups if lvs shows nothing:

sudo vgchange -ay
lvs
pvs

mdraid — assemble arrays if /proc/mdstat is empty:

cat /proc/mdstat
sudo mdadm --assemble --scan
# or: sudo mdadm --assemble /dev/md0 /dev/sdX1 /dev/sdY1

Then mount the real root device (/dev/mapper/..., /dev/vgname/lvname, or /dev/md0).

Typical mount and chroot (ext4 or prepared LUKS/LVM root)

ROOT=/mnt   # use ROOT=/target in installer rescue shell when needed
sudo mount /dev/sdXN "$ROOT"
# separate /boot if applicable
sudo mount /dev/sdXB "$ROOT/boot"
# UEFI: ESP must be available for grub-install
sudo mount /dev/sdXY "$ROOT/boot/efi"
sudo mount --bind /dev      "$ROOT/dev"
sudo mount --bind /dev/pts  "$ROOT/dev/pts"
sudo mount --bind /proc     "$ROOT/proc"
sudo mount --bind /sys      "$ROOT/sys"
sudo mount --bind /run      "$ROOT/run"
# DNS for apt inside chroot (copy or bind-mount)
sudo cp -L /etc/resolv.conf "$ROOT/etc/resolv.conf"
sudo chroot "$ROOT"

Inside the chroot, commands like grub-install, update-grub, dpkg, and update-initramfs affect the installed system.

After chroot repairs: unmount and reboot

When you finish commands inside the chroot, exit and unmount in this order (use /target instead of /mnt if you mounted there):

exit
sudo umount -R /mnt    # or: sudo umount -R /target

If unmount fails because a target is busy:

sudo lsof +f -- /mnt

Reboot and remove the ISO or USB from the boot order so the machine boots from the repaired disk:

sudo reboot

For systemd emergency.target vs installer rescue on Debian, see emergency and rescue targets (RHEL/CentOS examples; the same systemd concepts apply on Debian).

Scenario 1: Debian boots into emergency mode after power outage

Emergency mode means Debian could not complete the normal boot process. After a power outage, this often happens because systemd could not mount one of the filesystems listed in /etc/fstab, or because a filesystem needs repair before it can be mounted safely.

This scenario is mainly for systems that still reach a root shell with a message such as:

You are in emergency mode
Give root password for maintenance
Cannot open access to console, the root account is locked
Dependency failed for Local File Systems

If emergency mode will not give you a root shell

Emergency mode expects the root password. If you see Cannot open access to console, the root account is locked, or root has no password set, you cannot rely on this shell for repairs.

Use Debian installer rescue mode or a live ISO instead, mount the installed system, and repair from there (see Mounting the installed system). Do not try to force emergency mode when the console is inaccessible.

Diagnose mount and fstab errors

Start by checking which unit failed during boot:

systemctl --failed
systemctl status local-fs.target
journalctl -xb -p err
journalctl -xb | grep -iE 'mount|failed|dependency|uuid|fsck|filesystem'
findmnt /
findmnt -no SOURCE,OPTIONS /

If / is mounted read-only, you may see ro in the mount options.

Compare /etc/fstab with real devices:

lsblk -f
blkid
cat /etc/fstab

Match every UUID= or PARTUUID= entry in /etc/fstab with blkid. Power loss does not normally change UUIDs, but emergency mode can happen if a disk is missing, an optional data disk in fstab is unavailable, a partition has filesystem errors, fstab was edited incorrectly, or /dev/sdX names shifted instead of UUIDs.

Verify and test mounts:

findmnt --verify --verbose
systemctl list-units --type=mount --state=failed

Fix one fstab line at a time when possible. Test a single entry with mount /mountpoint before running mount -a on every filesystem.

Edit and test /etc/fstab

If you need to edit /etc/fstab from emergency mode, first remount root as writable:

mount -o remount,rw /
cp -a /etc/fstab /etc/fstab.bak.$(date +%F-%H%M%S)
nano /etc/fstab

After editing, reload systemd units and test the mounts:

systemctl daemon-reload
findmnt --verify --verbose
mount -a

If mount -a succeeds without errors, continue the boot with systemctl default or reboot.

For optional data disks only (not root), a temporary nofail entry can let Debian boot while you investigate a missing disk—for example: UUID=1111-2222 /data ext4 defaults,nofail 0 2.

If /etc/fstab looks correct but a partition still fails to mount, the filesystem may need repair. For a non-root unmounted partition you can run e2fsck -fv /dev/sdXN from the emergency shell. For root, boot rescue media and follow Scenario 2. Do not run e2fsck on a mounted read-write filesystem.

If you repaired from a live ISO using chroot, unmount and reboot when finished.

Scenario 2: Debian shows filesystem errors or asks for manual fsck

Messages such as UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY, Superblock could not be read, filesystem contains errors, or Debian dropping into emergency mode after filesystem errors usually mean one partition needs an offline filesystem check.

After a power outage, this often happens when pending writes were interrupted and the filesystem journal could not be replayed cleanly during boot.

Identify the affected filesystem

Boot Debian installer rescue mode or a Debian live ISO, then list disks and filesystems:

lsblk -f
blkid

Look for the partition that contains /, /boot, /home, /var, or the failed mount shown in emergency mode.

You can also check recent kernel messages for filesystem or disk errors:

dmesg | grep -iE 'ext4|filesystem|fsck|superblock|I/O error|buffer error'

Example output from lsblk -f may look like this:

NAME   FSTYPE FSVER LABEL UUID                                 MOUNTPOINTS
sda
├─sda1 vfat   FAT32       8A2B-91CD                            /boot/efi
├─sda2 ext4   1.0         6f6c2f7b-aaaa-bbbb-cccc-111122223333 /
└─sda3 ext4   1.0         9d2a1e33-dddd-eeee-ffff-444455556666 /home

In this example:

• /dev/sda2 is the root filesystem
• /dev/sda3 is /home
• /dev/sda1 is the EFI system partition, not an ext4 filesystem

Repair an unmounted filesystem

Before running e2fsck, confirm the target partition is not mounted (findmnt /dev/sdXN should print nothing). If it is mounted, run sudo umount /dev/sdXN first; use sudo lsof +f -- /dev/sdXN if the partition is busy.

For ext2, ext3, or ext4, start with an interactive repair:

sudo e2fsck -fv /dev/sdXN

Use sudo e2fsck -fy /dev/sdXN for automatic repair only when you have a backup or accept the risk. Avoid starting with e2fsck -y on important systems—it can move damaged files to lost+found.

After repair, confirm the filesystem is clean:

sudo e2fsck -f /dev/sdXN

A clean result usually includes /dev/sdXN: clean, files, blocks. If the same errors return immediately, suspect disk failure (When repair is not safe).

For a non-root filesystem, test mounting with sudo mount /dev/sdXN /mnt, ls /mnt, then sudo umount /mnt. For root, sudo reboot and check systemctl --failed and journalctl -xb -p err after boot.

If the filesystem is not ext4

Do not use e2fsck on every filesystem. Check the FSTYPE column from lsblk -f first.

EFI System Partition (ESP): if UEFI boot fails after power loss and /boot/efi is vfat, boot rescue media, unmount the ESP, and check it with fsck.vfat -a /dev/sdXY before repeating GRUB repair in Scenario 3.

See also repair ext4 in rescue mode for LVM, RAID, and alternate device paths.

If the superblock is damaged

If you see an error such as:

The superblock could not be read

first confirm that you selected the correct partition and filesystem type:

lsblk -f
blkid

If it is definitely an ext filesystem, list backup superblocks:

sudo mke2fs -n /dev/sdXN

The -n option prints what would be created but does not actually create a filesystem.

Then try one of the backup superblocks shown in the output:

sudo e2fsck -b <backup-superblock-number> /dev/sdXN

Example:

sudo e2fsck -b 32768 /dev/sdXN

When fsck cannot repair everything

Stop repeated repair attempts if you see signs of storage failure:

• repeated I/O error or buffer error messages in dmesg
• Error reading block during e2fsck
• bad block messages keep increasing
• SMART health reports failure
• the same filesystem errors return immediately after every repair
• the disk disappears from lsblk or firmware/BIOS

Check SMART status if smartctl is available:

sudo smartctl -a /dev/sdX

Use the disk device here, such as /dev/sda, not a partition such as /dev/sda2. On NVMe, try /dev/nvme0n1 (whole drive) or the namespace device smartctl reports—smartctl -a /dev/nvme0 works on some systems, /dev/nvme0n1 on others.

If the disk looks unhealthy, do not keep running e2fsck -y. Clone the disk if possible, copy important data first, and restore Debian from backup onto healthy storage.

Quick reference for most ext4 errors after a power outage:

lsblk -f
blkid
findmnt /dev/sdXN
sudo umount /dev/sdXN
sudo e2fsck -fv /dev/sdXN
sudo e2fsck -f /dev/sdXN
sudo reboot

If the target is the root filesystem, perform these steps from Debian installer rescue mode or a live ISO so the installed root partition is not mounted.

Scenario 3: Debian enters GRUB rescue or does not show the boot menu

If Debian drops to grub rescue>, shows no GRUB menu, or fails before the kernel starts, the firmware is still working but the bootloader stage is broken.

This can happen after a power outage during:

• kernel package installation
• GRUB package update
• update-grub
• grub-install
• writes to /boot or the EFI System Partition

The safest repair path is to boot Debian installer rescue mode or a Debian live ISO, mount the installed system, enter chroot, reinstall GRUB, and regenerate the GRUB configuration.

At the grub rescue> prompt, manual set root, linux, and initrd commands can sometimes boot once, but a rescue ISO is safer for most users. Boot Debian installer rescue mode or a live ISO and repair GRUB from the installed system using the steps below.

Identify whether the system uses BIOS or UEFI

Boot Debian installer rescue mode or a Debian live ISO, then check whether the rescue environment itself was booted in UEFI mode:

ls /sys/firmware/efi

If the directory exists, the rescue media is running in UEFI mode.

If it does not exist, the rescue media was booted in legacy BIOS mode.

Now identify your Debian partitions:

lsblk -f
blkid

Look for:

Example:

NAME        FSTYPE FSVER LABEL UUID                                 MOUNTPOINTS
sda
├─sda1      vfat   FAT32       8A2B-91CD                            /boot/efi
├─sda2      ext4   1.0         11112222-3333-4444-5555-666677778888 /
└─sda3      ext4   1.0         9999aaaa-bbbb-cccc-dddd-eeeeffff0000 /home

In this example:

• /dev/sda2 is the root partition
• /dev/sda1 is the EFI System Partition
• the disk device is /dev/sda

Mount and chroot. If root uses LUKS, LVM, or mdraid, unlock and assemble devices first (see LUKS, LVM, or mdraid before mounting root). Then follow Typical mount and chroot and use /target instead of /mnt in installer rescue shell when needed.

Reinstall GRUB on BIOS systems

Use this section only for legacy BIOS boot. Run the commands below inside the chroot (after chroot /mnt).

Inside the chroot, install GRUB to the disk device, not a partition:

grub-install /dev/sdX
update-grub

Example:

grub-install /dev/sda
update-grub

For NVMe disks, use the disk name, not the partition:

grub-install /dev/nvme0n1
update-grub

Reinstall GRUB on UEFI systems

Use this section only if the system boots with UEFI and the EFI System Partition is mounted at /boot/efi. Run the commands below inside the chroot (after chroot /mnt).

Confirm the ESP is mounted:

findmnt /boot/efi

UEFI boot entries: grub-install may need access to EFI variables to create or update the Debian boot entry.

First confirm the rescue media was booted in UEFI mode:

ls /sys/firmware/efi

If that directory does not exist, reboot the rescue media and choose the UEFI boot option from the firmware menu.

Then check whether efivarfs is mounted:

mount | grep efivarfs

If it is not mounted, mount it before running grub-install:

mount -t efivarfs none /sys/firmware/efi/efivars

If /sys/firmware/efi/efivars is empty or grub-install cannot write NVRAM entries, reboot the rescue ISO and add the efi=runtime kernel parameter at the boot menu, then mount efivarfs again.

Then reinstall GRUB:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian
update-grub

If grub-install reports success but Debian still does not appear in firmware boot order, check:

efibootmgr -v

An empty list or missing debian entry often means efivarfs was not mounted or rescue media was not booted in UEFI mode.

If efibootmgr is missing, install it from inside the chroot if networking works:

apt update
apt install efibootmgr

Secure Boot: if grub-install reports errors related to shim, Secure Boot, or signed EFI binaries, reinstall shim-signed and grub-efi-amd64-signed (apt install --reinstall shim-signed grub-efi-amd64-signed), then retry grub-install and update-grub. You can also disable Secure Boot in firmware and use the normal UEFI repair path.

After BIOS or UEFI repair, confirm kernels exist: ls -l /boot/vmlinuz-* /boot/initrd.img-*. Run update-grub again if you changed /etc/default/grub. If /boot is empty, mount the correct /boot partition or follow Scenario 4.

Unmount and reboot when finished. Remove rescue media from the boot order before testing.

If GRUB still does not appear

If Debian still does not boot after reinstalling GRUB, check these common causes:

Background: what GRUB files do.

Scenario 4: Debian fails with kernel panic or cannot find root filesystem

Typical errors include VFS: Cannot open root device, Gave up waiting for root device, Failed to mount /, ALERT! UUID does not exist, or a panic shortly after Loading initial ramdisk.

After a power outage, this usually points to one of these problems:

• initramfs was not generated correctly
• GRUB points to the wrong root UUID
• /etc/fstab has a stale or wrong UUID
• the kernel or initramfs file is missing from /boot
• the root filesystem, LVM, LUKS, or RAID device is not being assembled during boot

Mount and chroot

Boot Debian installer rescue mode or a Debian live ISO, identify partitions with lsblk -f and blkid, then follow Typical mount and chroot. If root uses LUKS, LVM, or mdraid, unlock and assemble devices first (see LUKS, LVM, or mdraid before mounting root). Use /target instead of /mnt in installer rescue shell when needed.

Fix kernel, initramfs, and root UUID

Inside the chroot, confirm kernel and initramfs files exist:

ls -l /boot/vmlinuz-*
ls -l /boot/initrd.img-*

A normal Debian system should have matching pairs, for example /boot/vmlinuz-6.1.0-xx-amd64 and /boot/initrd.img-6.1.0-xx-amd64. If /boot is empty, stop and confirm whether /boot is a separate partition that was not mounted.

If initramfs files exist but may be incomplete or stale:

update-initramfs -u -k all
update-grub

If an initramfs file is missing for a kernel, list installed kernel versions with ls /lib/modules, then create it:

update-initramfs -c -k <kernel-version>
update-grub

Example: update-initramfs -c -k 6.1.0-xx-amd64. Use -u to update an existing initramfs; use -c when the file is missing.

Find the real root device and compare it with GRUB and /etc/fstab:

findmnt -no SOURCE /
lsblk -f
blkid
cat /etc/fstab
grep -E 'root=UUID|root=PARTUUID|linux.*/boot/vmlinuz' /boot/grub/grub.cfg

The root=UUID=... or root=PARTUUID=... value in GRUB should point to the partition that contains the installed Debian root filesystem. If /etc/fstab has a wrong UUID, edit it with nano /etc/fstab, then run update-grub.

Reinstall the kernel package if kernel files are missing

If /boot/vmlinuz-* is missing, reinstall the Debian kernel meta-package from inside the chroot.

For a standard amd64 Debian system:

apt update
apt install --reinstall linux-image-amd64

Then rebuild initramfs and GRUB:

update-initramfs -u -k all
update-grub

If the initramfs file is still missing for a specific kernel, create it explicitly:

update-initramfs -c -k <kernel-version>
update-grub

Unmount and reboot when finished. Remove rescue media from the boot order before testing.

Check LUKS, LVM, or mdraid systems

If Debian uses LUKS encryption, LVM, or software RAID, the initramfs must know how to unlock or assemble the root device during boot. From rescue media you must unlock/assemble before mounting root—see LUKS, LVM, or mdraid before mounting root.

Check these files from inside the chroot (or from $ROOT/etc/ before chrooting):

cat /etc/crypttab
cat /etc/fstab

For LVM systems, confirm logical volumes are visible from the rescue environment:

sudo vgchange -ay
lvs
vgs
pvs

For mdraid systems, check and assemble if needed:

cat /proc/mdstat
sudo mdadm --assemble --scan
mdadm --detail --scan

If you changed /etc/crypttab, LVM, or mdraid configuration, rebuild initramfs again:

update-initramfs -u -k all
update-grub

If the same error appears again

If Debian still cannot find the root filesystem, check these common causes:

If logs show repeated I/O error, buffer error, or the disk disappears from lsblk, treat it as a storage problem rather than an initramfs problem.

Scenario 5: apt or dpkg broke after the power outage

If the outage happened during apt upgrade, apt full-upgrade, or dpkg --configure, Debian may refuse new package operations until the package database returns to a consistent state.

This is usually recoverable when the disk is healthy. The safest approach is to inspect first, finish pending package configuration, then fix dependencies.

If you repair packages from a chroot, copy /etc/resolv.conf into the chroot before apt update (see Typical mount and chroot).

Inspect and repair the package database

Start by checking whether Debian already knows about half-installed, unpacked, or broken packages:

sudo dpkg --audit
dpkg -l | grep -E '^iU|^iF|^iH|^rc'

Common states after a power loss include iU (unpacked but not configured), iF (configuration failed), and iH (half-installed). For power-outage recovery, those matter more than rc (removed but config files remain).

Run the command Debian usually recommends after an interrupted package operation:

sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt update

If these commands complete without errors, reboot and confirm the system starts normally:

sudo reboot

Fix locks and stubborn packages

If apt or dpkg reports a lock error, do not delete lock files immediately. First check whether a real package process is still running:

ps aux | grep -E '[a]pt|[d]pkg'
sudo lsof /var/lib/dpkg/lock /var/lib/dpkg/lock-frontend /var/lib/apt/lists/lock /var/cache/apt/archives/lock

If an apt, apt-get, or dpkg process is still active, wait for it to finish. If it is stuck, investigate before killing it. Only remove stale locks when you are sure no package manager process is running:

sudo rm -f /var/lib/dpkg/lock \
           /var/lib/dpkg/lock-frontend \
           /var/lib/apt/lists/lock \
           /var/cache/apt/archives/lock
sudo dpkg --configure -a
sudo apt --fix-broken install

If only one package is causing the failure, identify it with sudo dpkg --audit and dpkg -l | grep -E '^iU|^iF|^iH', then try sudo apt install --reinstall <package-name> followed by sudo apt --fix-broken install and sudo dpkg --configure -a.

If a package is stuck in a reinstall-required state and normal repair does not work, check dpkg -l | grep -E '^..r|^iF|^iH'. As a last resort, remove only the affected package:

sudo dpkg --remove --force-remove-reinstreq <package-name>
sudo apt --fix-broken install
sudo dpkg --configure -a

Avoid destructive dpkg database fixes

Do not follow advice that deletes or recreates /var/lib/dpkg as an early fix:

rm -rf /var/lib/dpkg

That directory contains Debian’s package database. Removing it can make the system unable to track installed packages correctly.

For most interrupted package operations after a power outage, the safer order is:

sudo dpkg --audit
sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt update

If these still fail, read the exact package error before removing anything. The problem is usually one package script, one missing dependency, or a filesystem issue—not the entire dpkg database.

Scenario 6: System boots but root filesystem is read-only

Sometimes Debian still reaches a login prompt after a power outage, but write operations fail with:

Read-only file system

This usually means the kernel mounted / as read-only, or later remounted it read-only after detecting filesystem or storage errors.

Diagnose the root mount state

Check how / is mounted:

findmnt /
findmnt -no SOURCE,OPTIONS /

If the options include ro, the root filesystem is mounted read-only.

Check recent kernel messages:

dmesg | grep -iE 'read-only|I/O error|buffer error|ext4|filesystem|remount'

Also check systemd journal errors:

journalctl -xb -p err

Test write access directly on the root filesystem:

sudo touch /.rw-test && sudo rm /.rw-test

Do not rely only on /tmp for this test because /tmp may be a separate mount or tmpfs.

Try a temporary remount

If logs do not show active I/O errors and the filesystem was only mounted read-only during boot, try remounting / as read-write:

sudo mount -o remount,rw /

Confirm the new mount options:

findmnt -no SOURCE,OPTIONS /

Test writing again:

sudo touch /.rw-test && sudo rm /.rw-test

If this works, the system is writable again. Reboot once and confirm the issue does not return:

sudo reboot

After reboot:

findmnt -no SOURCE,OPTIONS /
systemctl --failed
journalctl -xb -p err

If remount fails or errors return

If remount fails with filesystem errors, or if the root filesystem becomes read-only again, do not keep forcing it writable.

Treat it as a filesystem repair case:

1. Boot Debian installer rescue mode or a Debian live ISO.
2. Identify the root partition with lsblk -f.
3. Make sure the root partition is not mounted.
4. Run the correct filesystem repair tool.

For an ext4 root filesystem:

lsblk -f
findmnt /dev/sdXN
sudo e2fsck -fv /dev/sdXN

Replace /dev/sdXN with the real root partition.

Use Scenario 2 for the full offline filesystem repair flow.

When repair is not safe: disk failure, bad sectors, and backup recovery

Not every Debian boot problem after a power outage is safe to repair in place. If the storage device is failing, repeated fsck, forced writes, or package repairs can make data loss worse.

Stop normal repair steps when you see signs of hardware or storage failure.

Stop if the disk looks unhealthy

Check whether the disk is visible:

lsblk -f
blkid

Check recent kernel errors:

dmesg | grep -iE 'I/O error|buffer error|medium error|rejecting I/O|reset|failed command|read error|write error'

Common danger signs include:

• the disk does not appear in firmware, BIOS/UEFI, or lsblk
• dmesg shows repeated I/O error, medium error, or buffer error
• the disk disappears and reappears during boot
• e2fsck reports the same block errors after every repair
• SMART health reports failure
• the system becomes read-only again immediately after repair

Check SMART health

If smartctl is available, check the disk device:

sudo smartctl -H /dev/sdX
sudo smartctl -a /dev/sdX

Use the disk device, such as /dev/sda, not a partition such as /dev/sda2.

For NVMe disks:

sudo smartctl -a /dev/nvme0n1

If that fails, try sudo smartctl -a /dev/nvme0—the correct device name depends on your kernel and drive.

If smartctl is not installed and the system can still install packages:

sudo apt update
sudo apt install smartmontools

Better path than repeated fsck

If the disk looks unhealthy, use a recovery-first approach:

1. Stop booting from the damaged disk if possible.
2. Attach the disk as a secondary disk, or boot from a live ISO.
3. Copy important files first if the disk is still readable.
4. If possible, clone the disk with ddrescue.
5. Restore Debian onto a healthy disk, or reinstall Debian and restore /home, application data, and configuration files from backup.

Example high-level recovery order:

failing disk detected
→ stop normal repair
→ copy critical data
→ clone/image if possible
→ replace disk
→ restore from backup or reinstall

Why repeated fsck can be risky

fsck and e2fsck repair filesystem metadata. They do not repair failing hardware.

If the disk cannot reliably read or write sectors, repeated repair attempts may:

• move damaged files into lost+found
• remove corrupted directory entries
• rewrite metadata onto unstable storage
• make later data recovery harder

Use fsck when the filesystem is inconsistent but the disk is healthy. Use backup, cloning, or disk replacement when the storage device itself is failing.

Power outages do not always damage disks directly, but they can expose drives that were already weak, full of bad sectors, or close to failure.

Summary

Repairing Debian after a power outage is a routing problem: emergency mode and fstab/fsck for mount failures, offline e2fsck for ext4 inconsistencies, grub-install and update-grub for bootloader damage, update-initramfs and UUID checks for kernel panic, and dpkg --configure -a for interrupted apt. Installer rescue mode or a live ISO gives you an unmounted root when you need it. When SMART, I/O errors, or unrecoverable fsck loops appear, stop forcing repairs and restore from backup.

References

• Debian Installation Guide — Recovering a Broken System
• e2fsck(8) — Debian manpages
• fsck(8) — util-linux
• grub-install(8)
• systemd.special(7) — emergency.target / rescue.target
• On-site: e2fsck in rescue mode, emergency vs rescue targets (systemd concepts on Debian), GRUB files overview