Brian Mork - Spring 2009
I have used Dual-Boot systems for
years. I've now transitioned to using Alternate Boot system
architecture because storage hardware is cheap, it provides better
redundancy, and offers more modular upgrade paths.
I ran dual-boot Windows Linux systems since about 1994, using two different boot loaders.
The LILO boot loader writes a hard-coded MBR (Master Boot Record) pointing to physical locations on the hard disk(s) to continue booting. It doesn't matter what operating system you're booting to because physical locations of the disk are coded in the MBR and not edited once the MBR is created. You do need an operating sysetm to write the initial MBR from the lilo.cfg file, and there are both Windows and Linux programs to do so (primarly lilo under Linux).
The GRUB boot loader is a more feature oriented, and the MBR that is written actually contiues to a small-footprint command line interactive program. It reads a menu.lst file from the local Linux disk and presents options to choose from. It can auto default to a choice, or you can choose something else, or edit choices, or just manually type in a new choice real time. Very flexible.
It bothered me that, on a dual-boot system (Windows on the first drive and Linux on the second), that I needed both drives alive and well to boot. The MBR on the first drive needed to be there to read the GRUB menu.lst file and 2nd/3rd stage load files on the second drive. Rather than providing some redundancy and backup, I was instead asking for failure twice as often because booting depended on two hard drives.
When I jostled things around and rewrote my GRUB menu.lst file to accomodate Linux on the first drive and Windows on the second, I had nothing but trouble. Windows does not like to be isolated away from the first drive boot sectors. I still don't know why the "windows" boot choice doesn't work.
color black/cyan yellow/cyan
serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
kernel (hd0,0)/boot/vmlinuz BOOT_IMAGE=linux root=UUID=c91114f6-e482-4232-99ed-a452f176f676 splash=verbose vga=788
kernel (hd0,0)/boot/vmlinuz BOOT_IMAGE=linux-nonfb root=UUID=c91114f6-e482-4232-99ed-a452f176f676 splash=verbose
kernel (hd0,0)/boot/vmlinuz BOOT_IMAGE=failsafe root=UUID=c91114f6-e482-4232-99ed-a452f176f676 failsafe
title desktop586 22.214.171.124-1mnb
kernel (hd0,0)/boot/vmlinuz-126.96.36.199-desktop586-1mnb BOOT_IMAGE=desktop586_188.8.131.52-1mnb root=UUID=c91114f6-e482-4232-99ed-a452f176f676 splash=verbose vga=788
title desktop586 184.108.40.206-1mnb
kernel (hd0,0)/boot/vmlinuz-220.127.116.11-desktop586-1mnb BOOT_IMAGE=desktop586_18.104.22.168-1mnb root=UUID=c91114f6-e482-4232-99ed-a452f176f676 splash=verbose vga=788
What I wanted was two bootable drives that could each stand alone in case the other failed. Finally, I just created a stand alone two-partition Windows drive (C: and D:) as a solo drive in the computer. Then I created a stand-alone 3-partition drive under Mandriva 2008 Linux (root, swap, home) as a solo drive in the computer.
Finally, I put them both in with Linux as IDE Primary and Windows as IDE Secondary.
Once inside of the Gentoo boot Linux, mount up the Mandriva root partition:
mount -t ext3fs /dev/hda2 /mnt/mount-location
In my Linux distribution there was an install script
install.sh, of all
things) left in place that runs GRUB, which automates three grub
commands. Here's a copy of the script file:
Next, drop into the GRUB directory previously created during the Mandriva install and run the script, which will cause GRUB to re-write over the Master Boot Record:
Revision 1.0 - This document was edited using Kompozer 0.7.10 (renamed Nvu editor) web page editor under the KDE desktop on a Mandriva 2008.1 Linux system.