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:
https://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:
https://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:
https://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 (https://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
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
