PDA

View Full Version : GRUB hangs when installing to second hard drive



tomahola
30th October 2007, 10:52 AM
I have successfully installed Linux on a second hard drive while being able to keep Windows XP on the first drive and keeping the Windows MBR intact. I have seen many posts on the net with people struggling with this issue, but no solution, so I thought I will post the solution here to help others.

When using normal GRUB install methods when the Linux is not on the primary hard drive, sometimes GRUB hangs when booting the machine. That is GRUB and a blinking cursor is displayed after starting, then nothing happens. This is especially the case when you like to use the Windows boot loader to start GRUB from a second drive. One might want to keep the primary disk MBR intact, for example if the disk is encrypted.

Here is how I did it:
I removed the primary disk during Linux install to make sure I keep it intact.
I have SATA disks, so I just unplugged the primary disk SATA cable.
I installed Linux normally on the second disk.
After the Linux install I plugged the primary disk back in (while power off, of course).
Now I needed to boot Linux with a rescue CD (for example, entering linux rescue to the install CD).
The rescue CD automatically mounted my Linux system to /mnt/sysimage
I did the following to "get in":

mount ---bind /dev /mnt/sysimage/dev
chroot /mnt/sysimage

Then I fixed the GRUB device devicemap /boot/grub/device.map by adding the second drive /dev/sdb as (hd1). I also edited the /boot/grub/grub.conf and changed all references to hd0 to hd1. This is needed because Linux install created these files when primary disk was removed, thinking the Linux was on primary disk hd0.

Now GRUB needs to be re-installed on the second disk MBR. It won't be loaded from there at boot, but it is a good placeholder for now. The grub-install script won't work and neither will the GRUB setup command. This because these commands won't put a reference to the second hard drive in the GRUB stage1 image that is put in the MBR. In this case GRUB will try to load stage2 (or stage1.5) from the boot drive and hang because this is the Windows disk, while the GRUB second stages are on the second disk. To make a functional MBR I used the more complicated GRUB install command:

From Linux command prompt (as root) start grub:

# grub

Then give following commands to grub:

grub> root (hd1,0)
grub> install /grub/stage1 d (hd1) /grub/stage2 p
grub> quit

This assumes you have a boot partition at (hd1,0) with the grub stage files in the /grub directory. The install command puts the stage1 in the MBR of second drive (hd1). Parameter d tells install to put in a reference for finding the stage2 on the second drive. Parameter p tells install to use the grub.conf file so that you get the boot menu instead of just a GRUB prompt when booting.

Now copy the MBR to a file with the following command:

dd if=/dev/sdb of=grub.mbr bs=512 count=1

This is for a SATA drive, for and IDE drive use /dev/hdb.
Now copy the created grub.mbr file to a floppy, memory stick, network drive, windows FAT(32) partition or similar to be able to transfer it to the C:\ drive of windows. I can not copy it directly there, because C:\ drive is a NTFS file system, which is not writeable by Linux.

Now I booted thee computer normally to WinXP.
I put the MBR file to c:\grub.mbr.
I edit the c:\boot.ini (hidden system file) with a text editor and add this line:

C:\grub.mbr="My Sweet Linux".

This works for me. I hope this solution helps somebody.

disclaimer: I take no responsibility if these instructions cause any damage to your system.

Regards,
Tom Ahola

stoat
30th October 2007, 07:23 PM
Hello tomahola,

Thanks for your contribution to the effort. You present an interesting variation that is sort of a hybrid of the so-called Jim Lawrence method (http://www.jplawrence.us/mywiki/DualBootLinux) and booting with NTLoader (http://www.astahost.com/info.php/using-ntloader-boot-linux_t1510.html). Like your method, the Jim Lawrence thing involves disconnecting the XP drive while Fedora is installed on a second drive with GRUB installed in the master boot record. But the difference is that it uses GRUB to boot both systems and the Fedora drive remains first in the BIOS boot order.

Consider this: Since you do not intend use GRUB to dual boot both systems, then you don't really need to install GRUB in the master boot record of the Fedora drive. It could instead be installed in the first sector of the Fedora boot partition. And if you don't need to install GRUB in the master boot record, then the XP drive doesn't need to be disconnected.

Would this possible short-cut without disconnecting the XP drive have satisfied your requirements?:

XP drive is first in BIOS
Install Fedora in the second drive with GRUB installed in the first sector of the Fedora boot partition (select Configure advanced boot loader options)
Copy stage1 from the first sector of the Fedora boot partition to a binary file in the XP system partition
Edit boot.ini
This would reduce the number of steps and eliminate the need to power down, pull the tower out of your desk, open the case, disconnect the XP drive, power up, power down, reconnect the XP drive, close the case, put it all back in your desk, and power up again.

Finally, when you find that the dd method of creating the binary file just doesn't work (that GRUB + blinking cursor hang), look into a free utility called BOOTPART (http://www.winimage.com/bootpart.htm) which will create the binary file, copy it to the XP system partition, and edit the boot.ini file in one step from an XP Command Prompt window. But most importantly, the binary file that BOOTPART creates has never failed to work for me even in those occasional scenarios where the dd generated file failed (http://www.fedoraforum.org/forum/showthread.php?t=158078) me. The difference is that the binary file created by BOOTPART does not contain an exact copy of GRUB stage1 in first sector of the Fedora boot partition. It instead contains code that loads and executes stage1 in the first sector of the Fedora boot partition.