{"id":7148,"date":"2026-09-16T21:58:55","date_gmt":"2026-09-16T18:58:55","guid":{"rendered":"https:\/\/avenacloud.com\/blog\/how-to-repair-corrupted-ubuntu-os-without-reinstalling\/"},"modified":"2026-09-16T21:58:55","modified_gmt":"2026-09-16T18:58:55","slug":"how-to-repair-corrupted-ubuntu-os-without-reinstalling","status":"publish","type":"post","link":"https:\/\/avenacloud.com\/blog\/how-to-repair-corrupted-ubuntu-os-without-reinstalling\/","title":{"rendered":"How to Repair Corrupted Ubuntu OS? (Without Reinstalling)"},"content":{"rendered":"<figure><img decoding=\"async\" src=\"https:\/\/wd9kbpy1zu.ufs.sh\/f\/zfTUaHBShJ7CdkJB8ETpA3uLsfxFaCKH5rN9mO0PkYMzyWGU\" alt=\"How to Repair Corrupted Ubuntu OS? (Without Reinstalling)\" title=\"\"><\/figure>\n<p>How to repair corrupted Ubuntu OS? The answer is less dramatic than most people fear: most corrupted Ubuntu installations don&#39;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.<\/p>\n<p>I&#39;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.<\/p>\n<h2>How to Repair Corrupted Ubuntu OS? The Short Version<\/h2>\n<ul>\n<li>Boot a Ubuntu Live USB and open a terminal.<\/li>\n<li>Mount your installed root partition and chroot into it.<\/li>\n<li>Run <code>dpkg --configure -a<\/code> and <code>sudo apt --fix-broken install<\/code> to repair packages.<\/li>\n<li>Run <code>fsck -f<\/code> on the root partition if the filesystem itself is damaged.<\/li>\n<li>Reinstall GRUB with <code>grub-install<\/code> if the machine won&#39;t boot at all.<\/li>\n<li>Check <code>\/etc\/fstab<\/code> with <code>mount -a<\/code> if booting drops you into an emergency shell.<\/li>\n<\/ul>\n<p>Each of those steps hides a few gotchas, so the rest of this guide walks through them in order.<\/p>\n<figure class=\"video-embed\"><a class=\"video-embed-link\" href=\"https:\/\/www.youtube.com\/watch?v=i8b7GiIi5So\" target=\"_blank\" rel=\"noopener noreferrer\" aria-label=\"Play video: Ubuntu Won\u2019t Boot? How to Fix a Broken Kernel\" onclick=\"var i=document.createElement(&#039;iframe&#039;);i.src=&#039;https:\/\/www.youtube-nocookie.com\/embed\/i8b7GiIi5So?autoplay=1&#039;;i.title=&#039;Ubuntu Won\u2019t Boot? How to Fix a Broken Kernel&#039;;i.setAttribute(&#039;allow&#039;,&#039;autoplay; encrypted-media; picture-in-picture&#039;);i.setAttribute(&#039;allowfullscreen&#039;,&#039;&#039;);var f=document.createElement(&#039;div&#039;);f.className=&#039;video-embed-frame&#039;;f.appendChild(i);this.parentNode.replaceChild(f,this);return false;\"><img decoding=\"async\" src=\"https:\/\/i.ytimg.com\/vi\/i8b7GiIi5So\/hqdefault.jpg\" alt=\"Ubuntu Won\u2019t Boot? How to Fix a Broken Kernel\" loading=\"lazy\" width=\"1280\" height=\"720\" title=\"\"><span class=\"video-embed-play\" aria-hidden=\"true\"><\/span><\/a><figcaption>Ubuntu Won\u2019t Boot? How to Fix a Broken Kernel<\/figcaption><\/figure>\n<h2>Before Anything Else: Copy Your Data Out<\/h2>\n<p>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 <code>fsck<\/code> 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.<\/p>\n<p>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 <code>~\/.ssh<\/code>, 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.<\/p>\n<p>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&#39;s control panel before touching anything, which is exactly why we build snapshot and recovery options into our <a href=\"https:\/\/avenacloud.com\/\">cloud hosting<\/a> plans at AvenaCloud. Fixing a broken server you can snapshot first is a completely different experience from fixing one you can&#39;t.<\/p>\n<h2>What You Need<\/h2>\n<ul>\n<li>A second computer (or a working phone and patience) to download the Ubuntu ISO.<\/li>\n<li>A USB stick, 4 GB or larger. Everything on it gets erased.<\/li>\n<li>The Ubuntu ISO, ideally the same major version as the broken install. If you&#39;re unsure what version the machine runs, grab the latest LTS from ubuntu.com; it works for repairs across versions in practice.<\/li>\n<li>About an hour, most of it waiting.<\/li>\n<\/ul>\n<p>To write the ISO from another Linux machine:<\/p>\n<pre><code class=\"language-bash\">sudo dd if=ubuntu-24.04-desktop-amd64.iso of=\/dev\/sdX bs=4M status=progress oflag=sync\n<\/code><\/pre>\n<p>Replace <code>\/dev\/sdX<\/code> with your actual USB device. Double check with <code>lsblk<\/code> 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.<\/p>\n<h2>Step 1: Boot the Live Environment<\/h2>\n<p>Insert the USB stick, power on, and hit the boot menu key during POST. On most laptops that&#39;s F12 or F2; on desktop boards it&#39;s often F8, F11, or Del. Select the USB drive from the firmware boot menu. When the Ubuntu menu appears, choose &quot;Try Ubuntu&quot; rather than &quot;Install Ubuntu&quot;. You&#39;ll land on a live desktop that runs entirely from RAM, and your broken installation sits untouched on the disk, ready to be repaired.<\/p>\n<p>One thing worth checking immediately: open &quot;Disks&quot; (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&#39;t detected at all, stop. That&#39;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.<\/p>\n<h2>Step 2: Find and Mount Your Installation<\/h2>\n<p>Open a terminal in the live session and identify your partitions:<\/p>\n<pre><code class=\"language-bash\">sudo fdisk -l\nlsblk -f\n<\/code><\/pre>\n<p>You&#39;re looking for the largest ext4 partition, typically <code>\/dev\/sda2<\/code>, <code>\/dev\/nvme0n1p2<\/code>, or similar. The <code>-f<\/code> flag shows filesystem types, which makes the root partition obvious. If you&#39;re on a UEFI system you&#39;ll also see a small FAT32 partition, around 100 to 500 MB, which is the EFI system partition. Note both.<\/p>\n<p>Mount the root partition and the supporting filesystems:<\/p>\n<pre><code class=\"language-bash\">sudo mount \/dev\/sda2 \/mnt\nsudo mount \/dev\/sda1 \/mnt\/boot\/efi\nfor i in \/dev \/dev\/pts \/proc \/sys \/run; do sudo mount -B $i \/mnt$i; done\n<\/code><\/pre>\n<p>If you use LVM (common on server installs and some desktop defaults), activate the volume group first:<\/p>\n<pre><code class=\"language-bash\">sudo vgchange -ay\nsudo mount \/dev\/ubuntu-vg\/ubuntu-lv \/mnt\n<\/code><\/pre>\n<p>If you use LUKS full-disk encryption, unlock it before mounting:<\/p>\n<pre><code class=\"language-bash\">sudo cryptsetup luksOpen \/dev\/sda3 cryptdisk\nsudo mount \/dev\/mapper\/ubuntu--vg-ubuntu--lv \/mnt\n<\/code><\/pre>\n<p>With everything mounted, chroot in. From this point, every command you run operates on your real installation, not the live session:<\/p>\n<pre><code class=\"language-bash\">sudo chroot \/mnt\n<\/code><\/pre>\n<p>Your prompt changes. You&#39;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.<\/p>\n<h2>Fix 1: Repairing Broken Packages<\/h2>\n<p>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 &quot;was interrupted&quot; or needs reinstallation, and the tail of <code>\/var\/log\/dpkg.log<\/code> shows the upgrade stopping mid-package. A login loop after a partially applied update is common too.<\/p>\n<p>Two commands handle most of it, in this order:<\/p>\n<pre><code class=\"language-bash\">dpkg --configure -a\napt --fix-broken install\n<\/code><\/pre>\n<p>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.<\/p>\n<p>If a specific package is corrupted and reinstalling it outright is cleaner:<\/p>\n<pre><code class=\"language-bash\">apt install --reinstall package-name\n<\/code><\/pre>\n<p>A disk that filled up mid-upgrade is a classic cause, so check space before and after:<\/p>\n<pre><code class=\"language-bash\">df -h\n<\/code><\/pre>\n<p>If the root partition is at 100%, clear out old kernels and apt caches (<code>apt clean<\/code>, <code>apt autoremove --purge<\/code>) before retrying anything, or you&#39;ll just break the packages again.<\/p>\n<h2>Fix 2: Repairing Filesystem Errors<\/h2>\n<p>If you&#39;re repairing a corrupted Ubuntu OS after an improper shutdown or a sudden power loss, the damage is often at the filesystem level, and <code>fsck<\/code> is the tool. It must run on an unmounted partition, so do this from the live session before you chroot, or unmount first:<\/p>\n<pre><code class=\"language-bash\">sudo umount \/mnt\nsudo fsck -f \/dev\/sda2\n<\/code><\/pre>\n<p>The <code>-f<\/code> flag forces a full check even if the filesystem was flagged clean. If fsck finds and fixes errors, it will report them. Answer &quot;yes&quot; to repair prompts unless something looks alarming, in which case, seriously, back up first. Ubuntu&#39;s own documentation recommends the built-in disk utility for this too: open Disks, select the affected disk, and choose &quot;Repair Filesystem&quot;. That&#39;s the friendlier route if the terminal intimidates you, and it does the same job for ext4.<\/p>\n<p>One honest warning from experience: fsck on a badly damaged ext4 filesystem can sometimes leave recovered files in <code>\/lost+found<\/code> with numeric names and no directory structure. That&#39;s still better than the alternative, but it&#39;s another reason the backup step isn&#39;t optional.<\/p>\n<h2>Fix 3: Repairing a Broken GRUB Bootloader<\/h2>\n<p>If the machine boots straight to firmware, shows &quot;GRUB rescue&quot;, or displays <code>error: no such partition<\/code>, the bootloader is the problem. Learning how to repair corrupted Ubuntu OS boot trouble almost always means dealing with GRUB, since it&#39;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.<\/p>\n<p>From inside the chroot environment:<\/p>\n<p>On a BIOS system, reinstall GRUB to the disk&#39;s master boot record:<\/p>\n<pre><code class=\"language-bash\">grub-install \/dev\/sda\nupdate-grub\n<\/code><\/pre>\n<p>Note that this targets the whole disk (<code>\/dev\/sda<\/code>), not a partition (<code>\/dev\/sda2<\/code>). Getting that wrong is a common mistake.<\/p>\n<p>On a UEFI system, which is virtually every machine sold since roughly 2015:<\/p>\n<pre><code class=\"language-bash\">grub-install --target=x86_64-efi --efi-directory=\/boot\/efi --bootloader-id=ubuntu\nupdate-grub\n<\/code><\/pre>\n<p>This writes a fresh GRUB binary to the EFI system partition and registers a boot entry with the firmware. <code>update-grub<\/code> then scans for installed kernels and other operating systems and rebuilds the boot menu. If <code>update-grub<\/code> finds no kernels, your chroot mount is incomplete or your kernel packages are broken; go back to the package repair section.<\/p>\n<p>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 &quot;Recommended repair&quot;, and it handles GRUB reinstallation automatically. It works well for straightforward cases, including dual-boot setups. My honest take: it&#39;s fine for a desktop, but I&#39;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.<\/p>\n<h2>Fix 4: Correcting a Broken \/etc\/fstab<\/h2>\n<p>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 <code>\/<\/code>. Maybe you changed UUIDs, removed a drive, or a partition&#39;s UUID changed after formatting.<\/p>\n<p>From the chroot (or from recovery mode), open the file:<\/p>\n<pre><code class=\"language-bash\">nano \/etc\/fstab\n<\/code><\/pre>\n<p>Compare each entry against reality. Get current UUIDs with:<\/p>\n<pre><code class=\"language-bash\">blkid\n<\/code><\/pre>\n<p>Every UUID in fstab must match one that blkid reports. Then, before you commit to a reboot, test the whole file safely:<\/p>\n<pre><code class=\"language-bash\">mount -a\n<\/code><\/pre>\n<p>If that returns no errors, fstab is good. If it complains about a specific line, fix or comment it out (prefix with <code>#<\/code>). 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&#39;ve removed is always safe; you can add it back later properly.<\/p>\n<h2>Fix 5: Recovering From a Failed Kernel Update<\/h2>\n<p>A failed kernel update is its own special case: you&#39;re repairing a corrupted Ubuntu OS where <code>\/boot<\/code> itself is half-written and sometimes no bootable kernel survives at all. After chrooting, reinstall the kernel package:<\/p>\n<pre><code class=\"language-bash\">apt install --reinstall linux-image-generic linux-headers-generic\nupdate-grub\n<\/code><\/pre>\n<p>If you can still reach GRUB, an alternative is booting an older kernel from the &quot;Advanced options for Ubuntu&quot; menu entry, then running the package repairs from within the working system. That&#39;s faster than the live USB route when the option exists, and you can clean up with <code>apt autoremove --purge<\/code> once you&#39;re in.<\/p>\n<h2>When You Can Still Boot: Recovery Mode Fixes<\/h2>\n<p>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 &quot;Advanced options for Ubuntu&quot; and then a kernel entry ending in &quot;(recovery mode)&quot;. You&#39;ll get a menu with several useful options:<\/p>\n<ul>\n<li><strong>fsck<\/strong>: runs a filesystem check without needing external media.<\/li>\n<li><strong>network<\/strong>: brings up networking so apt can download packages.<\/li>\n<li><strong>dpkg<\/strong>: attempts to repair broken packages, essentially running the dpkg fixes for you.<\/li>\n<li><strong>root<\/strong>: drops you to a root shell for manual work.<\/li>\n<\/ul>\n<p>The root shell plus <code>mount -o remount,rw \/<\/code> 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&#39;t load, which usually means bootloader or filesystem trouble rather than package trouble.<\/p>\n<h2>Black Screen After Login? Check the Graphics Driver<\/h2>\n<p>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&#39;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&#39;s most often true.<\/p>\n<p>Switch to a text console with Ctrl+Alt+F3 (or F4, F5, F6). Log in there with your username and password. From the TTY:<\/p>\n<pre><code class=\"language-bash\">sudo apt purge &#39;nvidia-*&#39;\nsudo apt autoremove\nsudo ubuntu-drivers install\n<\/code><\/pre>\n<p>Purging the NVIDIA drivers and letting <code>ubuntu-drivers<\/code> 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&#39;s no local display stack to corrupt.<\/p>\n<h2>How to Repair a Corrupted USB Drive in Ubuntu<\/h2>\n<p>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.<\/p>\n<ol>\n<li>Plug the drive in and identify it with <code>lsblk<\/code>. Triple-check the device name. This is the one scenario where a typo actually destroys data.<\/li>\n<li>Unmount it: <code>sudo umount \/dev\/sdb1<\/code>.<\/li>\n<li>For ext4: <code>sudo fsck -f \/dev\/sdb1<\/code>.<\/li>\n<li>For FAT32 (most flash drives): <code>sudo fsck.vfat -a \/dev\/sdb1<\/code>, or use GNOME Disks&#39; repair option.<\/li>\n<li>For NTFS (Windows-formatted drives): <code>sudo ntfsfix \/dev\/sdb1<\/code>, which fixes common issues but is not a full chkdsk equivalent. Deep NTFS repair is still best done from Windows itself.<\/li>\n<\/ol>\n<p>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&#39;ll spend fighting one that&#39;s worn out.<\/p>\n<h2>When Repair Fails: Reinstall Without Losing Everything<\/h2>\n<p>If you can&#39;t repair corrupted Ubuntu OS any other way, a reinstall doesn&#39;t have to cost you your data. Sometimes the damage is simply too extensive: a mangled partition table, a filesystem fsck can&#39;t stabilize, an interrupted release upgrade that left package state beyond saving. Even then, you don&#39;t have to nuke your data.<\/p>\n<p>The Ubuntu installer can install over the existing root partition while leaving the home directory intact, provided <code>\/home<\/code> is on its own partition (which server and many manual desktop installs use). During installation, choose manual partitioning, assign your existing root partition as <code>\/<\/code> without formatting it&#8230; actually, let me be more careful here, because this is the step where people lose data. The reliable approach:<\/p>\n<ol>\n<li>From the live session, back up <code>\/home<\/code> to external media. Full stop. Do this regardless.<\/li>\n<li>Reinstall normally, then restore your backup over the fresh install.<\/li>\n<li>Your packages and system config are gone, but your data survives.<\/li>\n<\/ol>\n<p>If you had a package list worth keeping, it lives at a single command&#39;s distance for next time. Run <code>dpkg --get-selections &gt; packages.txt<\/code> from the chroot before giving up, and after reinstalling you can reapply it with <code>dpkg --set-selections &lt; packages.txt<\/code> followed by <code>apt dselect-upgrade<\/code>. Not perfect (PPA packages won&#39;t come back automatically), but it reconstructs 90% of a workstation in one command.<\/p>\n<p>There&#39;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 <a href=\"https:\/\/meldliveapp.com\" target=\"_blank\" rel=\"noopener\">Meldliveapp<\/a> 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.<\/p>\n<h2>Prevention: Make the Next Repair Unnecessary<\/h2>\n<p>Repairs are satisfying but avoidable. A few habits cover the big risks:<\/p>\n<ul>\n<li>Keep 15 to 20% of your root partition free. Full disks corrupt upgrades, full stop.<\/li>\n<li>Don&#39;t force power off during apt operations. If an upgrade looks stuck, wait ten minutes before assuming the worst.<\/li>\n<li>Run <code>apt update &amp;&amp; apt upgrade<\/code> regularly rather than letting months of updates pile into one enormous, riskier upgrade session.<\/li>\n<li>Enable automatic backups of <code>\/home<\/code>, whether that&#39;s D\u00e9j\u00e0 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 <a href=\"https:\/\/csc-audio.com\" target=\"_blank\" rel=\"noopener\">CSC-Audio<\/a>&#39;s audience deals with, treat backup automation as non-negotiable because a corrupted sample library is unrecoverable in a way code rarely is.<\/li>\n<li>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.<\/li>\n<\/ul>\n<h2>Quick FAQ<\/h2>\n<p><strong>How do you repair corrupted Ubuntu OS?<\/strong><br \/>\nIt depends which layer broke. Package damage responds to <code>dpkg --configure -a<\/code> and <code>apt --fix-broken install<\/code> from a chroot. Filesystem damage needs <code>fsck -f<\/code> on an unmounted partition. Boot failures point at GRUB and need <code>grub-install<\/code> plus <code>update-grub<\/code>. Diagnose the layer first, then apply the matching fix from the sections above.<\/p>\n<p><strong>Is there an Ubuntu boot repair app?<\/strong><br \/>\nYes. Boot-Repair is the best-known one. It&#39;s a graphical tool you install in the live session, and its &quot;Recommended repair&quot; button reinstalls and reconfigures GRUB automatically. It handles simple bootloader problems and dual-boot setups well. For anything involving packages or fstab it won&#39;t help much; the manual chroot method gives you far more control there.<\/p>\n<p><strong>How do I repair boot on Ubuntu?<\/strong><br \/>\nFrom a chroot on a UEFI machine: <code>grub-install --target=x86_64-efi --efi-directory=\/boot\/efi --bootloader-id=ubuntu<\/code>, then <code>update-grub<\/code>. On older BIOS systems, target the whole disk (<code>\/dev\/sdX<\/code>), never a partition. If even the GRUB rescue prompt never appears, check that the EFI system partition is still present and mounted.<\/p>\n<p><strong>How do you repair corrupted Ubuntu OS from a bootable USB?<\/strong><br \/>\nBoot it, choose &quot;Try Ubuntu&quot;, and confirm your partitions with <code>lsblk -f<\/code>. Mount the root partition (plus <code>\/boot\/efi<\/code> on UEFI systems), bind-mount <code>\/dev<\/code>, <code>\/proc<\/code>, <code>\/sys<\/code>, and <code>\/run<\/code>, then <code>chroot<\/code> in. Everything you run from that point applies to the broken installation rather than the live session.<\/p>\n<p><strong>How do you repair corrupted Ubuntu OS from the command line?<\/strong><br \/>\nIf GRUB still loads, recovery mode is quicker: pick a recovery kernel entry, drop to the root shell, remount read-write with <code>mount -o remount,rw \/<\/code>, and run the package repairs there. If the machine won&#39;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.<\/p>\n<p><strong>How do I repair a corrupted USB drive in Ubuntu?<\/strong><br \/>\nIdentify the device with <code>lsblk<\/code>, unmount it, then run <code>sudo fsck -f \/dev\/sdb1<\/code> for ext4 or <code>sudo fsck.vfat -a \/dev\/sdb1<\/code> for FAT32 drives. GNOME Disks offers a graphical &quot;Repair Filesystem&quot; option that does the same thing. If repairs fail more than once, the drive&#39;s flash memory is likely worn out; replace it.<\/p>\n<h2>Where to Start<\/h2>\n<p>If your machine won&#39;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 <code>lsblk -f<\/code>, 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.<\/p>\n<p><script type=\"application\/ld+json\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"BlogPosting\",\"headline\":\"How to Repair Corrupted Ubuntu OS? (Without Reinstalling)\",\"description\":\"How to repair corrupted Ubuntu OS? Fix broken packages, GRUB, fstab, and filesystem errors from a Live USB, step by step, without losing your data.\",\"inLanguage\":\"en\",\"mainEntityOfPage\":{\"@type\":\"WebPage\",\"@id\":\"https:\/\/avenacloud.com\/how-to-repair-corrupted-ubuntu-os-without-reinstalling\"},\"url\":\"https:\/\/avenacloud.com\/how-to-repair-corrupted-ubuntu-os-without-reinstalling\",\"publisher\":{\"@type\":\"Organization\",\"name\":\"AvenaCloud\"},\"image\":[\"https:\/\/wd9kbpy1zu.ufs.sh\/f\/zfTUaHBShJ7CdkJB8ETpA3uLsfxFaCKH5rN9mO0PkYMzyWGU\"],\"author\":{\"@type\":\"Person\",\"name\":\"AvenaCloud\"}},{\"@type\":\"FAQPage\",\"mainEntity\":[{\"@type\":\"Question\",\"name\":\"How do you repair corrupted Ubuntu OS?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"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.\"}},{\"@type\":\"Question\",\"name\":\"Is there an Ubuntu boot repair app?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"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.\"}},{\"@type\":\"Question\",\"name\":\"How do I repair boot on Ubuntu?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"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.\"}},{\"@type\":\"Question\",\"name\":\"How do you repair corrupted Ubuntu OS from a bootable USB?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"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.\"}},{\"@type\":\"Question\",\"name\":\"How do you repair corrupted Ubuntu OS from the command line?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"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.\"}},{\"@type\":\"Question\",\"name\":\"How do I repair a corrupted USB drive in Ubuntu?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"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.\"}}]}]}<\/script><\/p>\n","protected":false},"excerpt":{"rendered":"<p>How to repair corrupted Ubuntu OS: fix broken packages, GRUB, fstab, and filesystem errors from a Live USB, step by step, without losing data.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-7148","post","type-post","status-publish","format-standard","hentry","category-vps-vds"],"_links":{"self":[{"href":"https:\/\/avenacloud.com\/blog\/wp-json\/wp\/v2\/posts\/7148","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/avenacloud.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/avenacloud.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/avenacloud.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/avenacloud.com\/blog\/wp-json\/wp\/v2\/comments?post=7148"}],"version-history":[{"count":0,"href":"https:\/\/avenacloud.com\/blog\/wp-json\/wp\/v2\/posts\/7148\/revisions"}],"wp:attachment":[{"href":"https:\/\/avenacloud.com\/blog\/wp-json\/wp\/v2\/media?parent=7148"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/avenacloud.com\/blog\/wp-json\/wp\/v2\/categories?post=7148"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/avenacloud.com\/blog\/wp-json\/wp\/v2\/tags?post=7148"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}