Fixing GRUB

Just a few days ago I had installed the new version of Mint on a second partition. The installation succeeded, so everything’s good, right? Well, no. Because unfortunately, this installation somehow screwed up the GRUB configuration, leading to GRUB both not being able to boot into the new installation, as well as removing all other entries. This lead to quite a bit of headache and work trying to fix it. So if this has happened to you, how do you fix it?

Booting into a system

The first step in recovering your system, is booting into your operating system. For this you have two options. Option one, is to just take a live-bootable CD or USB-Drive, and boot into that instead. Alternatively, you can try to boot into your already existing OS and go from there. I chose that route and can therefore vouch for it and will demonstrate how to use it. However, I’m guessing that the other way will work too, especially if you’re uncomfortable with the command-line interface of GRUB.

So to start with, you will need to know on which partition your operating system is, which I will assume you already know. If you do not, I recommend using a live-bootable CD for this step, or if you really need your system, use it to just figure out which partition it is on. However, GRUB does not use the Linux style /dev/sda1 naming scheme. It uses a scheme, that looks like this: (hd0,msdos1). This may seem weird and opaque, but converting to it is really rather simple. For the drive identifier, instead of sd you have hd, instead of letters you have the numbers starting from 0. So /dev/sde would be hd4. Now to the slightly odd part: the partition number. You can just reuse the number part, but you also need to specify the partitioning system, meaning gpt or msdos or something else. If you’re uncertain about which one your drive is using, helpfully, typing ls will list all of the partitions in the way that GRUB expects them to be named.

Now that we know the drive and partition number, it’s time to get started on the actual booting. We’ll just set the root in GRUB to be the partition that we’re trying to boot into, to make everything easier on us, with the command set root=(hd0,msdos1), obviously using your partition identifier. Note: this doesn’t set root for Linux, that will be done next. Now we select the Linux kernel which is chosen. This is usually found under /boot/vmlinuz, sometimes followed with a dash and the version number. We select the correct Kernel and root file system as follows: linux /boot/vmlinuz root=/dev/sda1. Following that, we select the correct initrd, with the same version number – or lack thereof – with initrd /boot/initrd.img. Now that everything is selected correctly, we just use boot to boot into our system, and are done.

set root=(hd0,msdos1)
linux /boot/vmlinuz root=/dev/sda1
initrd /boot/initrd.img

For this part, I found this article: to be very helpful. If you run into issues or are in GRUB rescue, refer to this.

Fixing the issue – permanently

To actually solve the problem, we need to fix the GRUB configuration file. This process is unclear to me, so I will just tell you what worked on my UEFI machine, and if that doesn’t work for you or your machine isn’t UEFI, I recommend this guide: from redhat. The first step is to run the update-grub tool, which according to most guides should already do the trick. So reboot your system and see if it worked. If it didn’t, get back into your system and do the following. Make sure the system EFI partition is mounted, probably on /boot/efi/. If it isn’t, mount it there. Now you should find to directories in /boot/efi/EFI/, one BOOT and one other one, for example ubuntu. Go into the second one, and here you will find the GRUB configuration file, grub.cfg. Run the output from update-grub into that file, by running update-grub -o grub.cfg. Now reboot, and it should work.

update-grub -o /boot/efi/EFI/ubuntu/grub.cfg
This entry was posted in Command line and tagged , , , , , . Bookmark the permalink.