Dual Booting with Windows XP

[June Tate]

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?

<snip>

> 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 at theonelab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.plug.phoenix.az.us/pipermail/plug-discuss/attachments/20050816/4cd0f3c3/attachment.pgp