This article will show you how, when presented with this situation, to manually load your kernel and find out what went awry.
First thing is to briefly explain how Grub loads itself and the kernel.
GRUB in a nutshell
When the server is powered on, the server's BIOS finds the primary bootable device and loads the initial bootstrap program from the master boot record (MBR), then transfers control to Grub Stage 1. Stage 1 resides in the MBR and because it is very small code, it basically loads the next Stage from a defined location on the disk within the first 1024 cylinders.
Stage 1 can load Stage 2 directly, but it's normally set up to load Stage 1.5. Grub Stage 1.5 is located in the first 30 kilobytes of hard disk immediately following the MBR and before the first partition. Stage 1.5 can contain any drivers needed and it then loads Stage 2. Stage 2 will then load the default configuration file and any other modules needed. These files are located on a SLES server in the /boot/grub/ directory.
Once Grub has loaded, it normally presents a graphical interface where you can select which kernel to load. There are other options that can be configured, but we’ll stick with the SLES defaults here.
Grub then loads the kernel into memory and passes control to that kernel.
Or so it should…
Manual Load Process
Now, aside from a drastic failure in hardware, seeing the prompt below causes one to scratch one’s head in confusion and perhaps state a few unmentionable explicatives.
But, seeing this prompt has it’s upside. We know the server is not dead, Grub cannot find its files for some reason.
We’ll try to get the menu back first. On SLES, by default, Grub files reside in /boot/grub/ directory. But, we need to know what disk device and partition. We can use “find” and Grub will tell us.
grub> find /boot/grub/stage1
Now that we know that on hard disk 0, partition 1 (the second partition), the Grub files reside and we can issue the “configfile” command and start the menu.
grub> configfile (hd0,1)/boot/grub/grub.conf
Note: I have found SLES servers (various versions) that will have the grub.conf in /etc/, so if the above command doesn’t work, you can “find” the grub.conf file just like before.
Boot up the kernel and ensure that Grub is still part of your MBR. You can use the /sbin/grub-install command to re-install it to the MBR. Here is the command example.
# /sbin/grub-install /dev/hda
Installation finished. No error reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.
# this device map was generated by anaconda
Don’t worry. Re-installing Grub to the MBR does not affect your data, unless this was a Windows Server to begin with.
Still Having Issues...
If you still get the Grub prompt, we can load the kernel manually.
First we need to find out where the kernel files are located. Again, SLES puts the kernel files in the /boot/ directory as with most distros. Then we need to set "root" to its proper disk device, tell Grub which kernel to use and then which initrd to use
Note: The word "root" is used here to represent a starting point. It has nothing to do with the user “root”.
We remember from above, that the Grub files are located on (hd0,1), but I will show the find command again for consistency.
grub> find /boot/grub/stage1
Now that we know the hard disk partition that the kernel files are located, we can set the root location.
The root will be on the same hard disk and partition that we found the Grub file /boot/grub/stage1 on. The "root" would be on (hd0,1). To set this we enter the root command,
grub> root (hd0,1)
Filesystem type is ext2fs, partition type 0x83
We can see that grub has found a Linux file system EXT3, and set root to it. It says EXT2 but it’s really EXT3.
Next we need to tell Grub which kernel file to load and where it’s located. We use the “kernel” command. One thing I know is, I have no idea the name of the kernel file to load. Like working in Bash, the Tab key can help us. We want to specify our “root” as part of the path, otherwise Grub won’t know which device partition to use.
grub> kernel (hd0,1)/boot/
Possible files are: map grub initrd-22.214.171.124-0.7-pae symvers-126.96.36.199-0.7-pae.gz
Kerntypes-188.8.131.52-0.7-pae config-184.108.40.206-0.7-pae vmlinuz-220.127.116.11-0.7-pae initrd
backup_mbr symtypes-18.104.22.168-0.7-pae.gz vmlinuz vmlinux-22.214.171.124-0.7-pae.gz
grub> kernel (hd0,1)/boot/
I look for the file, (for SLES), that starts with vmlinux for my server. I see three possible choices.
The file that ends in “gz” is a compressed version of my kernel and “vmlinux” is really a symlink to the real kernel file, so our choice is vmlinuz-126.96.36.199-0.7-pae
We then enter the command to load the kernel file.
grub> kernel (hd0,1)/boot/vmlinuz-188.8.131.52-0.7-pae root=/dev/hda
[Linux-bzImage, setup=0x1400, size=0x12c945]
I added the additional “root=/dev/hda” because this kernel needs to know which device has the root file system (/).
After that loads, we need to load the initrd (Initial RAMdisk) file. Some kernels do not need it, it is default in SLES so we’ll load it also. It is important to know that the initrd file will have the same numeric version as the kernel. Using the listing above, we can see that the file is named, initrd-184.108.40.206-0.7-pae, but you can use the Tab key here also.
grub> initrd (hd0,1)/boot/initrd-220.127.116.11-0.7-pae
[Linux-initrd @ 0x3c8000, 0x27dcb bytes]
If anything is not right, at this point you will probably experience a Kernel Panic and have to power cycle the server.
Otherwise, we have one last critical step, booting the server.
At the Grub prompt, enter the boot command.
If you’ve provided the proper information, then the kernel should take over control and you should see familiar processes scroll and your server boot. When complete, if you need to re-install Grub or repair your disks, you will need to do so at that time.
I remember the first time I was presented with the Grub prompt. I was a Linux Newbie and couldn’t find any help. I fumbled around for a while to no avail. Eventually, I just got the CDs out and rebuilt the whole server. If I’d known the steps in this article, I’d wouldn’t have wasted a good day, rebuilding from scratch.
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.