Chainloading GRUB2 in a dual-boot Linux Setup

So my setup is like this on two computers: Ubuntu Linux (used most frequently), Fedora Linux, and either Windows XP Home or Windows Vista. On my laptop, I have Fedora controlling GRUB, and on my desktop, I have Ubuntu controlling it. The two biggest issues that I’ve run into are these: when I update/upgrade the non-controlling distro, it overwrites GRUB and takes control, or when I update/upgrade the non-controlling distro, I have to log into the controlling distro and update GRUB to make those changes appear.

In researching this, I’m finding a couple of things out. First “Beginning in Fedora 18, GRUB2 can no longer be installed to a partition.”, so it will have to control everything. Well, technically, I can probably force GRUB2 to install in a partition, but I’ll probably just use the Fedora version of it to control everything for simplicity (plus I like the background more than the plain black one for Ubuntu).

The first step is to either install or move one of the grubs to a partition. In my case, I wanted to move the Ubuntu GRUB to it’s partition. WIth GRUB2 though, this is harder than it would seem. GRUB2 doesn’t like using partitions, because it’s not as stable as putting it in the Master Boot Record (MBR). It has to use blocklists in order to determine what operating system is where.

So, in order to force grub to install in a partition, you have to use the –force option. (note that it’s two dashes – – not –)

grub-install –force /dev/sdXY # Where X is the letter from fdisk that represents the boot order, and Y is the partition number.

You’ll use fdisk -l to decide which partition GRUB should be installed on. For example, if you only have one drive, it would most likely be sdaY, if you have two drives, it could be sdaY or sdbY; depending on which drive your operating system is on.

Next you’ll have to reboot into the operating system that you’re going to use for the main version (in my case, Fedora). When you boot up, if you don’t see that operating system listed in the GRUB menu, you’ll have to use a LiveCD to fix it. In my case, as I didn’t have anything on the Fedora partition that was important, I simply reinstalled it.

The first thing you’ll want to do in the operating system that will control GRUB, is to install it in the MBR. You can do this with

grub-install /dev/sda  #(or sdb or sdc or whatever letter corresponds with your hard drive).

After installing GRUB to the drive, you’ll need to edit your etc/grub.d/40_custom file to add in the chainloader.

You’ll add something similar to this:

menuentry “Chainload Ubuntu 9.10 on /dev/sda3” {
set root=(hd0,3)
chainloader +1
}

GRUB2 uses the following numbering conventions: 0 to infinity for the hard disk number, and 1 to infinity for the partition number. So, the first partition on the first disk would be hd0,1 and the second partition on the second disc would be hd1,2. Also it doesn’t matter if you used hd or sd in the grub-install command. Inside of the grub.cfg files, it’s always hd.

It’s also recommended that you set 30_os-prober to non executable with chmod -x 30_os-prober so that you won’t have multiple entries for your operating systems. And if you have other operating systems (such as a triple or quadruple boot setup), they should be added to the 40_custom file as well.

FInally you’ll run the

grub2-mkconfig -o /boot/grub2/grub.cfg

command to update grub. On Ubuntu, this command is actually update-grub.

If you don’t like the format of the GRUB menu (such as all of the different single-user (Recovery) mode entries), you can comment those out in the 10_linux file as well, and re-update grub.

So what will this accomplish? Simply put, it will ensure that if you have two Linux distributions installed on a computer, they’ll be able to update their own grub. Why’s that important? Because it makes updating kernels/upgrading versions much simpler. Instead of having to boot into the operating system, update or upgrade, and then boot into the controlling operating system and update grub before you can use the newest kernels, you simply do updates/upgrades as you would on a single-boot system.

Restoring your GRUB bootloader after upgrading Windows (or installing Windows)

There’s a story behind this.  I am triple-booting my laptop:  Windows XP Media Center 2005, Windows 7 RTM Ultimate, and Kubuntu 9.04.  When I installed Kubuntu, GRUB was the boot loader that I chose, and it worked perfectly.  However, when I installed Windows 7 RTM, Windows overwrote my GRUB boot loader, so I no longer could boot to Kubuntu. 

This is a pet-peeve that I have had with Microsoft’s operating systems for a long time.  Linux will happily move things around, so you can boot to either Linux or use the Windows Boot loader to boot up whichever versions of Windows you had installed.  Microsoft, however, just writes it’s boot loader over whatever is there—which will break your dual-boot of Windows and Linux (or multi-boots) or Windows and whatever other Operating System (non-Microsoft) you have installed.

I’ve searched the Internet for easy instructions for repairing GRUB—but never really found anything good. Until today, that is.  The closest that I found was the Super GRUB Disk or Auto Super GRUB Disk, which didn’t work on Windows 7.

Today, I read an article about the SystemRescueCD releasing their 1.3.0 version.  So, I downloaded it and looked for any articles on repairing GRUB with this.  I found some very simple instructions, and successfully repaired my GRUB installation.  Now I can boot to Windows or Kubuntu with all of the kernels that I had before.

The instructions

The instructions come from Tutorial on Repairing GRUB.  Here they are step by step.

  1. Boot to the SystemRescueCD or any liveCD for Linux (SystemRescueCD is preferred as it automatically sets you as root).  If you booted another Live CD, open a Terminal and either use “sudo” or su to get to the root prompt. The rest of the instructions are assuming that you have a root prompt or will use “sudo grub” to get into the grub program.
  2. type grub or sudo grub at the prompt (enter your password if necessary)
  3. At the grub> prompt, type find /boot/grub/stage1

It should return a value such as (hd0,1) or whatever your grub location is (Mine was hd0,3)

At the grub> prompt, type root (hd0,1) or whatever value was returned previously  (mine was “root (hd0,3)”)

It should return a value such as filesystem type is ext2fs, partition type 0x83.

At the grub> prompt, type setup (hd0) or whatever the first number in the value you used earlier is.

You should see grub running through some tests then installing itself and your menu.lst file with “Yes” or “Succeeded” depending on the action—then “Done.”.

If you see that it was successful, you can type “Quit” at the grub> prompt.

Something to note.  Linux, like most Operating Systems and programs, begins everything from 0—not 1, as you would normally think.  So, seeing “hd0,3” would mean the fourth partition on the first physical drive.  If you have Grub installed on a second hard drive, it will most likely show up as hd1,x where x is the partition that Grub is installed on.

Typically, your hard drive will have Windows on hd0,0 and then whatever other operating system on hd0,1 or whichever partition it is placed on.  In my case, my swap file (Linux’s version of the pagefile on Windows) is on hd0,2, so my actual Linux installation is on hd0,3.

So, if you’re needing to install GRUB or reinstall GRUB, I hope this helps you out.

Have a great day:)
Patrick.