How to Repair Corrupted Ubuntu OS? (Without Reinstalling)

How to repair corrupted Ubuntu OS? The answer is less dramatic than most people fear: most corrupted Ubuntu installations don't need a reinstall. The bootloader, the package database, and the filesystem are separate things, and when one of them breaks, the other two are usually fine. A failed upgrade, a power cut mid-update, a full disk, or an edited fstab that no longer matches reality can all leave you staring at a blinking cursor or a GRUB rescue prompt, and in nearly every one of those cases you can be back on your desktop in under an hour with a Live USB and a handful of terminal commands.

I've recovered a fair number of Ubuntu machines over the years, including one of my own that died halfway through a 23.10 to 24.04 upgrade because the router decided to reboot itself at the worst possible moment. That one took about twenty minutes to fix. Before you reach for the installer USB, work through the steps below. Reinstalling is the last resort, not the first one.

How to Repair Corrupted Ubuntu OS? The Short Version

• Boot a Ubuntu Live USB and open a terminal.
• Mount your installed root partition and chroot into it.
• Run dpkg --configure -a and sudo apt --fix-broken install to repair packages.
• Run fsck -f on the root partition if the filesystem itself is damaged.
• Reinstall GRUB with grub-install if the machine won't boot at all.
• Check /etc/fstab with mount -a if booting drops you into an emergency shell.

Each of those steps hides a few gotchas, so the rest of this guide walks through them in order.

Before Anything Else: Copy Your Data Out

If your drive still mounts from the live session, spend ten minutes backing up before you change anything. This is the step most people skip and the one they regret. Repair commands like fsck are safe in the overwhelming majority of cases, but they are not risk-free, and if the partition table itself is damaged, a wrong move can turn a recoverable problem into a lost one.

From the live environment, plug in an external drive or mount a network share and copy out whatever matters: home directories, project folders, database dumps, SSH keys in ~/.ssh, your browser profile if you live in it. Even a partial backup beats nothing. Anyone who has lost a weekend to a badly damaged filesystem learns this the hard way, which is why the rule gets drilled in so hard: before you attempt to repair a corrupted Ubuntu OS install, copy the data out first.

If the machine is a server you rent rather than hardware on your desk, the same logic applies with a shortcut. On a managed VPS you can usually snapshot the disk from the provider's control panel before touching anything, which is exactly why we build snapshot and recovery options into our cloud hosting plans at AvenaCloud. Fixing a broken server you can snapshot first is a completely different experience from fixing one you can't.

What You Need

• A second computer (or a working phone and patience) to download the Ubuntu ISO.
• A USB stick, 4 GB or larger. Everything on it gets erased.
• The Ubuntu ISO, ideally the same major version as the broken install. If you're unsure what version the machine runs, grab the latest LTS from ubuntu.com; it works for repairs across versions in practice.
• About an hour, most of it waiting.

To write the ISO from another Linux machine:

sudo dd if=ubuntu-24.04-desktop-amd64.iso of=/dev/sdX bs=4M status=progress oflag=sync

Replace /dev/sdX with your actual USB device. Double check with lsblk before you run this, because dd will happily overwrite a disk you care about if you point it at the wrong device. On Windows, Rufus does the same job. On macOS, balenaEtcher.

Step 1: Boot the Live Environment

Insert the USB stick, power on, and hit the boot menu key during POST. On most laptops that's F12 or F2; on desktop boards it's often F8, F11, or Del. Select the USB drive from the firmware boot menu. When the Ubuntu menu appears, choose "Try Ubuntu" rather than "Install Ubuntu". You'll land on a live desktop that runs entirely from RAM, and your broken installation sits untouched on the disk, ready to be repaired.

One thing worth checking immediately: open "Disks" (GNOME Disks) from the applications menu and see whether your drive shows up with a healthy-looking partition table. If the disk makes clicking noises or isn't detected at all, stop. That's a hardware failure, not a software corruption problem, and no amount of chrooting will help. Clone or image the drive first if the data matters.

Step 2: Find and Mount Your Installation

Open a terminal in the live session and identify your partitions:

sudo fdisk -l
lsblk -f

You're looking for the largest ext4 partition, typically /dev/sda2, /dev/nvme0n1p2, or similar. The -f flag shows filesystem types, which makes the root partition obvious. If you're on a UEFI system you'll also see a small FAT32 partition, around 100 to 500 MB, which is the EFI system partition. Note both.

Mount the root partition and the supporting filesystems:

