Server support blog

You’ve decided to reboot your Linux Desktop (or remote server) and instead of getting to running system you were greeted by something like this

Why did it happen and where to go from here?

Now I can not possibly offer you “cure for all illnesses” here. I can think of about 10 different reasons why your boot process will end up in GRUB shell.
What I want to review is the particular situation that can end up like this and possible ways out of it.
What we will need is the ability to boot from recovery CD (for CentOS installation CD preferrable, for other distros – rescue media they provide) and access to the console – for the remote server that could be IP-KVM or iLO/IPMI management card, for local PC – attached display/keyboard. Knowledge of the name of root device would be also very helpful (or device UUID if that’s your thing). As well as knowledge if you have separate /boot parititon or not
First and foremost advice – do not despair – GRUB shell is pretty powerful and flexible tool for its purposes.
Lets try to find where (if) do we have GRUB installed.

Good – 1st primary partition.
Now, lets check if it’s possibly /boot partition or root, and where is root partition and if it is readable at all.

Ok, in our case root partition is first logical drive of extended partition, that means that GRUB is installed on separate /boot partition.
Now, one of the reasons boot processes ended up in GRUB shell is that GRUB could not find it’s config file so it has no information about kernel to boot. Lets check this out

The file is there, why it did not load? One of possible reasons is the file itself is corrupt. Let’s try to find out.

Looks correct – we also refreshed our memory about root device. Why this config file was not executed then? Let’s try one more test:

Now here is the clue – in some cases ( I don’t know exactly which) GRUB *stage_15 part looks for /boot/grub/menu.lst regardless of the partition on which it was installed. In case of separate /boot partition that calls for special symlink, which is not existant in our situation.
What we can do now – we can try to boot manually or boot from rescue CD to resolve the problem.
Lets try to boot manually via GRUB shell. Use TAB completion to get the list of kernel/initrd images you can use

If starts are in lucky position and there are no other problems (corrupt file system for example), then your system will boot and we can correct the reason why it’s all happened in the first place.

From this otherwise very informative page I’ve got possible explanation of the reason of this problem and the solution same as above. But because of page formatting I’ve got it wrong and did

And very next reboot I was awarded with infamous GRUB “error 26” – – too many symbolic links just like this guy.

I hope this page was helpful and saved you some time and efforts.