Repairing Grub with a rescue CD
Boot a Linux rescue CD, for instance Mariposa Rescue Disk, preferably using Ventoy.
Reparing a damaged Grub boot loader is quite easy. It is very well explained here: https://www.system-rescue.org/disk-partitioning/Repairing-a-damaged-Grub/. I recommend to have a copy of that page with you if the need for troubleshooting is likely.
However, there are some pitfalls that you might encounter. Therefore, we are going through the basic procedure here and also explain some troubleshooting procedure that might be necessary.
Check your partition table
First check your partition table in order to be sure that you repair the correct partition when you install Grub back onto the hard disk:
rescue@mariposa:~$ sudo fsarchiver probe simple
[======DISK======] [=============NAME==============] [====SIZE====] [MAJ] [MIN]
[sda ] [Samsung SSD 870 ] [ 465.76 GB] [ 8] [ 0]
[sdb ] [Samsung SSD 850 ] [ 232.89 GB] [ 8] [ 16]
[sdc ] [Samsung SSD 870 ] [ 931.51 GB] [ 8] [ 32]
[sdd ] [DataTraveler 3.0 ] [ 57.75 GB] [ 8] [ 48]
[sde ] [DT 101 G2 ] [ 14.64 GB] [ 8] [ 64]
[=====DEVICE=====] [==FILESYS==] [======LABEL======] [====SIZE====] [MAJ] [MIN]
[loop0 ] [squashfs ] [<unknown> ] [ 1.15 GB] [ 7] [ 0]
[sda1 ] [ext2 ] [<unknown> ] [ 487.00 MB] [ 8] [ 1]
[sda5 ] [crypto_LUKS] [<unknown> ] [ 465.28 GB] [ 8] [ 5]
[sdb1 ] [ntfs ] [System Reserved ] [ 50.00 MB] [ 8] [ 17]
[sdb2 ] [ntfs ] [<unknown> ] [ 116.63 GB] [ 8] [ 18]
[sdb3 ] [ntfs ] [<unknown> ] [ 517.00 MB] [ 8] [ 19]
[sdb4 ] [BitLocker ] [<unknown> ] [ 115.70 GB] [ 8] [ 20]
[sdc1 ] [<unknown> ] [<unknown> ] [ 15.98 MB] [ 8] [ 33]
[sdc2 ] [ntfs ] [data2 ] [ 931.50 GB] [ 8] [ 34]
[sdd1 ] [exfat ] [Ventoy ] [ 57.72 GB] [ 8] [ 49]
[sdd2 ] [iso9660 ] [Mariposa ] [ 1.25 GB] [254] [ 0]
[dm-0 ] [iso9660 ] [Mariposa ] [ 1.25 GB] [254] [ 0]
rescue@mariposa:~$
To get an even more detailed overview proceed as follows:
rescue@mariposa:~$ sudo fsarchiver probe detailed
[======DISK======] [=============NAME==============] [====SIZE====] [MAJ] [MIN]
[sda ] [Samsung SSD 870 ] [ 465.76 GB] [ 8] [ 0]
[sdb ] [Samsung SSD 850 ] [ 232.89 GB] [ 8] [ 16]
[sdc ] [Samsung SSD 870 ] [ 931.51 GB] [ 8] [ 32]
[sdd ] [DataTraveler 3.0 ] [ 57.75 GB] [ 8] [ 48]
[sde ] [DT 101 G2 ] [ 14.64 GB] [ 8] [ 64]
[=====DEVICE=====] [==FILESYS==] [======LABEL======] [====SIZE====] [MAJ] [MIN] [==============LONGNAME==============] [=================UUID=================]
[loop0 ] [squashfs ] [<unknown> ] [ 1.15 GB] [ 7] [ 0] [/dev/loop0 ] [<unknown> ]
[sda1 ] [ext2 ] [<unknown> ] [ 487.00 MB] [ 8] [ 1] [/dev/sda1 ] [f8280c80-bb13-46dc-8aef-846241960a45 ]
[sda5 ] [crypto_LUKS] [<unknown> ] [ 465.28 GB] [ 8] [ 5] [/dev/sda5 ] [6db4e532-3bac-4200-ab7c-2a3ac1c52a3b ]
[sdb1 ] [ntfs ] [System Reserved ] [ 50.00 MB] [ 8] [ 17] [/dev/sdb1 ] [FA4E940B4E93BEB7 ]
[sdb2 ] [ntfs ] [<unknown> ] [ 116.63 GB] [ 8] [ 18] [/dev/sdb2 ] [C61EBB731EBB5ADF ]
[sdb3 ] [ntfs ] [<unknown> ] [ 517.00 MB] [ 8] [ 19] [/dev/sdb3 ] [CC8852B388529BB0 ]
[sdb4 ] [BitLocker ] [<unknown> ] [ 115.70 GB] [ 8] [ 20] [/dev/sdb4 ] [<unknown> ]
[sdc1 ] [<unknown> ] [<unknown> ] [ 15.98 MB] [ 8] [ 33] [/dev/sdc1 ] [<unknown> ]
[sdc2 ] [ntfs ] [data2 ] [ 931.50 GB] [ 8] [ 34] [/dev/sdc2 ] [40CCADF0CCADE100 ]
[sdd1 ] [exfat ] [Ventoy ] [ 57.72 GB] [ 8] [ 49] [/dev/sdd1 ] [4E21-0000 ]
[sdd2 ] [iso9660 ] [Mariposa ] [ 1.25 GB] [254] [ 0] [/dev/sdd2 ] [2024-04-19-16-08-36-00 ]
[dm-0 ] [iso9660 ] [Mariposa ] [ 1.25 GB] [254] [ 0] [/dev/dm-0 ] [2024-04-19-16-08-36-00 ]
rescue@mariposa:~$
To get some information about sectors, you can also use the following command on the terminal:
sudo fdisk -lu
rescue@mariposa:~$ sudo fdisk -lu
Disk /dev/loop0: 342.9 MiB, 359522304 bytes, 702192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: [ ]
Device Start End Sectors Size Type
/dev/sda1 102402048 122882047 20480000 9.8G BIOS boot
/dev/sda2 122882048 234436511 111554464 53.2G Linux root (x86)
/dev/sda3 2048 18431 16384 8M Linux filesystem
/dev/sda4 18432 102402047 102383616 48.8G Linux root (x86)
Partition table entries are not in disk order.
Disk /dev/sdc: 7.2 GiB, 7767851008 bytes, 15171584 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: [ ]
Device Boot Start End Sectors Size Id Type
/dev/sdc1 3224498923 3657370039 432871117 206.4G 7 HPFS/NTFS/exFAT
/dev/sdc2 3272020941 5225480974 1953460034 931.5G 16 Hidden FAT16
/dev/sdc3 0 0 0 0B 6f unknown
/dev/sdc4 50200576 974536369 924335794 440.8G 0 Empty
Partition table entries are not in disk order.
rescue@mariposa:~$
Repair the damaged Grub boot loader
rescue@mariposa:~$ sudo mkdir /mnt/linux
Pitfall 1:
Should you forget to mount the necessary directories from the hard disk, you will get an error message as follows:
rescue@mariposa:~$ sudo grub-install /dev/sda
Installing for i386-pc platform.
grub-install: error: failed to get canonical path of `airootfs'.
The "airootfs" is the root file system of the live directory from which we have booted. However, what we wanted to do was to install grub on the hard disk.
Note that this does not apply if you booted directly into the OS on the hard disk, for instance using Supergrub2, as explained in the article "Using SuperGrub2".
Before you proceed, you have to mount the necessary directories from the hard disk to your live boot system before you can start recovering Grub.
rescue@mariposa:~$ sudo mount -r /dev/sda2 /mnt/linux
Just in case, check the init directory:
rescue@mariposa:~$ ls -l /mnt/linux/sbin/init
In case there is no extra boot partition, the output would be as follows:
rescue@mariposa:~$ ls -l /mnt/linux/boot
total 216832
-rw-r--r-- 1 root root 206143 Oct 18 2020 config-4.19.0-12-amd64
-rw-r--r-- 1 root root 206242 Jan 30 09:35 config-4.19.0-14-amd64
-rw-r--r-- 1 root root 206242 Mar 19 14:29 config-4.19.0-16-amd64
drwxr-xr-x 5 root root 4096 Mar 31 07:20 grub
-rw-r--r-- 1 root root 64899669 Feb 15 13:30 initrd.img-4.19.0-12-amd64
-rw-r--r-- 1 root root 65001483 Feb 17 14:17 initrd.img-4.19.0-14-amd64
-rw-r--r-- 1 root root 65012997 Mar 31 07:21 initrd.img-4.19.0-16-amd64
-rw-r--r-- 1 root root 182704 Jun 25 2015 memtest86+.bin
-rw-r--r-- 1 root root 184840 Jun 25 2015 memtest86+_multiboot.bin
-rw-r--r-- 1 root root 3415048 Oct 18 2020 System.map-4.19.0-12-amd64
-rw-r--r-- 1 root root 3420599 Jan 30 09:35 System.map-4.19.0-14-amd64
-rw-r--r-- 1 root root 3421023 Mar 19 14:29 System.map-4.19.0-16-amd64
-rw-r--r-- 1 root root 5278960 Oct 18 2020 vmlinuz-4.19.0-12-amd64
-rw-r--r-- 1 root root 5278960 Jan 30 09:35 vmlinuz-4.19.0-14-amd64
-rw-r--r-- 1 root root 5287168 Mar 19 14:29 vmlinuz-4.19.0-16-amd64
rescue@mariposa:~$
Now you have to mount the relevant directories from the live file system to the relevant directories on the hard disk, mounted to the live file system:
rescue@mariposa:~$ sudo mount -o bind /proc /mnt/linux/proc
rescue@mariposa:~$ sudo mount -o bind /dev /mnt/linux/dev
rescue@mariposa:~$ sudo mount -o bind /sys /mnt/linux/sys
Case: the boot directory is an extra partition
In this case you have to mount the extra partition to the boot directory of the mount point.
rescue@mariposa:~$ sudo mount /dev/sda1 /mnt/linux/boot
Do not forget to tell your OS that root shall now refer to the OS on the hard disk that you just mounted:
rescue@mariposa:~$ sudo chroot /mnt/linux /bin/bash
Make sure that the root file system is writable:
rescue@mariposa:~$ sudo mount -o remount,rw /
Now you can install Grub back to the hard disk:
rescue@mariposa:~$ sudo grub-install /dev/sda
Pitfall 2:
SytemrescueCD "supposes" that the boot directory is an extra partition, but it is not.
rescue@mariposa:~$ sudo grub-install /dev/sda
Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists.
rescue@mariposa:/#
In this case you have to change the label type from boot to bios_grub. In order to do so, you can use the application parted:
rescue@mariposa:~$ sudo parted /dev/sda
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) set 1 boot off
(parted) set 1 bios_grub on
(parted) q
Now you can install Grub on the hard disk:
$ sudo grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.
Once you are done, restart. In case you still did not succeed, check more Grub repair tools on "Linux Boot repair tools".
Error message "Kernel Panic - not syncing"
Should you get a message saying that Linux is unable to mount the root filesystem, it means that you are missing the initramfs for your kernel. The initramfs (initial ram file system) is the root filesystem image which is needed to start the system.
Make sure that the root file system is writable:
mount -o remount,rw /
Now what you need is the update-initramfs script which manages your initramfs images on your local system:
update-initramfs -u -k 5.15.0-76-generic or your version.
If you don't know your kernel version, execute the following command:
dpkg --list | grep linux-image
Otherwise you find it in the /boot folder.
Now install grub:
rescue@mariposa:~$ sudo grub-install /dev/sda
Check "Boot repair tools on Linux" for some of the most relevant boot repair tools on Linux.
Check for more Linux related articles.