Repairing GRUB and fixing boot issues on elementary OS
elementary OS is one of those distributions that quietly does its job in the background, which is exactly why it feels so jarring when the machine refuses to boot. Instead of the familiar Pantheon desktop, the screen shows "minimal BASH-like line editing is supported" or, worse, just a blinking cursor. Most of the time the underlying Linux system is still perfectly fine; what has failed is GRUB, the bootloader that hands control from the firmware to the kernel.
In Australia, where a lot of people pick up hardware from MSY, JB Hi-Fi, or PCCaseGear and assemble their own rigs, bootloader trouble tends to show up after a Windows update, a partition resize, or a swap to a fresh NVMe drive. The fix is rarely a full reinstall. With a live USB and a handful of terminal commands you can put GRUB back in place and be back at the desktop before the kettle boils.
This guide covers how GRUB actually fits into the elementary OS boot chain, how to build a recovery USB, what to try before touching the bootloader, and the chroot workflow that restores it. The intended reader is anyone comfortable opening a terminal, whether sitting in a Melbourne share house at 11pm AEST or troubleshooting a server room in Perth.
How GRUB fits into the elementary OS boot chain
When you press the power button, the machine's firmware (the legacy BIOS or the far more common UEFI) runs a small program stored on a special partition. On most elementary OS installs that program is GRUB, which then loads the Linux kernel and initramfs from the /boot directory, hands over control, and the rest of the system comes up through systemd.
If that handoff goes wrong, the firmware either cannot find anything to run, or it hands control to a bootloader that has been partly overwritten. The symptoms vary: a black screen, the words "GRUB Rescue>", the more cryptic "no such partition", or the Windows-style "No bootable device" on a UEFI box. Each error points to a slightly different cause, but the remedy is similar in spirit.
UEFI and legacy BIOS installs look different under the bonnet. A legacy install uses the first 440 bytes of the Master Boot Record and points to GRUB files in /boot/grub. A UEFI install uses a small FAT32 partition, usually mounted at /boot/efi, that holds the GRUB EFI binary and a config file. Most elementary OS machines shipped in the last decade boot in UEFI mode, and that is the path this guide focuses on, with legacy notes where they matter.
Building a recovery USB before things go wrong
The single best thing any elementary OS user can do is keep a live USB on hand. Most people only think about it when the laptop refuses to boot, by which time the NBN upload speed is throttled to a trickle and the CGNAT on a typical Telstra or Aussie Broadband connection makes it awkward to download a fresh ISO from a mate's house. Sort the USB out on a quiet Sunday arvo and stash it in a drawer.
The elementary OS website offers a current ISO. Write it to a USB stick with balenaEtcher, Popsicle (which is bundled with elementary OS itself), or Ventoy if you want to keep multiple tools on one drive. Ventoy is popular with Australian Linux enthusiasts who often run a half-dozen distros for testing; it lets you drop ISO files onto a normal exFAT stick and pick one from a menu at boot.
Whichever tool you pick, verify the checksum. A corrupted ISO is a surprisingly common cause of mysterious boot failures later on, and the failure is almost impossible to diagnose after the fact. Once the stick is built, pop it into the troublesome machine, mash the boot menu key (F12 on most Lenovo and HP laptops sold through JB Hi-Fi, F2 on many Acer models), and confirm you can reach the live desktop. If that works, you have a working rescue environment.
Quick fixes that solve most boot problems
Before reaching for the chroot toolkit, run through a short checklist. A surprising share of "broken GRUB" cases turn out to be something much simpler, and skipping these steps leads people to overwrite a perfectly good bootloader.
First, check the boot order inside the firmware setup. A Windows update occasionally reorders UEFI entries, especially after a feature update on a dual-boot laptop. Open the firmware, find the boot priority, and put "elementary" or "ubuntu" (the bootloader is signed that way) above Windows Boot Manager. Save and reboot before doing anything destructive.
Second, confirm the disk is still detected. NVMe sockets can work loose after a drop or after years of thermal cycling, and Australian summers can push SSD temperatures into the seventies. Open the case, press the drive home, and check the SATA or NVMe cable. If the drive has vanished entirely, no amount of GRUB repair will bring it back.
Third, try the fallback path. Many UEFI firmwares keep a secondary boot entry, often labelled "ubuntu" or simply "EFI Default". Selecting it from the firmware boot menu sometimes loads a working GRUB when the main entry has been clobbered. If that one boots, run sudo update-grub once you reach the desktop and the problem is solved without any further fuss.
Mounting your broken install from a live session
When the easy fixes are out of the way, the next move is to boot the live USB, identify the installed system's partitions, and mount them so you can poke at its files. Elementary OS's Calamares installer normally creates a small EFI partition (around 512 MB, FAT32), a root partition (ext4 or btrfs), and optionally a swap partition. Listing them is straightforward.
Open a terminal in the live session and run sudo lsblk -f. The output shows every block device with its filesystem label and UUID. The EFI partition will almost always be the FAT32 one of about 500 MB; the root partition is the larger ext4 or btrfs volume with the bulk of the disk space. If you see LUKS encryption in the column, unlock it first with sudo cryptsetup open /dev/sdXn cryptroot and feed it your passphrase.
Mount the root partition first, then the EFI partition on top of its mount point inside the root. The usual incantation looks like sudo mount /dev/sda2 /mnt followed by sudo mount /dev/sda1 /mnt/boot/efi. If you also have a separate /boot partition, mount that too. Once everything is in place, sudo ls /mnt should show the familiar elementary OS directory tree, and you are ready for the real repair.
Repairing GRUB from a chroot environment
Chrooting changes the apparent root of the running system to your mounted install, so commands like grub-install and update-grub see your real files instead of the live USB's. It is the cleanest way to repair a bootloader without booting the broken system itself.
Bind the virtual filesystems the kernel expects, then chroot in. The canonical sequence is:
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo cp /mnt/etc/resolv.conf /etc/resolv.conf
sudo chroot /mnt
Inside the chroot, run sudo grub-install /dev/sda for legacy installs or sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=elementary on UEFI machines. Adjust the device name if your disk is on NVMe (/dev/nvme0n1) or a RAID array. After the install completes, run sudo update-grub to regenerate the menu; os-prober will pick up any Windows install sitting alongside.
Exit, unmount in reverse order, and reboot. Most of the time you land straight at the Pantheon greeter.
Working around UEFI and Secure Boot quirks
UEFI firmware is meant to make life easier, but every Australian hardware vendor ships their own quirks. Lenovo machines sold through the local channel sometimes have a "Boot Order Lock" that hides anything that is not Windows by default. HP's UEFI on business-grade laptops expects the bootloader to be signed with a specific key. Acer's firmware occasionally drops custom boot entries after a firmware update.
If GRUB installs cleanly but the firmware ignores it, use sudo efibootmgr -v inside the chroot to list the existing UEFI entries. You can create or reorder entries with efibootmgr --create. For Secure Boot, the shipped elementary OS shim is signed by Microsoft and accepted by default on most modern firmware, so leaving Secure Boot on is usually fine. If you disabled it once to install a niche driver, leave it disabled consistently; toggling it after a repair often confuses the firmware into forgetting the boot entry.
One more local wrinkle: firmware updates on consumer laptops often arrive through Windows Update rather than the UEFI itself. If you have wiped Windows in favour of a clean elementary OS install, your machine may be sitting on a year-old firmware with known bugs. Check the vendor's Australian support site for a bootable firmware ISO, or boot a Windows PE USB once a year to apply updates.
Keeping your bootloader healthy over time
A working GRUB is easy to take for granted and easy to forget about until it breaks. A few habits keep it that way.
Keep a separate /boot partition if you use full-disk encryption or btrfs subvolumes with snapshots. Snapshots in particular can confuse os-prober and leave dangling entries in /boot/grub/grub.cfg; running sudo update-grub after major changes keeps the menu honest. If you dual-boot, run update-grub after every Windows feature update, because Windows occasionally rewrites its own boot entry in a way that pushes GRUB down the priority list.
Back up the EFI partition. It is only a few hundred megabytes, and a tarball of /boot/efi/EFI stored on a USB drive can save an entire afternoon when a repair goes sideways. Pair that with a copy of /etc/default/grub and the output of sudo efibootmgr -v, and you have everything needed to recreate the boot setup on a fresh disk.
Finally, label your recovery USB clearly and store it somewhere you can find at 2am AEST after a power blip has corrupted your boot config. A working live stick with a current elementary OS ISO is the single most useful troubleshooting tool you can keep on hand, and labelling it means you do not waste half an hour digging through a drawer at an ungodly hour.
Before any of this becomes urgent, take ten minutes to back up the EFI partition and capture the output of efibootmgr -v onto a labelled USB stick; that tarball turns the worst-case bootloader failure into a thirty-minute job rather than a weekend reinstall.
