Dev Ups

Published 2023-08-11 in grub

Providing grub to an unbootable linux

I like to put different OSs on different disks. About a decade ago, I observed Windows render a Linux partition unbootable. It probably only affected the boot sector, or partition. While critical, these are usually fairly generic, and recoverable. Using what I'll demonstrate here, I would have been able to recover within hours.

The situation today is I installed Linux onto its own disk, but accidentally put grub on the Windows disk, which, for total isolation I didn't want powered whilst running the other.

I already recovered my original Windows Boot Manager, but that has left Linux without a working boot sector.

Repairing Linux

Fixing the Linux disk required resizing which took about 8 minutes to shift 70 GB forward:

Shifting existing 70GB Linux installation right by 512MB for EFI partition

I made the 512 MB efi partition in gparted, then set the esp flag (which set the boot flag for me) as a separate operation.

Managing flags in gparted

I was in the Live environment of my installation media, so I gave it the chance to save its creation.

Ubuntu installation types available from the live environment

Here the options for "install now", from the live environment, were as limited as those I got when Windows was the only OS installed. Apart from Something else, the best option seems to be to install alongside, and choose, via unspecified software which will invariably be grub, which OS to boot each time.


The live media contained no rescue kit. I had to install Boot-Repair using:

sudo add-apt-repository ppa:yannubuntu/boot-repair && sudo apt update
sudo apt install -y boot-repair && boot-repair

I'd hesitate to use a PPA here due to the potential to inject a rootkit, but Ubuntu themselves link their docs to boot-repair. Boot-repair's rumoured to be open source, but the repositories I found on launchpad and github were last modified in October 2012, 11 years ago.

Boot-repair landing screen

I chose "advanced options", explicit being better than implicit.

Boot-repair advanced options

Immediately I can see this is the right tool. In "grub location" it picked up the newly gparted partition as the "/boot/efi" one. Could it be mistaken? No, the ESP flag we set within gparted initialised this for us.

Curiosity got the better of me. I'd skim read several reports of Ubuntu not needing the second, that is, the EFI, partition. Perhaps I should have let grub install to sda1 as it was, prior to resizing it?

BootInfo summary

The text report generated is insightful. The first rows look profound, but I am unsure on what they are based. Below, the report quotes the outputs of various shell commands. The analysis of grub is interesting:

====================== sda1/boot/grub/grub.cfg (filtered) ======================

Ubuntu   <<UUID1>>
Ubuntu, with Linux 5.19.0-46-generic   <<UUID1>>
Ubuntu, with Linux 5.19.0-32-generic   <<UUID1>>
Windows Boot Manager (on sdd1)   osprober-efi-<<UUID2>>
### END /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_uefi-firmware ###

========================== sda1/etc/fstab (filtered) ===========================

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=<<UUID1>> /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sdd1 during installation
UUID=<<UUID2>>  /boot/efi       vfat    umask=0077      0       1

At the top is the Boot Info Summary, its very first row states:

=> Windows 7/8/10/11/2012 is installed in the MBR of /dev/sda.

What in the world? It's clearly Ubuntu as it states literally everywhere other than this line. Windows was /dev/sdd when grub got installed. Ubuntu was, and is, /dev/sda1.

It's odd that sda1/boot/grub/grub.cfg contains an entry for Windows. I receive an unbootable message attempting to boot from this disk (<<UUID11>>). The Windows disk at least gets to grub, albeit no further without "obscure" command line interaction. Hence, my willingness to create a new boot partition. I can just leave that partition unpopulated to let the rescue do its thing.

BootInfo's suggested repair was:

reinstall the grub-efi of sda1, using the following options: sda2/boot/efi

Repartitioning and automated repairs

I was going to let it run, but for the EFI parition I created. (Hmm, they did just call partition out, sda2/boot/efi, which I ignored). I removed that in gparted, again, this involved copying 70 GB. This failed citing the partition was mounted. I didn't think it was. I stopped the boot-repair and gparted could proceed.

After 10 minutes gparted was complete. I consulted boot-repair again:

GPT detected by boot-repair

GPT detected. Please create a BIOS-Boot partition (>1MB, unformatted filesystem, bios_grub flag). This can be performed via tools such as Gparted. Then try again.

That was exactly what I just removed!

Here the boot partition is back, as 550MB this time.

I reinstated sda2, as an empty, unformatted partition. All was well. Well, actually, I got an error about NVRAM from boot-repair, but it still booted just fine after that.

Locked-NVRAM detected by boot-repair

Something else

Before rebooting, while I had the live system up, I went through the motions of a dry run installation. I observed that the "something else", installation type does have an option, beneath the list of partitions, choosing where we want to install grub. I must have been installing one-handed, without a mouse, whilst doing something else to have missed that!

The "something else", type of ubuntu installation displaying the box to change the grub installation location

If you're interested to learn more about bootloaders I wrote On Modern Bootloaders while investigating the fixes above.