sudo mount /dev/sda2 /mnt
sudo mount /dev/sda1 /mnt/boot/efi
for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done

If you use LVM (common on server installs and some desktop defaults), activate the volume group first:

sudo vgchange -ay
sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt

If you use LUKS full-disk encryption, unlock it before mounting:

sudo cryptsetup luksOpen /dev/sda3 cryptdisk
sudo mount /dev/mapper/ubuntu--vg-ubuntu--lv /mnt

With everything mounted, chroot in. From this point, every command you run operates on your real installation, not the live session:

sudo chroot /mnt

Your prompt changes. You're now effectively booted into your broken system, just without the kernel and display manager. Work down the fixes in order of likelihood: packages first, then the filesystem, then the bootloader, then fstab.

Fix 1: Repairing Broken Packages

This is the fix for the most common failure: an upgrade interrupted by a power cut, a full disk, or a dropped network connection. Most attempts to repair corrupted Ubuntu OS start in this section, because interrupted upgrades are the single most frequent cause. The symptoms are specific if you know where to look: apt fails with unmet dependency errors, dpkg reports that a package "was interrupted" or needs reinstallation, and the tail of /var/log/dpkg.log shows the upgrade stopping mid-package. A login loop after a partially applied update is common too.

Two commands handle most of it, in this order:

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

The first one finishes configuring any packages that were left half-installed when things went wrong. The second resolves and repairs dependency breakage. If apt asks you to confirm, read what it proposes, then let it run. These two commands have stayed standard for years because they work.

If a specific package is corrupted and reinstalling it outright is cleaner:

apt install --reinstall package-name

A disk that filled up mid-upgrade is a classic cause, so check space before and after:

df -h

If the root partition is at 100%, clear out old kernels and apt caches (apt clean, apt autoremove --purge) before retrying anything, or you'll just break the packages again.

Fix 2: Repairing Filesystem Errors

If you're repairing a corrupted Ubuntu OS after an improper shutdown or a sudden power loss, the damage is often at the filesystem level, and fsck is the tool. It must run on an unmounted partition, so do this from the live session before you chroot, or unmount first:

sudo umount /mnt
sudo fsck -f /dev/sda2

The -f flag forces a full check even if the filesystem was flagged clean. If fsck finds and fixes errors, it will report them. Answer "yes" to repair prompts unless something looks alarming, in which case, seriously, back up first. Ubuntu's own documentation recommends the built-in disk utility for this too: open Disks, select the affected disk, and choose "Repair Filesystem". That's the friendlier route if the terminal intimidates you, and it does the same job for ext4.

One honest warning from experience: fsck on a badly damaged ext4 filesystem can sometimes leave recovered files in /lost+found with numeric names and no directory structure. That's still better than the alternative, but it's another reason the backup step isn't optional.

Fix 3: Repairing a Broken GRUB Bootloader

If the machine boots straight to firmware, shows "GRUB rescue", or displays error: no such partition, the bootloader is the problem. Learning how to repair corrupted Ubuntu OS boot trouble almost always means dealing with GRUB, since it's the layer sitting between your firmware and the kernel. Windows reinstallations wiping GRUB on dual-boot machines are a classic case, as are firmware updates that reset the boot order.

From inside the chroot environment:

On a BIOS system, reinstall GRUB to the disk's master boot record:

grub-install /dev/sda
update-grub

Note that this targets the whole disk (/dev/sda), not a partition (/dev/sda2). Getting that wrong is a common mistake.

On a UEFI system, which is virtually every machine sold since roughly 2015:

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

This writes a fresh GRUB binary to the EFI system partition and registers a boot entry with the firmware. update-grub then scans for installed kernels and other operating systems and rebuilds the boot menu. If update-grub finds no kernels, your chroot mount is incomplete or your kernel packages are broken; go back to the package repair section.

If chrooting feels like too much, the Boot-Repair utility remains a legitimate shortcut. You add its PPA from the live session, launch it, click "Recommended repair", and it handles GRUB reinstallation automatically. It works well for straightforward cases, including dual-boot setups. My honest take: it's fine for a desktop, but I'd rather do the manual chroot repair on a server, because you learn exactly what was wrong and Boot-Repair sometimes writes a cluttered GRUB config full of fallback entries.

Fix 4: Correcting a Broken /etc/fstab

A fstab mismatch is the least common cause on this list, but when you repair corrupted Ubuntu OS machines that drop straight into an emergency shell, this is usually why. The telltale message is a maintenance prompt complaining about mounting /. Maybe you changed UUIDs, removed a drive, or a partition's UUID changed after formatting.

