msbr_and_lilo

This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.



Date: Fri, 20 Oct 2000 11:25:28 -0700
To: svlug@svlug.org
Subject: Re: [svlug] gui lilo..?
From: Rick Moen <rick@linuxmafia.com>

begin  Bill Jonas quotation:

> Last I checked, the MBR was still 512 bytes.

Not that you asked for this sort of ridiculously over-detailed further
elaboration, but:

Sector 0's 512 total bytes are divided into 446 bytes available for
initial boot code (called by the Int 13h boot service), followed
by four 16-byte records for the (64-byte) partition table, and then two
bytes left over at the end (which NT disk administrator uses for "disk
signatures").

Yr. welcome.

===

Date: Fri, 20 Oct 2000 17:31:35 -0700
From: Marc MERLIN <marc_news@valinux.com>
To: Greg Herlein <gherlein@herlein.com>
Cc: svlug@svlug.org
Subject: Re: [svlug] About lilo fitting in the MBR

On Fri, Oct 20, 2000 at 06:54:56AM -0700, Greg Herlein wrote:
> > Last I checked, the MBR was still 512 bytes.
> 
> Yes, yet another technical reason - the exact size that lilo has
> to fit into - why the proposed graphical lilo is not going to
> work.  Of course, you could make a new boot loader (like
> OS/2's) that has to have a separate partition of it's own, I
> suppose.... but it's not written yet.

Actually, lilo  doesn't fit  in the  MBR, the  MBR code  has just  enough to
bootstrap the second stage loader, which has  to be read block by block from
the hard drive, just like the kernel itself.
This is  why you  need to  re-run lilo  when you  change your  lilo.conf, to
update those blockmap tables.

In other words, adding whatever amount of code to lilo at this point (GUI or
other) doesn't make a difference.

===

the rest of The Pile (a partial mailing list archive)

doom@kzsu.stanford.edu