...making Linux just a little more fun!

GRUB, PATA and SATA

By Anonymous

1 The Problem

Start your search engine and search for the following keywords both on the Web and in the newsgroups:

GRUB SATA confused

You will get reports galore of GRUB failing with SATA, most certainly failing when facing a mix of old IDE (PATA) and new SATA disks. I'm submitting this as evidence, but I personally don't need any, since GRUB cost me some 10 hours of toiling in exactly this context.

You will find less evidence for Lilo, but Lilo will also fail. Xandros 4.0, which relies on Lilo, gave me a bad time. Further, Lilo is on its way out; the major distros rely on GRUB.

So what is to be done, if you have a mix of PATA and SATA, and want to have a few GNU/Linux distros ready to boot, and need to have Windows anyway? Repeat after me: do not install GRUB to the Master Boot Record on the disk carrying the Windows C partition.

It is assumed the problem does not stem from the hardware, because there are indeed mobos with both SATA and PATA, and are able to handle them together.

2 Accessing the GRUB boot record

If we write a GRUB boot record to a partition, how do we activate it? Not from GRUB's Master Boot Record (MBR); we don't have one, given our earlier decision. The options are:

(i) from Windows's MBR

(ii) from a real floppy, from a (DOS floppy emulation) CD, or from a (DOS floppy-emulation) USB stick.

Although frequently recommended, (i) is not a solution. You will fail if you install GRUB to a boot sector, extract that boot sector to a file, and append an entry for that file in boot.ini: It will not work with a mix of PATA and SATA. Something else is needed.

Maybe you belong to the lucky ones who never had problems with GRUB. Otherwise, here follow solutions A and B, for your attention. They will work in most cases, but still there might be hardware constellations where they will fail. There are too many variations to test, and I certainly do not have access to the hardware.

The instructions given here target Windows XP. They can probably be adjusted for Vista.

3 Terminology

Some terminology first. Under Windows, the boot drive is the one that carries boot.ini and the loader, ntldr. The system drive is the one that carries the Windows directory. They can be different, although often they're not. We say "boot directory" to indicate the directory containing boot.ini. For Windows XP, the boot partition has to be the first one seen by the operating system - with the drive letter C slapped on it. Apparently, Vista accepts any partition, and just re-arranges the drive letters.

When installing or restoring or updating your Linux distro, make sure that the Master Boot Record for the Windows boot drive is not touched. If it is, you will have to go through some rescue operations. That MBR is reserved for Windows - and GRUB should keep its GRUBby fingers off it. Let it install a boot record to the boot sector in the partitions - e.g., to /dev/hda4 - but never to /dev/hda.

Be aware that the installation routine may seem set to comply with your instructions, but then it may go ahead and modify the MBR anyway. It's difficult to say whether the blame is with GRUB directly or with the install routines, but it happens. Be ready for a fight, be ready for emergencies. You might even consider trying the following trick: let the boot record be installed to a floppy, then do everything else by hand. The trick works even if there is no physical floppy.

The trouble stems from one simple fact: when GRUB starts from the Master Boot Record and is showing its menu, it sees the available devices in an order which may differ from the order it sees after launching initrd and then the kernel. In other words, its device map changes on you without any warnings or compliments. After activating the required entry from the menu, all hell breaks loose because essential files are not found. I.e., kernel panic.

Ubuntu is trying to handle the problem using UUIDs for the hard disks. UUID means Universally Unique IDentifier, and is intended to be the immovable rock in the sea storm of boot loader, initrd, and kernel. So you will see Ubuntu's GRUB configuration showing lines like:

    kernel /vmlinuz root=UUID=f0bfe866-2449-4d75-8222-b444ff564876

Long story short - it does not help. This is my empirical finding. Some theory from Linus Torvalds himself:

http://lwn.net/Articles/65209/

4 Method A

Method A uses the 'hide/unhide' feature in GRUB, to hide away all boot partitions that are contributing confusion - in the extreme case, all boot partitions but the one that has a specific operating system. At that moment, there can be no confusion in the device map, since only one entry is left.

This approach is explained here:

http://www.justlinux.com/forum/showthread.php?t=143973

