Yet another GRUB guide

It should go without saying that there are a lot of guides to installing GRUB and fixing GRUB stuff for Linux users (not the least of which is the Arch Wiki. This article is a smaller, more focused article on the issues I have personally run into, and their solutions.

Which is usually just needing to re-install GRUB because I broke something.

Re-installing GRUB

The easy solution is to usually use something like Rescatux/Super Grub Disk, but they presently have a bug in their NVMe support. rEFInd is another good option, which doesn't have that problem. If you can use one of these options to just boot your existing config, then it quite simple to re-install GRUB from within the machine itself by running (as root):

# grub-install --uefi-secure-boot /dev/nvme0n1

Assuming nvme0n1 is your device. The secure boot option can be omitted if you aren't using secure boot.

Debian users can use the Debian install media, which has a dedicated re-install grub option. The only trick with this method is remembering which partition is the root. The Debian installer should recognize if you use a separate boot and/or EFI partitions and mount them accordingly. When asked where to install GRUB at the end of the steps, be sure to select the device for the drive itself (sda, nvme0n1 or whatever type your hardware uses).

But what if you have none of those available and just have some other Linux live environment? Then you would do the following:

  1. Open a terminal window in the Live environment (naturally)
  2. Mount your root partition. If you have a separate boot partition, mount that too.
  3. Change your current directory to where you mounted root (e.g. /mnt, probably)
  4. Modprobe EFI (if needed) and set up sys/efivarfs/proc/dev mounts:

    # modprobe efivarfs
    # mount -t sysfs sys sys
    # mount -t efivarfs efivarfs sys/firmware/efi/efivars
    # mount -t proc proc proc
    # mount /dev dev -o bind
  5. chroot into your setup:

    # chroot .
  6. Install grub

    # grub-install --uefi-secure-boot /dev/nvme0n1

As per above, omit the uefi-secure-boot option if you aren't using secure boot.

Booting from unconfigured GRUB

Sometimes you will boot, and end up with GRUB running, but no menu and just a GRUB recovery console. How can you end up properly booting from this state, you ask? Well, read on!

The first step is to use the ls command to figure out which drive is which, according to GRUB's conventions. Normal GRUB configuration files nowadays use UUIDs, but I assume you don't have them written down and/or don't want to type them by hand.

grub> ls
(proc) (hd0) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,gpt1)

Using ls on the partition itself will give you information on the partition instead of its contents:

grub> ls (hd0,gpt2)
        Partition hd0,gpt2: Filesystem type btrfs, UUID xxxxxxxx
- Partition start at ####Kib - Total size ####KiB

To see the contents, add a slash:

grub> ls (hd0,gpt2)/
dev/ run/ lib32 boot/ lib sbin srv/ media/ usr/ opt/ initrd.img vmlinuz lib64 bin home/ etc/
var/ tmp/ libx32 initrd.img.old sys/ mnt/ vmlinuz.old proc/ root/ snapshots/

Using existing config files

If the existing Grub configuration files are present and valid, just not being used, you can tell the GRUB recovery session to use them. The following examples are for root and boot on the same partition. If not, only the boot partition is important here.

First, locate your root or boot partition per above, and set the root and prefix variables:

grub> set root=(hd0,gpt2)
grub> set prefix=(hd0,gpt2)/boot/grub

Then load and run the normal module to bring up the menu:

grub> insmod normal
grub> normal

The above was written with help from a similar IBM developer works article.

Booting Linux directly

Referring to an existing GRUB configuration, the "normal" first steps would be to load any needed GRUB modules (e.g. insmod ext2), but this appears to be automatic when using the command-line. Therefore, you can get on with the core steps needed to boot Linux, after identifying the drive.

First, we set the root partition for the boot process. If you have a separate boot partition, you should specify that partition here.

grub> set root=(hd0,gpt2)

Next, specify the Linux kernel to boot, with command options. The partition specified here is the root partition, using normal Linux conventions. You can use ls or ls boot now to check options, or just tab complete the filename. The example below is for combined boot/root partition

grub> linux /boot/vmlinuz-4.19.0-13-amd64 root=/dev/nvme1n1p2

If you want to enable a serial console or set your video mode, you can add all sorts of fun things to the Linux kernel command. Finally, we load the initramfs and boot:

grub> initrd  /boot/initrd.img-4.19.0-13-amd64
grub> boot

The above was written with help from a similar Ubuntu Buzz article.

"Removable" GRUB

Most distros will install GRUB as a specific entry in the UEFI boot list stored in NVRAM. However, I have lost my boot list doing various things, so it is also useful to install GRUB using the "removable" style of booting, which has a dedicated filename and path that UEFI firmware will always be able to locate. It can be accomplished as follows, assuming install to nvme0n1 with secure boot enabled:

# grub-install --removable --no-nvram --uefi-secure-boot /dev/nvme0n1

Help, GRUB just won't install!

Sometimes, your EFI storage can be full if your Kernel is configured to store memory/debugging dumps in your EFI NVRAM. Mount efivarfs if it is not already mounted:

# modprobe efivarfs
# mount efivarfs /sys/firmware/efi/efivars

Then check the contents of /sys/firmware/efi/efivars to see if there are a large number of abnormal 'dump' files present there. If so, delete them! Then try to install GRUB again.

Reference for my setup

This is useless to anyone not me, but it's useful to have this sort of information recorded. As such, here are the important partitions for the above processes on my current partition layout.

nvme0n1p2     259:2    0    99M  0 part  /boot/efi
nvme0n1p3     259:3    0   450M  0 part  /boot
nvme0n1p5     259:4    0  93.1G  0 part  /

I suggest other users make similar notes, though you can figure this out (eventually) by mounting partitions in a live environment and checking their contents. Or by liberal use of 'ls' in a GRUB recovery console. It can be slightly more difficult determining exactly which GRUB drive number matches the sda/sdb or nvme0n1/nvme1n1 Linux convention, however.

PS: It's less common now to have a dedicated boot partition. I only have one because I deleted Windows and needed to use the free space from the "System Partition" for something.


There are no comments yet.

Add a Comment
Comment Atom Feed