From the chroot (or from recovery mode), open the file:

nano /etc/fstab

Compare each entry against reality. Get current UUIDs with:

blkid

Every UUID in fstab must match one that blkid reports. Then, before you commit to a reboot, test the whole file safely:

mount -a

If that returns no errors, fstab is good. If it complains about a specific line, fix or comment it out (prefix with #). This test-before-reboot habit has saved me more reboots-into-rescue-cycles than I can count. Commenting out a line for a drive you've removed is always safe; you can add it back later properly.

Fix 5: Recovering From a Failed Kernel Update

A failed kernel update is its own special case: you're repairing a corrupted Ubuntu OS where /boot itself is half-written and sometimes no bootable kernel survives at all. After chrooting, reinstall the kernel package:

apt install --reinstall linux-image-generic linux-headers-generic
update-grub

If you can still reach GRUB, an alternative is booting an older kernel from the "Advanced options for Ubuntu" menu entry, then running the package repairs from within the working system. That's faster than the live USB route when the option exists, and you can clean up with apt autoremove --purge once you're in.

When You Can Still Boot: Recovery Mode Fixes

Not every corruption requires a live USB. If the bootloader and filesystem are healthy, recovery mode is the fastest way to repair corrupted Ubuntu OS, and it needs no external media at all. Pick "Advanced options for Ubuntu" and then a kernel entry ending in "(recovery mode)". You'll get a menu with several useful options:

• fsck: runs a filesystem check without needing external media.
• network: brings up networking so apt can download packages.
• dpkg: attempts to repair broken packages, essentially running the dpkg fixes for you.
• root: drops you to a root shell for manual work.

The root shell plus mount -o remount,rw / gets you a writable filesystem, from which the package repairs work exactly as they do in a chroot. For many software-level breakages, recovery mode is the ten-minute path. Use the live USB when recovery mode itself won't load, which usually means bootloader or filesystem trouble rather than package trouble.

Black Screen After Login? Check the Graphics Driver

A separate and very common category: the system boots, you get a login prompt, you log in, and the screen goes black or freezes. Often this isn't a case where you need to repair corrupted Ubuntu OS at all; the filesystem and packages are usually fine. The graphics driver is the suspect, and on NVIDIA hardware that's most often true.

Switch to a text console with Ctrl+Alt+F3 (or F4, F5, F6). Log in there with your username and password. From the TTY:

sudo apt purge 'nvidia-*'
sudo apt autoremove
sudo ubuntu-drivers install

Purging the NVIDIA drivers and letting ubuntu-drivers pick a fresh, compatible set resolves the majority of black-screen cases. If the machine is headless or you manage it remotely, this whole class of problem disappears anyway, which is part of why we run most production Ubuntu workloads on VPS instances at AvenaCloud rather than local hardware; there's no local display stack to corrupt.

How to Repair a Corrupted USB Drive in Ubuntu

Since it comes up constantly: the same repair logic applies to USB sticks and external drives, but simpler. No bootloader, no packages, just a filesystem.

1. Plug the drive in and identify it with lsblk. Triple-check the device name. This is the one scenario where a typo actually destroys data.
2. Unmount it: sudo umount /dev/sdb1.
3. For ext4: sudo fsck -f /dev/sdb1.
4. For FAT32 (most flash drives): sudo fsck.vfat -a /dev/sdb1, or use GNOME Disks' repair option.
5. For NTFS (Windows-formatted drives): sudo ntfsfix /dev/sdb1, which fixes common issues but is not a full chkdsk equivalent. Deep NTFS repair is still best done from Windows itself.

If the drive fails fsck repeatedly or mounts read-only no matter what, the flash memory is dying. Replace it. USB sticks are cheaper than the hours you'll spend fighting one that's worn out.

When Repair Fails: Reinstall Without Losing Everything

If you can't repair corrupted Ubuntu OS any other way, a reinstall doesn't have to cost you your data. Sometimes the damage is simply too extensive: a mangled partition table, a filesystem fsck can't stabilize, an interrupted release upgrade that left package state beyond saving. Even then, you don't have to nuke your data.

The Ubuntu installer can install over the existing root partition while leaving the home directory intact, provided /home is on its own partition (which server and many manual desktop installs use). During installation, choose manual partitioning, assign your existing root partition as / without formatting it… actually, let me be more careful here, because this is the step where people lose data. The reliable approach:

1. From the live session, back up /home to external media. Full stop. Do this regardless.
2. Reinstall normally, then restore your backup over the fresh install.
3. Your packages and system config are gone, but your data survives.

If you had a package list worth keeping, it lives at a single command's distance for next time. Run dpkg --get-selections > packages.txt from the chroot before giving up, and after reinstalling you can reapply it with dpkg --set-selections < packages.txt followed by apt dselect-upgrade. Not perfect (PPA packages won't come back automatically), but it reconstructs 90% of a workstation in one command.