It is based on a GRUB floppy, either as a real floppy or as a floppy image burnt to a CD. It is not quick to set up, since it requires extensive trial and error but - to be fair - the other method is not much quicker.

Note that with this method, when you are running a distro, Windows may be hidden away. If you want to transfer files from the distros to Windows, you will have to have a FAT partition accessible at all times - or have access to Linux file systems from Windows (available only for ext2/ext3, as far as I know).

5 Method B

Go and download a modified version of GRUB, including grldr (mnemonics: 'grub loader'). Put grldr in c:\ and add the following line to boot.ini:

    c:\grldr = "sundry distros"

You also need GRUB's menu.lst in the same directory. Edit it as appropriate for each of your distros, and you are done.

Fine - but what is grldr, and where do you get it from? grldr is a GRUB console that gets along with Windows booting, and weighs less than 190K. It is part of a free software project with a puzzling name:

http://grub4dos.sourceforge.net/

You really only need that one file, grldr; the adventurous can play around with the rest.

6 The Correct Device Map

As stated above, GRUB's problem with a mix of PATA and SATA is that its device map shifts while the boot is in process. So, if you opt for method B, what device map are you going to throw at it? None: you do not need a device.map file for method B. But you still need to edit menu.lst, and thus you need to know what to call your available disks according to both GRUB and kernel conventions.

Start with a menu.lst file that might be right. When the GRUB menu pops up, go to the GRUB's command line and type

    root (

pressing 'Tab' to get a list of all possible completions, as seen by GRUB here and now. This is the list of the available devices. For each one of them repeat the trick, e.g.,

    root (hd0,

plus a 'Tab' will list all partitions in hd0. This way, you get a list of all partitions on all disks with the correct GRUB denomination and the partition type. Partitions from the Unix world will be recognized; so will FAT partitions. NTFS will not be seen in pure GRUB, but grub4dos can manage. That should be sufficient for you to identify the hardware.

The hard part of the exercise is giving the devices correct names according to kernel conventions. Would hd0 be /dev/hda, or what? The shift in the device map occurs here, and you may have to rely on trial and error. When you have the mapping of the devices right, the mapping of the partitions is trivial.

7 State of the Nation

All this looks like a royal hassle - and it is. Installing an operating system should not affect operating systems already installed. Windows has bad manners in this respect, but does that mean that GRUB should also have bad manners? It should not; actually, it's supposed to be friendly and co-operative.

Well, if you go to the GRUB Web site (http://www.gnu.org/software/grub/), you'll learn that there is a discontinued GRUB version (0.97) and a new GRUB version (1.95, as of the time of writing.) The former is called legacy GRUB; the latter is called GRUB-2 and has been in the works for 4-5 years. The FAQ for the new GRUB asks straight away why there is a need for a fresh rewrite of GRUB. Excerpt from the answer:

    Because GRUB Legacy has become unmaintainable,
    due to messy code and design failures.

It also says that the new version is "usable". Obviously, it is not, since the major distros rely on legacy GRUB (customized for their own purposes) and ignore the new one - I was unable to find even one single distro that uses it.

Let's hope GRUB-2 will come up to speed very soon, and that it is not going to turn into a repeat of the Hurd saga. The situation is unbearable. While a Windows install takes over the MBR and impedes booting other operating systems, Windows still manages to pull itself up by its boot straps. With a mix of PATA and SATA, installing SUSE or Ubuntu destroys the Windows MBR, and then fails to boot ANY operating system at all!

Talkback: Discuss this article with The Answer Gang


Bio picture A. N. Onymous has been writing for LG since the early days - generally by sneaking in at night and leaving a variety of articles on the Editor's desk. A man (woman?) of mystery, claiming no credit and hiding in darkness... probably something to do with large amounts of treasure in an ancient Mayan temple and a beautiful dark-eyed woman with a snake tattoo winding down from her left hip. Or maybe he just treasures his privacy. In any case, we're grateful for his contribution.
-- Editor, Linux Gazette

Copyright © 2007, Anonymous. Released under the Open Publication License unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 141 of Linux Gazette, August 2007

Tux