Ubuntu Boot Repair Guide

By Khimananda Oli | Last reviewed: August 2026

A server that fails to boot is a production emergency, whether it is a critical AWS EC2 instance or a local VPS hosting client applications. This Ubuntu Boot Repair Guide gives you the exact diagnostic workflow and recovery commands needed to restore access without reinstalling the operating system. Before attempting risky filesystem operations, review the principles of safe recovery outlined in my article on rolling back failed deployments safely, as the same caution applies to low-level boot repairs.

How do I diagnose why Ubuntu won't boot?

Before typing any repair commands, you must identify where the boot sequence failed. Modern Ubuntu systems (22.04 LTS through 24.04 LTS) use a multi-stage process involving firmware, the bootloader (GRUB or systemd-boot), the kernel, and userspace init. Understanding this flow prevents wasted time fixing the wrong component.

If the system powers on but shows no output, check firmware settings first. Secure Boot can reject unsigned kernels after manual updates. If you see the GRUB menu but the kernel panics immediately, the issue is likely a corrupted initramfs or mismatched kernel modules. If the kernel loads but drops to an emergency shell, the problem usually lies in /etc/fstab or filesystem corruption. Use the UEFI firmware diagnostics or the GRUB command line (c key) to inspect available partitions and verify paths before proceeding to chroot-based repairs.

How do I use chroot to fix GRUB on Ubuntu?

The chroot method is the cornerstone of any serious Ubuntu Boot Repair Guide workflow. It allows you to run commands against your broken installation as if you had booted into it normally. This is essential when the bootloader is missing, overwritten by Windows, or pointing to the wrong UUID.

Mounting the target system correctly

Boot from an Ubuntu Live USB matching your installed version. Open a terminal and identify your root partition and EFI System Partition (ESP) using lsblk -f. Mount them precisely:

sudo mount /dev/sda2 /mnt
sudo mount /dev/sda1 /mnt/boot/efi
sudo mount --rbind /dev /mnt/dev
sudo mount --make-rslave /mnt/dev
sudo mount --rbind /sys /mnt/sys
sudo mount --make-rslave /mnt/sys
sudo mount --rbind /proc /mnt/proc
sudo mount --make-rslave /mnt/proc

The --rbind and --make-rslave flags are non-negotiable on modern systemd systems. They ensure device nodes and cgroups propagate correctly into the chroot environment. Skipping these often causes grub-install to fail silently or produce a non-functional configuration.

Reinstalling GRUB from within chroot

Enter the chroot environment and reinstall the bootloader:

sudo chroot /mnt /bin/bash
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu
update-grub
exit

For legacy BIOS systems, replace the target with i386-pc and omit the EFI directory flag. After exiting, unmount everything in reverse order with sudo umount -R /mnt before rebooting. This procedure resolves the majority of "no bootable device" errors on Ubuntu 22.04 and 24.04.

What if update-grub fails or doesn't detect my OS?

A common frustration in boot repair is running update-grub only to have it ignore your installed kernel or other operating systems. This typically happens because the chroot environment lacks proper access to device metadata or because os-prober is disabled.

• Enable os-prober: On Ubuntu 22.04+, os-prober is disabled by default for security. Edit /etc/default/grub inside chroot and add GRUB_DISABLE_OS_PROBER=false, then re-run update-grub.
• Verify kernel presence: Run ls /boot/vmlinuz* inside chroot. If no kernels exist, install one: apt install --reinstall linux-image-generic.
• Check EFI variables: Outside chroot, run efibootmgr -v. If the ubuntu entry is missing, create it: efibootmgr --create --disk /dev/sda --part 1 --label "ubuntu" --loader '\EFI\ubuntu\grubx64.efi'.
• Regenerate initramfs: Corrupted init images cause silent boot failures. Inside chroot, run update-initramfs -u -k all to rebuild for all installed kernels.

If GRUB still misbehaves, consider switching to systemd-boot for simpler EFI management, especially on servers where dual-boot detection is unnecessary. See my comparison in web server performance trade-offs for similar decision frameworks between competing technologies.

How do I recover from emergency mode and fstab errors?

Dropping into emergency mode usually means systemd could not mount a filesystem listed in /etc/fstab. This is extremely common after disk migrations, UUID changes during cloning, or accidental edits. The system is actually functional—you just need to fix the mount table.

At the emergency prompt, log in as root. Remount the root filesystem as writable:

mount -o remount,rw /

Then inspect /etc/fstab and compare entries against actual block devices:

cat /etc/fstab
blkid

Comment out any lines referencing missing UUIDs or incorrect device paths. Save the file and run systemctl daemon-reload followed by mount -a to test. If mounts succeed, reboot. For production servers, always validate fstab changes with findmnt --verify --tab-file /etc/fstab before committing—a practice aligned with infrastructure validation patterns discussed in CI build verification gates.

When should I use Boot-Repair vs manual chroot?

The graphical Boot-Repair tool is popular in tutorials, but experienced engineers should understand its limitations compared to manual intervention. Here is a practical comparison for 2026 environments:

In my experience managing SOC 2 compliant infrastructure, manual chroot is mandatory. Automated tools modify configurations without explicit approval, creating audit gaps. For Nepali businesses running critical services on limited hardware budgets, understanding manual repair avoids costly support tickets or unnecessary reinstalls. If you manage multiple servers, consider documenting your specific recovery runbooks alongside your incident response procedures to reduce mean time to recovery.

How do I prevent future Ubuntu boot failures?

Recovery is reactive; prevention is professional. After restoring your system using this Ubuntu Boot Repair Guide, implement these safeguards immediately:

1. Pin known-good kernels: Configure apt-mark hold linux-image-* on stable versions before upgrades. Test new kernels in staging first.
2. Backup ESP and bootloader config: Copy /boot/efi/EFI/ubuntu/ and /etc/default/grub to version-controlled storage. These files are small but critical.
3. Enable serial console access: Add console=ttyS0,115200 to GRUB_CMDLINE_LINUX_DEFAULT. Cloud VMs and headless servers become unrecoverable without it.
4. Test recovery quarterly: Simulate boot failures in non-production environments. Verify your team can execute chroot repairs under pressure.
5. Monitor boot metrics: Track systemd-analyze blame output over time. Sudden increases in init time often precede catastrophic failures.

Boot resilience is not optional for production systems. Whether you operate infrastructure in Kathmandu or globally, treating boot repair as a documented, tested capability—not an ad-hoc crisis response—separates reliable operations from fragile ones. If your team needs help establishing audit-ready recovery procedures or hardening Linux infrastructure against boot-time failures, reach out to discuss your specific environment.