The following is a instruction about recovery of an damaged grub2 bootloader. it is not an explanation of why it occurred or a fix for the cause. Note that it assumes console access to the system.
* From the grub command shell start by using the set command to see the current boot environment, e.g.:
Among the output should be the device/partition with the root file system and the boot "prefix", the location of the boot loader on the boot device, e.g.:
Where the items with < and > symbols are just placeholders to describe the parameter but will actually vary based on system setup, such as:
* Verify the available devices and partitions using the ls command:
(hd0) (hd0,msdos1) (hd0,msdos3) (hd1,gpt1) (hd1,gpt5)
It's up to you to know which device and partition has the root file system. If you have a very large number of devices the list can be long enough to be confusing since no other details are shown.
* Set the boot loader location to the correct value using the prefix variable:
grub> set prefix=(hd0,msdos1)/boot
* Set the location of the root file system
grub> set root=(hd0,msdos1)
* Switch to the normal boot loader interface:
grub> insmod normal
* Load the kernel:
grub> linux /boot/vmlinuz
That file is usually a symlink, if the above has any failure then you can use the fully qualified kernel filename:
grub> linux /boot/vmlinuz-4.12.0-1-default
* Load the initial ramdisk:
grub> initrd /boot/initrd
That name is also usually a symlink to the real file and if you have any trouble you can use the fully qualified filename:
grub> initrd /boot/initrd-4.12.0-1-default
* If you need to load any device drivers you can use the insmod command with the driver name as an argument but, I prefer to make this boot simple, fix the bootloader then reboot to get what I'd consider a normal system
* boot the OS:
At that point the system should boot relatively normally and when the boot completes use one of the consoles to login as root then attempt to recover the bootloader by running the update-bootloader command:
myhost:/root # update-bootloader
When it completes, reboot the system and usually it will boot normally.
The part at the linux shell is all that's really needed, a previous run of it probably failed to complete successfully and left the system in the state where grub would show the grub command shell. So all the commands entered in it are just a manual replication of what update-bootloader should have configured to occur. Once you get to a linux shell then running update-bootloader a new will usually resolve grub.
There's much more to the grub command shell than what's described here. This is enough for recovery of a simple, single partition root file system that's not encrypted. There is decent documentation for the grub shell that can be used to extend the above to more complex root file systems, e.g. for grub 2.02:
=== FAQ ===
Q: A Kernel upgrade broke my tuned bootloader settings.
How can I edit them manually?
A: See below for an overview of bootloader related config files.
You can also set LOADER_TYPE="none" in /etc/sysconfig/bootloader to keep
the system from touching your individual boot config at all.
*** WARNING *** after a kernel upgrade you may need to update your boot
config manually (e.g. with lilo).
=== bootloader configuration files ===
= general config =
- contains bootloader type and is used by yast and perl-Bootloader
= grub2 =
/etc/default/grub_installdevice (x86 only)
- contains list of devices that grub2 is installed to (one per line)
- settings to control creation of grub.cfg; used by grub2-mkconfig
- main configuration file; is automatically created by running
"grub2-mkconfig -o /boot/grub2/grub.cfg"
- custom user configuration file, will automatically be
included in grub.cfg