Otto -I think you are missing the big picture here and
Ashley can confirm it or
disprove me -
1 - this system had two IDE drives in it at Linux
installation time.
A (the MASTER) and B (The Slave), There is no SCSI, NO
RAID, no LVM.
just a simple plain vanilla LINUX setup.
2 - Linux was installed in its entirety along with grub as
the
boot loader onto Drive A
3 - NOTHING was loaded onto Drive B at time of linux
installation.
4 - Drive B was later used to store files and such.
5 - GRUB NEVER used any part of DRIVE B at any time during
it's lifetime It ONLY used
the contents of DRIVE A to boot from.
6 - DRIVE B Crashed. Upon removal of drive b from the ide
chain, Ashley found HIMSELF
with a totally unbootable system for absolutely no sane
reason. The only drive he needed
for booting was Drive A which was still intact.
7 - this is proven by the addition of a replacement BLANK
Drive
B which then cured his system.
8 - GRUB is not trying to load anything from Drive B. The
Phase one half of GRUB ,
stored on the boot block of Drive A (MBR), can not find the
Phase 1.5 part of Grub
also stored on drive A because it's concept of
where that information is stored has been altered by the
ROM BIOS's changed perception
of the drive layout info for Drive A. This changed
perception , probably the
address of the drive or its geometry, is being caused by the
changes in
the drive select jumpers required by DRIVE A
when a SLAVE drive is removed or added onto the chain.
9 - The system can ALWAYS load the MBR because it is always
on BLOCK 0
or Cylinder Track and Sector 0
on the disk drive. It is a known fixed location which does
not change
even if drive geometrys are changed. The ROM BIOS on the
Motherboard loads
this single disk block into RAM and executes it.
It prints out "GRUB" to let you know it is there, then
attempts to locate the /boot partition start on the hard
drive to load Phase 1.5 which is the real OS Bootstrap
program.
10 - The MBR "KNOWS" where phase 1.5 is because the location
of the start of the
the /boot partition and phase 1.5 is HARDCODED into the MBR
program when it is
built and placed on the boot block.
The MBR merely know to go some far into the disk and read.
If You change the offset of /boot on the harddrive
by resizing the parition spaces between cylinder 0 and where
ever /boot originally started at
you trash the MBR's ability to find Phase 1.5 for the same
reason - you relocated Phase 1.5
on the drive and did not tell the MBR. The MBR uses the same
IO code the DOS bootstraps
use and has their same constraints about maximum Logical
block or
CTS values.
11 - the issue here is that somehow removing the drive b and
changing the drive select
on DRIVE A changes
where everything but where block 0 is located on the disk
drive. I dont know why, have
not read the GRUB sources or how as
I cant see his machine - his drives would normally be
LOGICAL BLOCK ADDRESSED,maybe
CTS addressed, but somehow, and only Ashley can figure this
out, the BIOS view of
the drive changes when he changes the drive select jumper.
And it is the BIOS DISK IO routines
that are normally used by the MBR boot strap to read the
disk contents.
The MBR is a sector long program which means at best it can
be 512 bytes long.
Lets take this to a CTS (Cylinder TRACK and SECTOR) View of
the hard drive -
I dont know if you program, but if you do -
View CTS as indices into a three dimensional Matrix. The
base address of the matrix
is always at the same address no matter what.
Think of Cylinders are Rings on a Tree, Tracks as fixed
horizontal slices
through the tree (like slicing a banana,) and sectors as pie
slices across DIVIDING UP
the surface OF A SINGLE TRACK and replicated down through
all the tracks
Boot Block/MBR - LOCATED at CTS 0-0-0 array[0][0][0]
Phase 1.5 bootstrap located at CTS 50-0-10 to 50-129-16, 50
cylinders
into the hard drive. array[50][129][10] is the start
The drive's geometry is currently 1024 cylinders, 256 tracks
per cylinder
and 512 sectors per track. array is of dimension
[1024][256]512]
IDE drives have had the ability to remap
the same physical disk geometry into many virtual disk
geometries.
If we shift the the drive via internal map settings OR
through manual
configuration tell the ROM BIOS that this disk is now say
512 cylinders,
512 tracks per cylinder and 512 sectors per track, CTS
50-129-10 will no longer
be addressed by the drive to the same physical location on
the disk.
array is now dimensioned as [512][512][512]. what was at
50-0-10 is not there
now, ITS PROBABLY NOW ADDRESSED AS 100-129-10.
(A SINGLE LOGICAL CYLINDER ON THE DISK MAY NOW BE COMPOSED
OF TWO
ADJACENT PHYSICAL CYLINDERS)
The ISSUE - THE MBR is hardcoded with the 50-0-10 address
and does not know to
double the cylinder count to get to where it needs to be.
This is one possibility, the other is that the MBR has a
base address to the drive controller
itself that references nothing once the drive select jumpers
change to BIOS's
idea of what the drive controller address should be. The
disk used to be IDE1DriveM,
now its IDE1DriveOnly. The mbr still is looking for
IDE1DriveM
which no longer exists.
The bottom line is his issue is not with GRUB, but with his
motherboard and the particular drives he is using.
The cure may lie in a FIRMWARE upgrade or in finding a way
to regenerate the MBR
in the new configuration in the same manner
as it is created during the install process. to reset the
now incorrect
references to their new equivalents.
THe Phase 1 MBR cant find the phase 1.5 piece not because it
is on DRIVE B
but because it is now looking in the wrong space on drive A
because the perception of
drive A has changed either in it's address it's layout so
the ROM BIOS routines
essentially read the wrong information off the drive (say
the contents of /etc/passwd
instead of the phase 1.5 bootstrap program and then try to
execute non-code and crash.
You would have to play with his system and GRUB to figure
exactly what has
changed. One can only guess otherwise.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Otto
Haliburton
> Sent: Sunday, August 03, 2003 5:13 AM
> To: [EMAIL PROTECTED]
> Subject: RE: GRUB failure
>
>
>
> Hi all,
> We have all been ignoring one fact and that is for some
reason
> GRUB is loading part of the boot loader on the second
drive. It
> apparently thinks that linux is on the second drive. A
> setup where the
> boot loader is on the MBR of drive A but linux is on
drive B
> so that the
> boot is A -> B -> A. Ashley while I believe you when you
> say that there
> is nothing on drive B would you post a fdisk listing of
partitions on
> drive b. In the meantime, you can remove drive b and
boot
> from floppy
> and then reinstall GRUB with B removed from the system
and note any
> error messages that install prints when this occurs
because either it
> will install successfully or it will fail with error
messages.
>
> To those of you, who have the theory that GRUB is
loading stage1
> and can't load stage2 answer the question, "how it can
find
> stage1 and
> then can't find stage2?", when both are in the same GRUB
> directory. It
> can not find the GRUB directory period.
>
>
> --
> 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
