Boot Manager

  • Thread starter Thread starter Teilhard Knight
  • Start date Start date
T

Teilhard Knight

Could you recommend a good boot manager, please? I mean, to boot several
OSs, but not relying on Lilo. Not Xosl, because it doesn't work together
with a Drive Overlay.

Teilhard.
 
Teilhard Knight said:
Could you recommend a good boot manager, please? I mean, to boot
several
OSs, but not relying on Lilo. Not Xosl, because it doesn't work
together
with a Drive Overlay.


No boot manager that usurps the MBR (master boot record) bootstrap area
will cooperate with a drive overlay manager which also usurps the MBR
bootstrap area. That is why many utilities will not cooperate with each
if they all are trying to overwrite the MBR bootstrap code. You cannot
use, for example, Powerquest (now Symantec) BootMagic with Symantec's
GoBack because both want to be in the MBR bootstrap area. If you
actually need to use the drive overlay manager, you'll need to find a
boot manager that does NOT use the MBR bootstrap area (which means it
might requires its own partition or share one).

Of the boot managers that I have used, all usurped the MBR bootstrap
area so, sorry, I cannot give a suggestion for one that resides wholly
within a partition. You might need to consider getting a new
motherboard with a newer BIOS that can actually support the large drives
that you want to use, or use an IDE controller card that has newer BIOS
to support the larger drives.
 
Very good answer. So many people don't realize that the friggin drive
overlay utilities wreck havoc with many things you want to do with your
computer.

--
Regards,

Richard Urban

aka Crusty (-: Old B@stard :-)

If you knew half as much as you think you know,
You would realize that you don't know what you thought you knew!
 
No boot manager that usurps the MBR (master boot record) bootstrap area
will cooperate with a drive overlay manager which also usurps the MBR
bootstrap area. That is why many utilities will not cooperate with each
if they all are trying to overwrite the MBR bootstrap code. You cannot
use, for example, Powerquest (now Symantec) BootMagic with Symantec's
GoBack because both want to be in the MBR bootstrap area. If you actually
need to use the drive overlay manager, you'll need to find a boot manager
that does NOT use the MBR bootstrap area (which means it might requires
its own partition or share one).

Of the boot managers that I have used, all usurped the MBR bootstrap area
so, sorry, I cannot give a suggestion for one that resides wholly within a
partition. You might need to consider getting a new motherboard with a
newer BIOS that can actually support the large drives that you want to
use, or use an IDE controller card that has newer BIOS to support the
larger drives.

Xosl is a boot manager which can be installed in a dedicated partition.
However, it is not working for me regardless. It tends to get lost if I boot
from floppy or CD.

Teilhard.
 
I had a WD HDD80Gb fitted to my Pentium III PC at a computer store and it
took them 6 hours to format and set it up. I suspect that they used this
"overlay utlitity" that you mentioned (because another store tried and the
drive did not show up in My Computer). What is Overlay exactly, and why will
it "wreak havoc" in the computer. Can I check whether my HD was formated
using this Overlay Utility?Thanks for your post Richard.
 
If your computer does not physically support large hard drives (as per the
computer specifications), yet you are using a large hard drive - you likely
have a drive overlay installed in the MBR to allow that to occur!

--
Regards,

Richard Urban

aka Crusty (-: Old B@stard :-)

If you knew half as much as you think you know,
You would realize that you don't know what you thought you knew!
 
Teilhard Knight said:
Xosl is a boot manager which can be installed in a dedicated
partition. However, it is not working for me regardless. It tends to
get lost if I boot from floppy or CD.

Teilhard.


Some boot managers, like BootMagic, usurp the MBR bootstrap code and put
the rest of the program in a partition. You only get 512 bytes per
sector, the MBR is sector 0 in track 0 of the first physically
BIOS-detected drive, and the MBR includes the partition table and drive
signature bytes. The MBR bootstrap program can only be 460 bytes in
size. That is damn tiny and just enough to figure out how to read the
partition table to determine which one is the primary and active-marked
partition to then load into memory the first sector of that partition
(i.e., its partition boot sector) to begin loading the operating system.
BootMagic puts its tiny bootstrap program in the MBR bootstrap area
which then runs the rest of its program from whatever partition in which
it got installed. Some boot manager will usurp the rest of the unused
track 0 to provide additional space for their code rather than putting
it into some partition.

It sounds like XOSL might not use the MBR bootstrap area at all. There
wasn't any documentation at its Sourceforge site for me to know how it
operates. So my guess is that the standard bootstrap code is used in
the MBR (which, in your case, is the drive overlay manager) which loads
the program in the boot sector of whichever is currently the active
designated primary partition in the partition table in the MBR, which
then loads XOSL under whatever file system was used in that partition.

