
September 11, 2026
11 min read
By Kokil Thapa | Last reviewed: September 2026
Your machine powers on, but Ubuntu never reaches the login screen. A kernel update, Windows patch, or resized partition can break the boot chain in minutes. This Ubuntu Boot Repair Guide is written for developers and sysadmins who run production stacks on Ubuntu 22.04 or 24.04 LTS. If you maintain web servers or local dev boxes, boot repair is a core skill — not a last resort. Start with the Ubuntu installation troubleshooting checklist to rule out hardware faults before you touch GRUB.
grub-install plus update-grub against the correct disk, fix EFI entries with efibootmgr on UEFI systems, then reboot. This Ubuntu Boot Repair Guide covers both automated and manual paths.What causes Ubuntu boot failures after updates or disk changes?
Boot failure means the firmware cannot find a valid bootloader, or GRUB cannot locate your kernel and initramfs. The symptoms look similar, but the root cause differs.
Common triggers include these scenarios:
- Windows Update overwriting the EFI boot order on dual-boot laptops
apt upgradeinstalling a new kernel while GRUB was not refreshed- Cloning a disk without regenerating UUIDs in
/etc/fstab - Removing a Linux partition that still held
/bootor/boot/efi - Full-disk encryption with a missing or renamed LUKS header partition
- RAID or LVM layout changes without updating the initramfs
On production VPS instances I maintain, boot issues are rare but painful. A broken cron path after deploy is annoying; a server that will not boot is a full outage. That is why I snapshot disks before major upgrades, as covered in our Ubuntu server backup strategies article.
Read the error message before you reinstall
Write down exactly what appears on screen. error: no such partition points to a stale GRUB config. GRUB rescue> means GRUB core loaded but config is missing. A blank screen after the vendor logo often means the EFI boot entry vanished — common after dual-booting Ubuntu with Windows.
Boot once from a live USB. Choose Try Ubuntu. Open a terminal and identify disks:
sudo fdisk -l
lsblk -f
sudo blkid Match your root partition by size, filesystem label, or UUID. Note whether the disk uses GPT with an EFI System Partition (ESP), typically FAT32 at 100–512 MB. You will need that path for every repair method below.
How do you use Boot Repair from a live USB?
Boot Repair is the fastest fix for standard desktop installs. It reinstalls GRUB, rebuilds EFI entries, and flags common dual-boot mistakes. I reach for it on client laptops before manual chroot work.
Follow these steps from the live session:
- Boot the Ubuntu live USB and connect to the internet.
- Open a terminal and add the Boot Repair PPA, then install the package.
- Launch Boot Repair and choose Recommended repair.
- Copy the URL it generates if you want a shareable report.
- Reboot, remove the USB, and test both OS entries if dual-booting.
sudo add-apt-repository ppa:yannubuntu/boot-repair
sudo apt update
sudo apt install boot-repair
boot-repair Boot Repair writes GRUB to the disk you select and runs update-grub inside a chroot automatically. On UEFI machines it also registers ubuntu with efibootmgr. Official background on GRUB behaviour is documented in the Ubuntu community Boot Repair page.
Boot Repair is not magic. It can misidentify the boot disk on multi-disk workstations. Always verify the target device in the advanced options before applying changes. Wrong-disk installs are recoverable, but they waste time.
How do you fix GRUB manually from the Ubuntu recovery shell?
Manual repair teaches you what Boot Repair automates. Use it when the GUI fails, on headless servers restored from snapshot, or when you need precise control. The pattern is mount, chroot, reinstall GRUB, regenerate config, update initramfs.
Assume root is /dev/nvme0n1p2 and ESP is /dev/nvme0n1p1. Adjust for your system.
Mount and chroot
sudo mount /dev/nvme0n1p2 /mnt
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
for d in dev proc sys run; do sudo mount --bind /$d /mnt/$d; done
sudo chroot /mnt Inside the chroot, reinstall GRUB to the whole disk — not a partition number:
grub-install /dev/nvme0n1
update-grub
exit Unmount in reverse order, then reboot:
sudo umount /mnt/run /mnt/sys /mnt/proc /mnt/dev
sudo umount /mnt/boot/efi
sudo umount /mnt
sudo reboot If update-grub warns about missing /boot/vmlinuz, your kernel packages may be broken. Reinstall from the chroot:
apt install --reinstall linux-image-generic linux-headers-generic
update-initramfs -u -k all The GNU project documents low-level GRUB commands in the official GRUB manual. Keep it open when editing /etc/default/grub.
GRUB rescue prompt quick fixes
At grub rescue>, GRUB can only see certain partitions. List them with ls. Probe until you find a partition containing /boot/grub:
grub rescue> ls
grub rescue> ls (hd0,gpt2)/
grub rescue> set root=(hd0,gpt2)
grub rescue> set prefix=(hd0,gpt2)/boot/grub
grub rescue> insmod normal
grub rescue> normal That should reach the full GRUB menu temporarily. Boot Ubuntu, then run permanent repair from a root shell. Our essential Ubuntu terminal commands reference helps if you rarely work from the console.
How do you repair Ubuntu boot on UEFI vs Legacy BIOS systems?
UEFI and Legacy BIOS store bootloaders differently. Applying Legacy commands on a UEFI-only laptop wastes an hour. Check firmware mode first.
| Check | UEFI (GPT) | Legacy BIOS (MBR) |
|---|---|---|
| Partition table | GPT with ESP (FAT32) | MBR, often one primary boot flag |
| GRUB target | grub-install + EFI file in ESP | grub-install /dev/sdX to MBR |
| Boot order tool | efibootmgr -v | BIOS boot priority list |
| Typical failure | Missing ubuntu EFI entry | Overwritten MBR by Windows |
| Secure Boot | May require signed shim | Not applicable |
On UEFI, list entries from the live session:
sudo efibootmgr -v You should see Boot000* entries pointing to \\EFI\\ubuntu\\shimx64.efi or grubx64.efi. If Ubuntu is missing, recreate it after chroot:
efibootmgr --create --disk /dev/nvme0n1 --part 1 \
--loader /EFI/ubuntu/grubx64.efi --label Ubuntu Secure Boot adds friction. Ubuntu ships signed shims, but custom kernels may fail validation. Disable Secure Boot temporarily in firmware settings if you see Verification failed during boot. Re-enable after repair if your policy requires it. Server hardening guides like our Ubuntu web server hardening article discuss firmware trade-offs separately from desktop recovery.
Dual-boot and BitLocker gotchas
Windows on the same disk often resets boot priority after feature updates. Repair GRUB from Linux, then boot Windows once and use Advanced startup → UEFI Firmware Settings to move Ubuntu first. BitLocker may prompt for recovery key after boot sector changes — have the key ready before repair.
For encrypted root, unlock LUKS from the live session before chroot:
sudo cryptsetup open /dev/nvme0n1p3 cryptroot
sudo vgchange -ay
sudo mount /dev/mapper/ubuntu--vg-root /mnt Store encryption passphrases in a secure vault. A strong password generator helps when rotating LUKS keys after recovery.
What advanced recovery steps fix fstab, RAID, and server boot issues?
Desktop Boot Repair rarely touches /etc/fstab or LVM names. Servers break differently. I have seen Deployer releases fail because someone rebooted mid-upgrade — the kernel updated but initramfs did not finish.
Broken fstab drops you to emergency mode
From the GRUB menu, press e on the Ubuntu entry. Add init=/bin/bash to the linux line, then press Ctrl+X. Remount root read-write:
mount -o remount,rw /
nano /etc/fstab Comment out bad UUID lines, reboot normally, then fix UUIDs with blkid. The Ubuntu file permissions guide pairs well here when restoring mount options on web roots.
Software RAID and netplan on headless boxes
MD RAID arrays need update-initramfs after layout changes. Verify /etc/mdadm/mdadm.conf inside chroot. Network-booted rescue environments may need correct NIC names — see our Ubuntu Netplan tutorial if the server boots but services fail because networking never came up.
For EC2 instances hosting Laravel stacks, I keep an AMI snapshot before kernel cycles. Sites on shared infrastructure — like those described in our Notary Kathmandu portfolio case — depend on predictable reboots after PHP-FPM deploys. Boot repair on cloud VMs usually means detach volume, attach to helper instance, chroot, repair, reattach.
When should you reinstall Ubuntu instead of repairing the boot loader?
Repair beats reinstall when root filesystem data is intact and only the bootloader or kernel metadata is wrong. Reinstall or restore from backup when the root partition is corrupted, ransomware-encrypted, or physically failing.
Choose reinstall when:
fsckreports unrecoverable inode damage on/- The disk throws SMART errors or I/O timeouts under load
- Multiple repair passes still drop to
grub rescue>with empty/boot - You cannot decrypt LUKS after header damage
- The system is a fresh VM and rebuild is faster than debug
Choose repair when:
- Windows update stole boot priority but Linux partitions are untouched
update-grubwas never run after a kernel upgrade- EFI entries were deleted but
/bootcontents exist - You cloned a disk and only UUIDs in fstab need updating
On new developer machines, a clean install following the Ubuntu for developers guide may take less time than deep chroot surgery. On production, restoration from snapshot wins — align that with ongoing server support and maintenance so boot incidents are not solo firefights.
If you host client sites on Ubuntu VPS instances, pair boot discipline with deployment hygiene. Symfony and Laravel stacks deployed via GitLab CI, as in our Symfony deployment on Ubuntu VPS walkthrough, still need working reboots after security patches. Schedule unattended-upgrades carefully and keep one known-good kernel in GRUB's menu.
Professional Linux system administration covers incident response when in-house teams lack live-USB experience. For hosting migrations — moving disks between providers — follow structured domain and hosting migration practices so UUID and network changes do not compound boot failures.
Key Takeaways
- Identify whether failure is firmware, GRUB, or kernel layer before running repair commands.
- Boot Repair from a live USB fixes most desktop dual-boot cases in one pass.
- Manual chroot with
grub-installandupdate-grubis the server-grade fallback. - UEFI repairs require ESP mount and
efibootmgr; Legacy repairs target the MBR disk. - Snapshot disks or create AMIs before major kernel upgrades on production Ubuntu hosts.
- Reinstall only when filesystem corruption or disk hardware failure makes repair pointless.
People Also Ask
Does Boot Repair delete my files?
No. Boot Repair modifies bootloaders, GRUB configuration, and EFI entries. It does not format root or home partitions. Still back up critical data before any disk-level work, because human error picking the wrong target disk can cause harm.
Can I fix GRUB without a live USB?
Only if you can reach a working GRUB menu or recovery mode. Press Esc or Shift at boot for GRUB. Choose Advanced options → recovery mode → root shell. If you see grub rescue> with no menu, you need external media.
Why does Ubuntu boot loop after a kernel update?
The new kernel may lack matching modules in initramfs, or Secure Boot rejects an unsigned build. Boot the previous kernel from GRUB's Advanced options, then reinstall linux-image-generic and run update-initramfs -u from a root shell.
How long does Ubuntu boot repair take?
Automated Boot Repair often finishes in five to fifteen minutes on a typical laptop. Manual chroot on encrypted RAID can take thirty to sixty minutes. Cloud volume attach workflows depend on provider snapshot APIs.
Recover confidently and document what you changed
This Ubuntu Boot Repair Guide gives you a decision path: diagnose the layer, pick Boot Repair or manual chroot, respect UEFI versus Legacy differences, and know when restore beats reinstall. Save partition maps and efibootmgr -v output after every successful fix. Future-you will thank present-you at 2 a.m.
Fresh installs and server builds benefit from a structured baseline — start with the Ubuntu server setup guide and the Ubuntu installation guide for beginners before production traffic arrives. If boot recovery is part of a wider infrastructure problem, contact us for hands-on Linux support on Nepali and international projects.
Frequently Asked Questions
0 Comments
Leave a comment
Your email is not published. Comments appear once they have been read. Sign in to have your details filled in.