There's also a middle path worth knowing: instead of repairing or reinstalling the OS, you can salvage the installation by moving it. A VPS rebuild with the old disk mounted as a secondary volume, or a physical machine with the drive placed in an external enclosure, lets you copy everything off at your leisure. The same discipline applies to streaming and media workloads, where sites like Meldliveapp depend on keeping their runtime environment separate from their data; when the OS layer breaks, a clean rebuild plus a data restore is often faster than surgery.

Prevention: Make the Next Repair Unnecessary

Repairs are satisfying but avoidable. A few habits cover the big risks:

• Keep 15 to 20% of your root partition free. Full disks corrupt upgrades, full stop.
• Don't force power off during apt operations. If an upgrade looks stuck, wait ten minutes before assuming the worst.
• Run apt update && apt upgrade regularly rather than letting months of updates pile into one enormous, riskier upgrade session.
• Enable automatic backups of /home, whether that's Déjà Dup, restic, or rsync to another machine. Audio production servers are a good example of where this pays off; studios running Ubuntu for audio work, the kind of setup CSC-Audio's audience deals with, treat backup automation as non-negotiable because a corrupted sample library is unrecoverable in a way code rarely is.
• On servers, take snapshots before upgrades. On rented infrastructure this is a one-click operation, and it turns any failed upgrade into a five-minute rollback instead of an evening of chrooting.

Quick FAQ

How do you repair corrupted Ubuntu OS?
It depends which layer broke. Package damage responds to dpkg --configure -a and apt --fix-broken install from a chroot. Filesystem damage needs fsck -f on an unmounted partition. Boot failures point at GRUB and need grub-install plus update-grub. Diagnose the layer first, then apply the matching fix from the sections above.

Is there an Ubuntu boot repair app?
Yes. Boot-Repair is the best-known one. It's a graphical tool you install in the live session, and its "Recommended repair" button reinstalls and reconfigures GRUB automatically. It handles simple bootloader problems and dual-boot setups well. For anything involving packages or fstab it won't help much; the manual chroot method gives you far more control there.

How do I repair boot on Ubuntu?
From a chroot on a UEFI machine: grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu, then update-grub. On older BIOS systems, target the whole disk (/dev/sdX), never a partition. If even the GRUB rescue prompt never appears, check that the EFI system partition is still present and mounted.

How do you repair corrupted Ubuntu OS from a bootable USB?
Boot it, choose "Try Ubuntu", and confirm your partitions with lsblk -f. Mount the root partition (plus /boot/efi on UEFI systems), bind-mount /dev, /proc, /sys, and /run, then chroot in. Everything you run from that point applies to the broken installation rather than the live session.

How do you repair corrupted Ubuntu OS from the command line?
If GRUB still loads, recovery mode is quicker: pick a recovery kernel entry, drop to the root shell, remount read-write with mount -o remount,rw /, and run the package repairs there. If the machine won't reach GRUB, the same repairs run inside a chroot from a Live USB. Filesystem checks have to happen on an unmounted partition either way.

How do I repair a corrupted USB drive in Ubuntu?
Identify the device with lsblk, unmount it, then run sudo fsck -f /dev/sdb1 for ext4 or sudo fsck.vfat -a /dev/sdb1 for FAT32 drives. GNOME Disks offers a graphical "Repair Filesystem" option that does the same thing. If repairs fail more than once, the drive's flash memory is likely worn out; replace it.

Where to Start

If your machine won't boot right now, resist the urge to run commands at random. Start with the diagnosis: a firmware screen with no GRUB means bootloader trouble, an emergency shell points at fstab, and a login loop or a failed upgrade points at packages. Then grab a spare USB stick, write the Ubuntu ISO to it on any working computer, and boot it. Confirm your data is readable with lsblk -f, copy off anything irreplaceable, and work down the fixes in the order they appear above. Knowing how to repair corrupted Ubuntu OS is mostly knowing which layer broke, and one repair session will teach you more about how your system fits together than a year of smooth operation.