When booting from a floppy or CD, you are NOT using the bootstrap
program in the MBR of the hard drive that then loads the boot sector of
the active primary partition. You are using the boot program on the
floppy or CD instead, if they have one. You said XOSL won't cooperate
with using a drive overlay manager and that would only occur if XOSL was
attempting to usurpt the MBR bootstrap area where the drive overlay
manager already resides. It's been maybe 8 years, or more, since I had
to use a drive overlay manager and, at that time, it was for some
motherboards that were already 3 years old.

Since it appears that you must use the drive overlay manager to get the
full capacity of your hard drive(s) on an old motherboard, and since
that only runs from the hard drive's MBR bootstrap area so you can use
the partition's that got created under its geometric translation, we are
back to:

- Get a new motherboard with a BIOS that handles large drives.
- Get a controller card for your hard drives that has a BIOS to support
large drives.
- Use removable drive bays and put a different OS on each swap drive.
- Find a boot manager that NEVER touches the MBR bootstrap area (I don't
know of those).

Maybe there are other boot managers that instead usurp the boot sector
of the active primary partition listed in the MBR's partition table, or
simply loads DOS and then runs the boot manager as an application
started by the Run line in config.sys or loaded by autoexec.bat.
However, at that point, you could just use FDISK to change which was the
active primary partition and reboot to it. Even BootMagic's DOS-mode
PQboot can do that (same effect as using FDISK but simpler to use).
 
I suspected as much, but is there a way to check this (a diagnostic software,
for example, like Everest or Aida)?
What type of problems does this overlay create?
I want to be prepared "just in case".
Thanks again for any suggestions.

Regards
Anthony
-----------------------------
 
Rick "Nutcase" Rogers said:
Seconded.

--
Best of Luck,

Rick Rogers, aka "Nutcase" - Microsoft MVP

Associate Expert - WindowsXP Expert Zone

Windows help - www.rickrogers.org


Doesn't BootIt NG also usurp the MBR bootstrap area to insert its own
bootstrap program which then loads its manager in the EMBR (extended
MBR, which is the rest of unused track 0) to then update the partition
table back in the MBR? If so, it still conflicts when using a drive
overlay manager that also usurps the 460-byte bootstrap area of the MBR.

If you read http://www.terabyteunlimited.com/specs/embr2.pdf:

"The EMBRI resides in the MBR. It is the initial code responsible for
loading of the EMBR and EMBRL (EMBR Loader)."

The EMBR Loader is the boot manager program. However, the MBR bootstrap
area must still be usurped by a special program that will load the EMBR
Loader program, so the standard bootstrap program (provided by an OS
install) or the one for a drive overlay manager will get stepped on and
wiped out. Without the drive overlay manager, the OP won't have the
geometic translation needed (which his motherboard's BIOS doesn't
support) to access the full capacity of his large drive (plus he may not
be able to read anything in any partitions without the use of the drive
overlay manager's translation).

So it doesn't look like the OP can use BootIt NG, either, *if* he really
does need the drive overlay manager.
 
"Chris {MSXP Technical Support}" <Chris {MSXP Technical
Support}@discussions.microsoft.com> wrote in message
Hi Telihard the most widely used software for createing and matain
multi boot
systems would Partition Magic * there are many types of software for
this
process but this one seems to work the best, here is the link Good
Luck!

http://www.symantec.com/partitionmagic/


To clarify, PartitionMagic is NOT a boot manager program. It is a disk
management program to let you create, delete, resize, move, and convert
file systems for partitions on hard drives. It is a partition manager,
not a boot manager. However, it includes BootMagic.

BootMagic is a boot manager. However, it has problems in the form of
requiring a DOS-recognizable partition which means it must be a FAT
partition; see Symantec's article at
http://makeashorterlink.com/?D25016FCA. Because the bootstrap area in
the MBR is only 460 bytes in size, it is too tiny to hold the whole boot
manager program. So the rest of BootMagic gets read and executed from
whatever partition it is installed. However, BootMagic's bootstrap
program cannot read NTFS or non-DOS partitions to then read its
executable file from within the file system in that partition. So it
must be a DOS-recognized partition where the rest of BootMagic gets
installed. Because of this requirement, PartitionMagic comes in handy
to resize your current partitions so you have free space to create a DOS
partition that uses FAT for the file system where you can then install
BootMagic. Be careful not to create a new partition before your old
ones or you change their relative index number which is used in the
boot.ini file of Windows NT/2000/XP (which means it won't boot anymore
and instead error on startup).

The requirement for a FAT partition in which to install the rest of
BootMagic makes it a real pain to use in an old setup because of the
potential in changing partition numbering when adding the new
DOS-recognized partition. BootIt NG tries to alleviate that problem by
using the rest of the unused track 0 as the EMBR (extended master boot
record) where its boot manager program resides along with a swap table
of partition definitions. However, that still requires replacing the
MBR bootstrap program with one specifically designed for BootIt NG.
BootMagic usurps the MBR bootstrap area as well. The OP is using a
drive overlay manager which resides in the MBR bootstrap area, so using
BootMagic or BootIt NG will result in wiping out the drive overlay
manager and possibly ending up losing access to all his current
partitions (because the drive overlay manager's geometic translation is
no longer in effect) or corrupting his data in those partitions.

The OP needs to figure out how to get rid of the need for the drive
overlay manager.
 
Anthony said:
I had a WD HDD80Gb fitted to my Pentium III PC at a computer store and
it
took them 6 hours to format and set it up. I suspect that they used
this
"overlay utlitity" that you mentioned (because another store tried and
the
drive did not show up in My Computer). What is Overlay exactly, and
why will
it "wreak havoc" in the computer. Can I check whether my HD was
formated
using this Overlay Utility?Thanks for your post Richard.


It provides for the geometry translation needed to access the entire
capacity of the large hard drive that the BIOS cannot support. When you
boot and after the POST completes:

- The BIOS' bootstrap program looks for a bootstrap program on a drive.
In this case, only booting to a hard drive is discussed. The EEPROM
containing the BIOS firmware is limited in size so its bootstrap program
doesn't do a whole hell of a lot.
- The BIOS programs scans for a hard drive and loads the bootstrap
program in the first 460-byte area of the MBR (master boot record). The
MBR is the first sector of the hard drive and only 512 bytes in size, so
you can't code much in just the 460 bytes allotted (the other bytes are
for the partition table and drive signature bytes).
- After loading the MBR bootstrap program, the BIOS program relinquishes
control by starting execution of the MBR bootstrap program (and then the
BIOS program terminates).
- The "standard" MBR bootstrap program reads the partition table in the
MBR, determines which primary partition is marked "active". It then
loads the program in the first sector of that active primary partition
(the boot sector), relinquishes control by starting it, unloads itself,
and the boot sector program continues by loading the operating system in
that partition.

