LiveChat 
Support 
Boot Repair on Ubuntu: A Diagnostic Guide to Fixing a System That Won’t Boot
A black screen. A blinking cursor. A cryptic `grub rescue>` prompt where your desktop should be. If your Ubuntu machine won’t boot, the worst thing you can do right now is panic and start reinstalling. Take a breath. A non-booting Ubuntu system is almost always recoverable, and your files are almost always intact — the problem is usually the part that *starts* the system, not the system itself.
The trick to boot repair on Ubuntu is not memorizing commands. It’s diagnosis. If you can match the symptom you’re seeing to the underlying cause, the fix becomes obvious. This guide walks you through that exact process: read the symptom, identify the root cause, apply the right fix. We’ll start with the easy, automated repair that solves most cases, then move to the manual methods for when you need precise control.
Key Takeaways
• Most Ubuntu boot failures are a broken or overwritten GRUB bootloader — not a damaged system. Your data is usually fine.
• Try the easy fix first. The Boot-Repair tool’s one-click “Recommended repair” from a Live USB resolves the large majority of GRUB problems automatically.
• Reach for manual `chroot` + `grub-install` only when the automated repair fails or you need exact control over which disk gets the bootloader.
• Match the symptom to the cause: GRUB issues drop you to a rescue prompt or boot the wrong OS; a bad `/etc/fstab` hangs the boot; filesystem corruption is fixed with `fsck`.
• The lesson scales to servers: keep backups and use VPS snapshots or rescue mode so a broken boot is never a catastrophe.
What does the symptom tell you about the cause?
Before you touch anything, look carefully at *what* the screen is showing you. The failure mode is your single best clue. Here’s how the common Ubuntu boot problems map to their causes and fixes.
| Symptom you see | Likely cause | Fix |
|---|---|---|
| Drops to a `grub rescue>` prompt | GRUB can’t find its configuration; bootloader partly broken | Boot-Repair recommended repair, or manual `grub-install` |
| Boots straight into Windows, no menu | Windows install overwrote the GRUB bootloader | Boot-Repair to reinstall GRUB to the boot disk |
| “No bootable device” / “Operating system not found” | GRUB missing entirely, or wrong boot order in firmware | Reinstall GRUB; check UEFI boot order |
| `minimal BASH-like editing` / `grub>` shell | GRUB loaded but config file missing or unreadable | `update-grub` via chroot, then reinstall GRUB |
| Boot hangs, then drops to `(initramfs)` or emergency shell | Bad `/etc/fstab` entry, or unmountable partition | Recovery mode → fix `/etc/fstab` |
| “Welcome to emergency mode” with fsck errors | Filesystem corruption | `fsck` from recovery or Live USB |
| Black screen after GRUB menu | Often graphics/driver, not bootloader (different class of problem) | Recovery mode → reconfigure drivers |
Read down the first column, find your symptom, and the rest of this article expands on the matching fix.
Why is GRUB the usual culprit?
GRUB (the GRand Unified Bootloader) is the program that runs before Ubuntu does. Its job is to find your kernel, hand off control, and — if you dual-boot — show you a menu to pick an operating system. When GRUB breaks, Ubuntu never gets a chance to start, even though the OS itself is perfectly healthy.
Here’s the single most useful thing to know: the most common Ubuntu boot failure, by a wide margin, is a broken or overwritten GRUB bootloader — and nine times out of ten the fix is the Boot-Repair tool’s one-click “Recommended repair” from a Live USB. You only need the manual `chroot` + `grub-install` method if that automated repair fails or you need precise control over which disk the bootloader is written to. Don’t start with the hard method. Try the easy fix first; it’s faster, it’s safer, and it usually just works.
GRUB typically breaks for one of two reasons:
- You installed Windows alongside Linux. Windows assumes it owns the boot process and cheerfully overwrites the bootloader. Symptom: your machine now boots straight into Windows with no Ubuntu menu, or you get “no bootable device.”
- A failed or interrupted update. A kernel update, a power loss mid-upgrade, or a disk that filled up can leave GRUB’s config half-written. Symptom: you drop to `grub rescue>` or a bare `grub>` shell.
Either way, the cause is the same class of problem — the bootloader needs to be reinstalled or its config regenerated.
How do you fix GRUB with the Boot-Repair tool?
This is your first move for any GRUB-related symptom. The Boot-Repair tool is a well-known graphical utility that automates everything we’d otherwise do by hand.
Step 1: Boot from an Ubuntu Live USB. You’ll need a USB stick flashed with an Ubuntu image (any recent version works). Insert it, then enter your firmware boot menu — usually by tapping F12, F2, Esc, or Del during startup, depending on your hardware. Select the USB device, and choose “Try Ubuntu” (not “Install Ubuntu”) to get a live desktop without touching your disk.
Step 2: Connect to the internet (Wi-Fi or Ethernet) so the tool can download what it needs.
Step 3: Install and launch Boot-Repair. Open a terminal in the live session and run:
“`bash sudo add-apt-repository ppa:yannubuntu/boot-repair sudo apt update sudo apt install -y boot-repair boot-repair “`
Step 4: Click “Recommended repair.” When Boot-Repair opens, it scans your disks and presents two main buttons. Choose Recommended repair. It will reinstall GRUB to the correct disk, regenerate the boot menu, detect other operating systems (including Windows), and fix the most common UEFI issues — all automatically. When it finishes, it shows a summary and a log URL.
Step 5: Remove the USB and reboot. In the large majority of cases, your normal GRUB menu returns and Ubuntu boots cleanly.
If Recommended repair succeeds, you’re done — stop here. Only continue to the manual method below if it fails or you have a specific reason to do it by hand.
How do you reinstall GRUB manually with chroot?
When you need precise control — say, you have multiple disks and must put the bootloader on a *specific* one — you reinstall GRUB by hand. The technique is chroot: you boot a Live USB, mount your real installation, then “step into” it so commands run as if the broken system were actually running.
First, identify your partitions from the live session:
“`bash sudo fdisk -l “`
Find your root partition (the one holding your Ubuntu install, often something like `/dev/sda2` or `/dev/nvme0n1p2`). Now mount it and bind the system directories so GRUB can see your real hardware:
“`bash
sudo mount /dev/sdXY /mnt
sudo mount –bind /dev /mnt/dev sudo mount –bind /proc /mnt/proc sudo mount –bind /sys /mnt/sys “`
If your system uses UEFI, also mount the EFI System Partition (the small FAT32 partition, often `/dev/sda1`) into place:
“`bash sudo mount /dev/sdX1 /mnt/boot/efi “`
Now step into your installation:
“`bash sudo chroot /mnt “`
You’re now operating *inside* your broken system. Reinstall GRUB to the disk (note: the whole disk like `/dev/sda`, not a partition like `/dev/sda2`), then regenerate the menu:
“`bash grub-install /dev/sdX update-grub “`
If you see `Installation finished. No error reported`, it worked. Exit and unmount cleanly:
“`bash exit sudo umount /mnt/boot/efi # only if you mounted it sudo umount /mnt/dev /mnt/proc /mnt/sys sudo umount /mnt “`
Reboot without the USB. If you see “no error reported,” the bootloader is back. The most common mistake here is pointing `grub-install` at a partition instead of the whole disk — if it complains, double-check that you used `/dev/sda`, not `/dev/sda2`.
What does update-grub actually do?
You’ll see `update-grub` in both methods above, and it’s worth understanding on its own. It regenerates the GRUB boot menu by scanning your disks for installed operating systems and kernels, then writing a fresh `/boot/grub/grub.cfg`.
The classic reason to run it manually: you dual-boot, but Windows (or another Linux) stopped showing up in the menu. Boot into Ubuntu (or chroot in from a Live USB), then run:
“`bash sudo update-grub “`
Watch the output — it lists each OS it finds, e.g. `Found Windows Boot Manager on /dev/sda1`. If your other OS appears in that list, it’ll appear in the menu on next boot. If it *doesn’t* appear, the OS-detection helper may be disabled; ensure `GRUB_DISABLE_OS_PROBER=false` is set in `/etc/default/grub`, then run `update-grub` again.
Why does a bad fstab entry hang the boot?
Not every boot failure is GRUB’s fault. If GRUB loads fine, the menu appears, you select Ubuntu — and then the boot hangs or drops you to an `(initramfs)` or emergency shell — the cause is frequently `/etc/fstab`.
`/etc/fstab` tells Ubuntu which filesystems to mount at boot. If you added a drive, changed a UUID, or fat-fingered an entry, Ubuntu may wait forever trying to mount something that isn’t there, then give up into emergency mode.
The fix is to boot into recovery mode and correct the file:
- At the GRUB menu, choose Advanced options for Ubuntu, then the entry ending in (recovery mode).
- From the recovery menu, select root to drop to a root shell.
- Remount the filesystem as writable: `mount -o remount,rw /`
- Edit fstab: `nano /etc/fstab`
- Find the offending line. Comment it out by adding `#` at the start, or fix the wrong UUID. A safe trick: add the `nofail` option to non-critical mounts so a missing drive never blocks boot:
“` UUID=xxxx-xxxx /mnt/data ext4 defaults,nofail 0 2 “`
Save, then reboot. If the system boots after commenting out a single line, that line was your culprit — now you can investigate why that mount failed without being locked out.
How do you repair a corrupted filesystem with fsck?
If recovery mode shows messages about a filesystem that’s “in an inconsistent state,” contains errors, or “could not be mounted,” you’re looking at filesystem corruption — often after an unclean shutdown or power loss.
The tool is fsck (filesystem check). Critically, you should never run fsck on a mounted filesystem, so run it from a Live USB or recovery mode where the target partition is unmounted.
From a Live USB, identify the partition and check it:
“`bash
sudo fsck -f /dev/sdXY “`
The `-f` forces a full check even if the filesystem looks clean. When fsck asks whether to fix errors, answering yes (or running with `-y` to auto-confirm) repairs the inconsistencies it finds. Once it completes without errors, reboot normally.
If fsck reports it repaired errors, try booting again — most corruption from an unclean shutdown is fully recoverable this way.
What’s the lesson for servers and VPS?
Everything above assumes a local desktop or laptop you can plug a USB stick into. On a remote server or VPS, you obviously can’t insert a Live USB — but the same failure modes (broken GRUB, bad fstab, filesystem corruption) absolutely still happen, usually after a kernel update or a disk filling up.
The takeaway is about recoverability, and it’s the same lesson at every scale: a broken boot should be an inconvenience, not a disaster.
- Keep backups. A bootloader problem rarely touches your data — but if a fix goes sideways, a recent backup means you never gamble with your files.
- On a VPS, use snapshots before risky changes. A snapshot taken before a kernel upgrade lets you roll back a broken boot in minutes.
- Use rescue mode. Most quality VPS platforms offer a rescue or recovery environment — the server-side equivalent of a Live USB — that boots an alternate system so you can `chroot` in and run the exact `grub-install` / `fsck` commands from this guide.
This is where your hosting infrastructure earns its keep. DarazHost VPS plans are built on reliable infrastructure with snapshot and rescue capabilities, so if your server won’t come back up after an update, you have a path back — and 24/7 support standing by when you’d rather have a hand on the problem than face a `grub rescue>` prompt alone. The principle holds whether it’s your laptop or a production box: pair good recovery tools with good backups, and a non-booting system is just a bad afternoon, not a lost weekend.
Frequently asked questions
Will boot repair on Ubuntu delete my files? No. Reinstalling GRUB, regenerating the menu with `update-grub`, or fixing `/etc/fstab` only touches the boot process — your data partitions are untouched. The one operation that *modifies* your filesystem is `fsck`, and it repairs structural errors rather than deleting files; even then, data loss is rare and usually limited to files that were already corrupted.
Why does my computer boot straight into Windows after installing it next to Ubuntu? Because the Windows installer overwrote GRUB with its own bootloader. This is the single most common dual-boot complaint. The fix is to boot an Ubuntu Live USB and run the Boot-Repair tool’s “Recommended repair,” which reinstalls GRUB and re-detects Windows so both appear in the menu again.
What’s the difference between `grub-install` and `update-grub`? `grub-install` writes the bootloader itself onto a disk — use it when GRUB is missing or overwritten. `update-grub` regenerates the *menu* (`grub.cfg`) by scanning for kernels and other operating systems — use it when GRUB works but an OS or kernel isn’t listed. Manual repairs often run both: install the loader, then rebuild the menu.
Boot-Repair’s “Recommended repair” didn’t fix it. What now? Move to the manual `chroot` + `grub-install` method, which gives you precise control over which disk receives the bootloader. Read Boot-Repair’s log (it provides a URL) first — it often pinpoints the exact problem, such as a missing EFI partition or the wrong disk being targeted.
Do I need internet access to repair the boot? For the Boot-Repair tool, yes — you install it from a PPA over the network. For the manual `chroot` + `grub-install` method and for `fsck`, no internet is required, since those tools are already present in the Live USB environment or your installed system.
