Otto we are not on the same page, perhaps this will help.
This is (perhaps) my
(MIS)Understanding that from having written and worked with
such bootloaders
but not personal expertise with GRUB That Grub is organized
in a manner such as -
Phase 1 - Grub MBR 512 byte initial boot loader - knows how
to get to Phase 1.5 only.
Phase 1.5 - Grub OS Loader Part one (OS filesystem
selector) Knows? os fs structures
Phase 2 - Grub OS Loader Part Two (OS loader, knows
particular OS FS structures)
Phase 1 the GRUB MBR DOES NOT KNOW THE OS FILE STRUCTURES.
It is too small a program to hold that level of knowledge
It deals in RAW DISK ONLY through the ROM BIOS disk IO code
mechanism.
Loaded and executed by the ROM BIOS boot strap code.
GRUB Phase 1.5 and/or Phase 2.0 IS the piece of GRUB That
knows about the
OS File structures, etc as you have stated. loaded and
executed by Grub MBR/Phase 1/
Mike and I are working on the Premise that Phase 1 (MBR) can
not find the Phase 1.5 (OSFS)
image on DRIVE A in order to load it. The drive and offset
info are hard coded low
level device references from a HARDWARE, not OS perspective,
IE. IT does not
know what a /dev/hda is. It only knows "select Drive 0,
Start loading 20 sectors starting
at LBA 14,208 (or Cylind 10, track 5, sector 4) into low ram
and execute the program.
The initial fresh GRUB INSTALL stuffs Phase 1.5/Phase 2
images into /boot, converts
their partition relative locations into physical drive
offsets and stores the info the MBR needs
into the MBR image when it builds them.
What we are trying to say is that something happens when
Ashley removes the drive such that
the BIOS and/or the Hard Drive A no longer maps to either
Drive 0 or the
Image being at LBA 14,208. Therefore the MBR Phase One boot
loader
fails to be able to load in the Phase 1.5 Loader.
However this is an ASSUMPTION, we could be loading in Phase
1.5 and dieing
before it spits out any text. But Mike is not seeing
any output from Ashley's tests that would indicate that
Phase 1.5 actually loaded.
We are not executing the piece of Grub that needs to know
about FS structures or OS
versions at this point, just the piece that loads that
piece.
the device.map has no references to /dev/hdb.
The scsi devices are in the same state as when he had a
single drive
and the original two drive setup.
The only variable is the addition or removal of drive B and
reconfiguring
the Drive A drive select jumper from Master-Slave to Single
drive configurations.
So the question becomes why does the removal of a single
drive not related to
the boot process cause the boot process to fail?
Unless we can prove that Phase one is successfully loading
Phase 1.5 and that phase 1.5
is actually failing, we can only go on the assumption that
Phase 1, the MBR, is failing to
load Phase 1.5 into memory. The only reason this type of
failure would happen
if Suddenly the hard coded device references in the MBR no
longer map as they should
to either the drive's ide bus address or if the stored
LBA/CTS information no longer
maps to the same physical disk area because something in the
BIOS that tells the MBR/BIOS
disk io routines what the drive looks like and how to read
data off of it
has changed. So the MBR actually reads the wrong disk blocks
off the hard drive
and grub then crashes trying to execute an invalid Phase 1.5
image.
In any case, this is really a dead thread at this point,
being all theory
and no real proof. If Ashley wishes to persue
this for the common good, he needs to take all of this to
the Grub Developers
Group and have them help him figure out what is really going
on here.
It may be an issue that may need to be addressed in a future
Grub Version release
so that no one else gets burnt Grub in the future.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Otto
Haliburton
> Sent: Monday, August 04, 2003 1:00 PM
> To: [EMAIL PROTECTED]
> Subject: RE: GRUB failure
>
>
> This is why you need to read the manual. GRUB does know
the file
> structures for the OS it boots the kernel for otherwise
it
> chain loads
> the boot loader for the other OS's. Remember what GRUB
stands for.
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:redhat-list-
> > [EMAIL PROTECTED] On Behalf Of Kenneth Goodwin
> > Sent: Monday, August 04, 2003 11:51 AM
> > To: [EMAIL PROTECTED]
> > Subject: RE: GRUB failure
> >
> > > >
> > > > BIOS loads and starts the code from master boot
record,
> > but code in
> > > > MBR fails to load stage1.5 which is located at a
fixed
> > position on
> > > > hda. At that point, GRUB does not even know about
> > > "directories" yet,
> > > > since it is this later stage that would give
native
> > access to ext2
> > > > fs. The reason that GRUB fails to access hda can
be
> > that
> > > BIOS uses a
> > > > different method to access the drive, while GRUB
maybe
> > gets a wrong
> > > > drive Id and hence fails to find hda.
> > > >
> > > > However, Ashley has mentioned that this computer
has
> > been working
> > > > fine with a single drive for several months until
hdb
> > was added.
> > > > Only when hdb was removed, it started to
malfunction.
> > So, if it's
> > > > not a BIOS thing that confuses GRUB, I don't see
why
> > GRUB
> > > would fail
> > > > loading from hda.
> > >
> > > You haven't gotten the point of the question. GRUB
is in
> > > the MBR from
> > > the install. It has a location to get to the GRUB
> > directory to load
> > > stage1 (we know that stage1 and stage2 and all other
> > things
> > > are in the
> > > GRUB directory look them up yourself). So it
locates the
> > > GRUB directory
> > > to load stage1 then why would it now lose that
location
> > to
> > > load stage2.
> >
> >
> > GRUB MBR DOES NOT KNOW LINUX DIRECTORY STRUCTURES
> > GRUB MBR DOES NOT KNOW EXTFS Filesystems
> >
> >
> > ALL IT KNOWS is an PHYSICal offset into the disk to
start
> > reading from and a count
> > of bytes to read. This is very low level stuff. where
it is
> > reading from on the drive
> > is not where the phase 1.5 is. (Or phase 1.5 is having
a
> > similiar issue itself
> >
> >
> > --
> > redhat-list mailing list
> > unsubscribe
mailto:[EMAIL PROTECTED]
> https://www.redhat.com/mailman/listinfo/redhat-list
--
redhat-list mailing list
unsubscribe
mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list
--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list