The drive overlay manager usurps the 460 bytes for the bootstrap area of
the MBR (i.e., it replaces the standard bootstrap program). The BIOS
doesn't have the logical geometric translation needed to support the
entire capacity of the large hard drive so this overlay program handles
the conversion. If you attempt to read a drive that used one geometric
translation in a machine that uses a different geometric translation,
the best that can happen is the other machine won't recognize your
partitions or their content but the worst is data corruption from
attempting to access the partition under a differing translation, like
using grammar rules for English when translating Russian to Japanese.

BootMagic, BootIt NG, and other boot managers will usurp the MBR
bootstrap area to insert their own program there. Well, that ends up
wiping out your drive overlay manager, you lose the full capacity of
your drive (because your BIOS doesn't support it), you lose access to
your partitions, and you might end up corrupting the data in those
partitions. Even using a partition manager when a drive overlay manager
is inuse could cause problems depending on whether the partition manager
recognized the use of the drive overlay manager. If, for example, you
booted using floppies to run PartitionMagic, the drive overlay manager
never got loaded and PartitionMagic making BIOS calls or directly
accessing the drive won't know the geometric translation used by the
drive overlay manager (but then you'll probably see errors in
PartitionMagic regarding unrecognized partitions or size problems).
 
Hi,

Yes, as you have already described, it does this. Thing is, many drive
makers still provide and user still install DO software when it is entirely
unnecessary. Fortunately, BING can deal with this when it takes over the
bootstrap, and it can be used to reload the drive to the designated OS.
This, among other reasons, is why I recommend it.

--
Best of Luck,

Rick Rogers, aka "Nutcase" - Microsoft MVP

Associate Expert - WindowsXP Expert Zone

Windows help - www.rickrogers.org
 
Some boot managers, like BootMagic, usurp the MBR bootstrap code and put
the rest of the program in a partition. You only get 512 bytes per
sector, the MBR is sector 0 in track 0 of the first physically
BIOS-detected drive, and the MBR includes the partition table and drive
signature bytes. The MBR bootstrap program can only be 460 bytes in size.
That is damn tiny and just enough to figure out how to read the partition
table to determine which one is the primary and active-marked partition to
then load into memory the first sector of that partition (i.e., its
partition boot sector) to begin loading the operating system. BootMagic
puts its tiny bootstrap program in the MBR bootstrap area which then runs
the rest of its program from whatever partition in which it got installed.
Some boot manager will usurp the rest of the unused track 0 to provide
additional space for their code rather than putting it into some
partition.

It sounds like XOSL might not use the MBR bootstrap area at all. There
wasn't any documentation at its Sourceforge site for me to know how it
operates. So my guess is that the standard bootstrap code is used in the
MBR (which, in your case, is the drive overlay manager) which loads the
program in the boot sector of whichever is currently the active designated
primary partition in the partition table in the MBR, which then loads XOSL
under whatever file system was used in that partition.

When booting from a floppy or CD, you are NOT using the bootstrap program
in the MBR of the hard drive that then loads the boot sector of the active
primary partition. You are using the boot program on the floppy or CD
instead, if they have one. You said XOSL won't cooperate with using a
drive overlay manager and that would only occur if XOSL was attempting to
usurpt the MBR bootstrap area where the drive overlay manager already
resides. It's been maybe 8 years, or more, since I had to use a drive
overlay manager and, at that time, it was for some motherboards that were
already 3 years old.

Since it appears that you must use the drive overlay manager to get the
full capacity of your hard drive(s) on an old motherboard, and since that
only runs from the hard drive's MBR bootstrap area so you can use the
partition's that got created under its geometric translation, we are back
to:

- Get a new motherboard with a BIOS that handles large drives.
- Get a controller card for your hard drives that has a BIOS to support
large drives.
- Use removable drive bays and put a different OS on each swap drive.
- Find a boot manager that NEVER touches the MBR bootstrap area (I don't
know of those).

Maybe there are other boot managers that instead usurp the boot sector of
the active primary partition listed in the MBR's partition table, or
simply loads DOS and then runs the boot manager as an application started
by the Run line in config.sys or loaded by autoexec.bat. However, at that
point, you could just use FDISK to change which was the active primary
partition and reboot to it. Even BootMagic's DOS-mode PQboot can do that
(same effect as using FDISK but simpler to use).

I have read all you have to say in this thread. I realize now I am damned
because none of the solutions you give me are feasible. I need the boot
manager for an old 486. Buying a new motherboard will cost more than the
machine itself. Also, I do not think I will be able to find an ISA card
which gives me access to the entire disk. Perhaps the only solution, as you
say is to select the bootable OS whenever I want to boot it. Problem is I do
not know whether I can boot into a logical partition (I'm running Linux).

Teilhard
 
Teilhard Knight said:
I have read all you have to say in this thread. I realize now I am
damned because none of the solutions you give me are feasible. I need
the boot manager for an old 486. Buying a new motherboard will cost
more than the machine itself. Also, I do not think I will be able to
find an ISA card which gives me access to the entire disk. Perhaps the
only solution, as you say is to select the bootable OS whenever I want
to boot it. Problem is I do not know whether I can boot into a logical
partition (I'm running Linux).


The standard bootstrap program in the MBR will not boot to logical
drives (in extended partitions). The bootstrap program can only select
among the primary partitions listed in the partition table because the
start of those partitions are known by the entries within the partition
table. For extended partitions, only the start of the partition is
known (as for primary partitions) but the start of the logical drive
within that extended partition is not defined in the partition table.

The standard bootstrap program can only load the first sector of a
partition (boot sector) for the primary partitions listed in the
partition table, and it picks the one that is marked "active". Also,
because the partition table only lists the partitions on that drive, you
cannot use the standard bootstrap program to boot to operating systems
residing in partitions on other drives. So, in your case, you will need
to put each operating system into a primary partition on the first drive
and in a primary partition. Note that some operating systems, like
Windows NT, will let you boot using a primary partition on the first
drive using the standard MBR bootstrap program but the OS loader files
in that first-drive active primary partition can read files on a
different drive in a different partition to continue loading the OS from
there (see http://support.microsoft.com/?id=314470; Microsoft's
terminology is backwards of what users would expect for the terms used
for those partitions). Basically:

- BIOS completes POST and looks for sector 0 (MBR) on first physically
detected hard drive.
- BIOS loads the program into memory from the first 460-bytes of the MBR
(i.e., the bootstrap program) and starts it.
- Bootstrap program reads the partition table looking for a primary
partition marked as "active". It loads sector 0 of that partition (boot
sector) into memory and starts it. This starts loading the OS.
- The boot sector program for the OS can then start its own loader
program and may even read files in other partitions or on other drives.
This is a mini-boot manager contained wholly within the partition (i.e.,
it does not usurp the MBR bootstrap area).

I don't know what your *NIX operating system has for features regarding
where it can be installed and if it can be spread across different
partitions across different drives by using a loader or mini-boot
manager program in its first booted partition. So while you might get
stuck having to use something like PQboot or FDISK to change which is
the active primary partition on the first drive, that may only determine
where the loader files are located for the OS and the OS could possibly
span onto a different partition or even a different drive.
 
Back
Top