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.
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 (
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:
- Open a terminal window in the Live environment (naturally)
- Mount your root partition. If you have a separate boot partition, mount that too.
- Change your current directory to where you mounted root (e.g.
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
chroot into your setup:
# chroot .
# 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 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.
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.