[TAG] How to Locate the second stage boot loader.

[Benjamin A. Okopnik]

On Thu, Feb 10, 2005 at 10:55:10AM -0500, David.Smith at celera.com wrote:
> 
> Hi,
 
Hi, David -

> I have not been able to find this information in any documents on-line or hard
> copy.  It may exist but I have not found it.
> 
> I am using the GRUB loader for my Linux system.
> 
> I understand that the X86 BIOS reads the first 512 Bytes of the boot disk (MBR)
> to load the first stage boot loader into memory and run it.  The part that I'm
> stuck on is:
> 
> > The first stage boot loader locates the second stage boot loader, loads it
> into memory and runs it.
> 
> How does it locate the second stage boot loader? Specifics please.

Well, back in the days of DOS, the MBR contained a pointer to the DBR
(DOS boot record) which lived in a fixed place (if I recall correctly,
it was at the beginning of track 1, whereas the MBR was at track 0.) I
can't imagine that it's any different now - although now the MBR has to
be _compiled_ by LILO and such whenever there's a change, precisely
because the file containing the second-stage loader is likely to be in a
different physical location.

> Where and how does the first stage boot loader look for the second stage boot
> loader?

Control gets passed to the entry point described by that hard-coded
pointer created by LILO, etc.

> For example, does it expect to find the second stage boot loader at a specific
> location on the boot disk?

Nope.

> The first stage boot loader is a small machine code binary, so I can't imagine
> that is has an understanding of the file system in order to look at /boot.  I
> assume then that the first stage boot loader must contain some kind of a
> pointer/address to locate the second stage boot loader, on the boot disk.

Right.

> If I look at the MBR can I determine where the second stage boot loader is
> located?

If you can read machine code, yes.

> What happens if the second stage boot loader is fried?

Famous DOS/Wind0ws message, which can still be seen in the MBR -

"Operating system not found"

Under Linux, the messages vary; you can actually set them (I recall
changing the MBR on a friend's Wind0ws machine after having booted it
with a Linux CD - we crafted some sort of a funny but indicative
message.) For Grub, I'm not really sure (although you could find out by
doing 'dd if=/dev/hda of=mbr.out count=1' and looking at the contents of
'mbr.out'.) LILO goes through a sequence of the letters in its name:

(from the LILO manual)

  (<nothing>)  No part of LILO has been loaded. LILO either isn't installed
    or the partition on which its boot sector is located isn't active.
   L <error> ...   The first stage boot loader has been loaded and started,
    but it can't load the second stage boot loader. The two-digit error
    codes indicate the type of problem. (See also section "Disk error 
    codes".) This condition usually indicates a media failure or a geometry
    mismatch (e.g. bad disk parameters, see section "Disk geometry").
   LI   The first stage boot loader was able to load the second stage boot
    loader, but has failed to execute it. This can either be caused by a 
    geometry mismatch or by moving /boot/boot.b without running the map
    installer. 
   LIL   The second stage boot loader has been started, but it can't load
    the descriptor table from the map file. This is typically caused by a
    media failure or by a geometry mismatch. 
   LIL?   The second stage boot loader has been loaded at an incorrect
    address. This is typically caused by a subtle geometry mismatch or by
    moving /boot/boot.b without running the map installer.
   LIL-   The descriptor table is corrupt. This can either be caused by a
    geometry mismatch or by moving /boot/map without running the map
    installer. 
   LILO   All parts of LILO have been successfully loaded. 

> Can I recover from this without a complete system reinstall?

Yes. 'gpart', as just one example of what you can use, will search the
specified HD for an OSBR and "fix" your MBR to point at it. I can tell
you from experience that this can be a *long* process for a large HD.


* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://linuxgazette.net *