Warning: This post is a little verbose. =o) On Mon, Aug 15, 2005 at 06:30:33PM -0700, Victor Odhner wrote: > I am trying to understand the fine points of installing Grub on a system > with XP. I did it successfully with lilo, but don't understand what I did. > > I have gathered that XP has problems with a norml "Free" boot manager in the > boot sector. I did my current install using instructions that came with > SystemRescueCd, which uses Lilo. The lilo.conf example is attached below. Actually, if you install the boot manager _after_ XP has been installed, XP has no problems whatsoever. On virtually all of my PCs, I have XP and Linux dual booting with Grub with no problems. > So, the questions are: > Q1: Is there a kind of boot-manager setup that is right or wrong with XP? There really isn't any right boot-manager setup. In fact, it's like Perl -- there's more than one way to do it, and most people do it in every concievable way. Generally, though, the simpler your setup, the better. Typically, installing the boot manager to the MBR is considered a Good Thing(tm). Additionally, using some kind of chainloader to boot other, proprietary operatings systems is also considered a Good Thing(tm). Keep in mind, XP (and other Windows-based OSes) have their own boot manager already installed to their partitions' boot sector, so all you have to do is get your boot manager to load that instead of pointing it to a kernel. Take this (horribly drawn) example: +-------------+--------------------------+---------------------+ | Name | MBR | Partition 1 (Win) | Partition 2 (Linux) | | Boot Loader | Grub | NTLDR | None | +-------------+--------------------------+---------------------+ When your PC starts up, it reads the MBR's boot sector and loads in Grub. From here, Grub has two options: boot Windows or Linux. Since Linux is really nothing more than a kernel, all Grub has to do in that case is load in the kernel from the parition and start it. In the case of Windows, however, it (and we) have no idea how to start the OS (where's the kernel? etc.). So in this case, since Windows installs it's own boot loader to the partition, all we have to do is load in the boot sector from that partition and start _it_ instead. > Q1: How is the one below different from an ordinary Lilo setup? > Sample lilo config: > lba32 > boot = /dev/hda > map = /boot/.map <<== 140 kb, looks sort of like executable code > prompt > install = /boot/boot-menu.b <<== This is an empty file > delay = 50 > vga = normal > default=win > image = /boot/vmlinuz1 > root = /dev/hda2 > label = sysrcd > read-only > other = /dev/hda1 > label = win > table = /dev/hda As far as I can tell, the configuration file you post below _is_ an "ordinary" Lilo setup. The only difference here is that you're telling Lilo that there's another operating system on disk and to load that one using a chainloader by saying "other = /dev/hda1". The map command tells Lilo to store it's list of independent sector addresses that it can use to store itself in into /boot/.map. The install command is essentially a way of adding additional code into Lilo for other features. In this case (if it weren't a zero-length file), /boot/boot-menu.b is a flashy menu for Lilo to present to the user on startup. > Q2: How can I do the equivalent using Grub? Now, LILO isn't quite as smart as Grub is -- you have to give it all kinds of extra information to take care of booting and such (hence the lba32 and map commands). This is because LILO exists solely in the first 512 bytes of the harddisk, so it has to be as dumb as possible. Grub, on the other hand, is actually composed of an initial 512-byte chunk of code (a file called /boot/grub/stage1) in the MBR that loads in the rest of the program from your Linux partition (usually called /boot/grub/stage1_5 and stage2), so we can be a little less verbose in our configuration file and rely on Grub's intelligence to handle oddball situations like older BIOSes. Additionally, every time you upgrade your kernel, all you have to do is update /boot/grub/menu.lst instead of reinstalling the entire bootloader. There is one _major_ caveat to Grub, however, and you should scrawl this on your bathroom mirror or somewhere where you see it every day so you always know about it: GRUB DEPENDS ON FILES ON YOUR FILESYSTEM TO BOOT So if you delete (or reinstall) your Linux partition later, Grub will be rendered useless because the files it uses to boot with are gone. Also, if you ever decide to change your filesystem after you've installed Grub, you will have to reinstall it, since it won't know how to read it. For most people this isn't an issue, since they don't play roulette with their operating systems (like I do... =op), but it's important that you know about it in case a situation arises where you end up having to make such a change. So with that said, let's move on, shall we? =o) In your case, your configuration file for Grub (called /boot/grub/menu.lst) should look similar to the following: title Windows root (hd0,0) chainloader +1 title Linux root (hd0,1) kernel /boot/vmlinuz1 root=/dev/hda2 ro default 0 timeout 5 Each menu item is started with a title command, and ends at the first blank line encountered. Also note that the order of entries is important, as that is the order that will be shown on the menu. Comments are like in Perl (with a hash), start anywhere on a line and extend until the end of the line. The "default" command tells Grub which menu item to use as the default os to boot (starting at 0 and going up as you move down the list), and timeout tells grub to boot the default selection in n seconds (five here). After you've told Grub what to call your menu item with the title command, you have to tell it where it resides. The format for this is (hdx,y), where x is the number of the physical drive on the chain (master on first IDE chain is 1, slave is 2, master on second IDE chain is 3, and so on), and y is the partition number. Note that both of these numbers start from 0 instead of Linux's customary 1. To boot linux, we need to load the kernel, so we use the "kernel" command and supply it with the full pathname to the kernel and all of the kernel options for it on the same line. Note that you usually have to specify the root drive here since GRUB historically doesn't supply that information automatically. Windows, on the other hand, just needs to load in the NTLDR boot sector and start that, so we give Grub the command "chainloader +1". Note that Grub has a command line version that may or may not be installed on your system. If it's not, download the disk image from ftp://alpha.gnu.org/gnu/grub/grub-0.97-i386-pc.ext2fs, write it to disk, and boot off of it to start it. You may have to press "c" at its menu to get to it's command line. Try doing the following to install it to the MBR: foo:~$ sudo grub Password: ***** Probing devices to guess BIOS drives. This may take a long time. grub> root (hd0,1) Filesystem type is ext2fs, partition type 0x83 grub> setup (hd0) Checking if "/boot/grub/stage1" exists... yes Checking if "/boot/grub/stage2" exists... yes Checking if "/boot/grub/e2fs_stage1_5" exists... yes Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 16 sectors are embedded succeeded Running "install /boot/grub/stage1 (hd0) (hd0)1+16 p (hd0,1)/boot/grub/stage2 /boot/grub/menu.lst"... succeeded Done. grub> _ Note that you have to tell it where all of it's stuff is by doing the "root (hd0,1)" command first, and then the "setup (hd0)" command can be run (note how I'm omitting the ",1" here -- this tells Grub that the target is the entire disk, not just a specific partition). For _most_ situations, this method of installation is fine, but in some rare situations, there may be some warnings or even errors. The Grub documentation is very comprehensive and covers most situations where problems would occur. Have a look there in case you run into trouble. Keep in mind, Grub is _much_ more versatile than what I have demonstrated here, and can be used for system recovery in many situations. See the Grub docs for more details. -- June Tate * http://www.theonelab.com * june@theonelab.com