[conspire] Building grub-1.95

[Rick Moen]

Quoting John Andrews (jla1200 at netzero.net):

> 2. I don't understand how grub-mbr Windows and Linux boot

I think this is a good place to start.  Let's review how booting works
on "PC" x86-type boxes.

You turn on the machine, which initialises the motherboard and attache
BIOS ROM routines.  The boot routine that's part of hardware interrupt
13 hexadecimal (thus: "INT 13h") comes alive and assumes control of the
machine.

The INT 13h boot routine checks the roster (and listed order) of
bootable devices in the BIOS Setup CMOS data.  It then polls the
hardware, in that order, to find the first bootable device that's in
"ready" state.  It then loads whatever data's in sector zero of that
device into RAM, and then transfers control of the machine to that
program.  (It'd better be a program, rather than random data or
something else, otherwise at best and most probably, your computer will
come to a halt, very confused.)

Let's say that the first device checked that's in "ready" state is your
(first) hard drive, and that that hard drive has a bog-standard,
commodity install of MS-Windows XP on it.  Not dual-boot, just XP.

That (512-byte long) sector zero (the "Master Boot Record" or MBR)
contains, as mentioned previously, a 446 byte area for a miniature
program, then 4 x 16 byte entries of partition table, then 2 bytes left
over that NT (and thus XP) Disk Administrator doodle in -- for a total
of 512 bytes.  All of that has gotten loaded, and the initial 446 bytes
(a very small and rather stupid program to which nobody's assigned a
name) parses the rest.  It reads each of the four entries until it finds
the first one that's of type "primary" (we won't get into that, at the
moment) and has the "active" aka "bootable" flag set.  Other data
included in that 16 byte entry include the beginning and ending hard
drive cylinder numbers for that partition -- essentially the location of
the partition's beginning and end, within the physical drive.

This will sound a bit familiar:  The unnamed MBR program seeks to the
first sector on the first cylinder of the qualifying partition, loads
that 512-byte sector into RAM, and turns over control of the computer to
whatever was found there.

During the process of installing XP, you (or more likely the OEM that
preloaded XP onto the computer) created a whopping big NTFS partition,
then installed XP onto that, including a second-stage bootloader program
called "OS Loader", whose configuration file is boot.ini .  A small
chunk of OS Loader is in the partition's first sector, and is what comes
alive.  It is smart enough to find the second, larger portion, which is
probably the part smart enough to find and read boot.ini .  For all I
know, there might be a third stage....  At some point, some incarnation
of OS Loader is smart enough to find the XP kernel, and load drivers
from somewhere or other, mount the NTFS filesystem(s), and start up the
rest of XP in turn.


Here's one analogous way to boot a Linux distribution from the same
hardware.  (Let's assume that XP is still present on /dev/hda1, but that
you've shrunk that to make room, and are otherwise ignoring it for now. 
You're going to have /dev/hda2 as swap, and /dev/hda3 as ext3 for the 
rest of the space.)

The BIOS INT 13h boot routine finds and loads the first hard drive's
sector zero and hands over control, as before.  The 446 bytes at the
beginning of the MBR has the usual sourt of rather stupid program.  It
could still be the unnamed Microsoft program, or it might be an open
source replacement that got installed when you loaded Linux.  Either
way, it reads the partition table and finds that the third entry (call
it /dev/hda3) is of type primary and has the active (bootable) flag.
It therefore loads and turns the machine over to the contents of that 
partition's first sector.

That first sector happens to be a slightly larger and less stupid
program, part of GRUB.  Maybe that code in turn finds and loads a
slightly smarter chunk of GRUB.  Pretty soon, the GRUB minikernel
(my jargon, might not be used by others) is loaded, and it's smart
enough to actually read and understand ext3 and some other common 
filesystems.  It does that and finds /boot/grub.conf (aka menu.lst
on some distros), which tells it in GRUB lingo[1] where to find bootable 
"things" -- kernels, matching initrds (= initial RAMdisks), and matching
root filesystem for Linux, corresponding things for MS-Windows.  It
presents a "boot:" menu to the user, reads which bootable "thing" is
described as default, and does a countdown.  If countdown completes
without the user intervening, it defaults to loading into RAM the
indicated kernel code plus information to pass _to_ that kernel about
the initrd + root filesystem, and turns over control to that.

I believe the _earliest_ part of the GRUB program has to get primed with
some stored information about where exactly, i.e., on what drive, to
find /boot/grub.conf .  I _think_ that priming happens when you run
/sbin/grub-install or whatever it's called.  I might be wrong; I don't
think about these things often.


Dual/multi-boot?  All that's really different is that you add more
"stanzas" (sections) to /boot/grub.conf to tell the full-blown GRUB
program, when it comes alive, about how to boot your MS-Windows
partition and other things present on your drive.

There are a large number of GRUB explanations / recipes on the Web.  
I just found this one, and rather like its clarity and brevity:
http://www.fedoraforum.org/forum/showthread.php?t=975
There are also two highly recommended entries about GRUB on 
http://linuxmafia.com/kb/Kernel/

> 4.Gutsy switches between hda and sda now in the menu.lst.

Sorry to say, the above's meaing is clear as mud, to me.

> 6. Gutsy started using uuid=xxxx... instead of root/dev/hda in the  
> menu.lst

I personally hate that.  The whole "uuid" thing is a mess, even though I
understand the rationale for it.

> 8. What does it mean when the win 98 flashes through the boot splash
> screen then drops you into a C:> prompt?When you try and boot it.

Sorry, can't help you debug Win98.

> 9. I think I grub> setup hd0  and later  did fdisk /mbr to it. I  
> don't remember now!

Suggest keeping notes in the future.  Right now, just concentrate on
correcting and re-doing your GRUB configuration / installation.


[1] Why a special GRUB lingo?  Why can't it say /dev/hda1 instead of
(hd0,0)?  Because GRUB is not Linux-specific; it wasn't written
particularly for Linux at all.