By your response you have failed to read the GRUB manual. I will say no further until you read it. Some points I will concede up to 11. Stage 1 is hard coded in the mbr or track 0. It is 512 bytes. It loads stage1_5 which can be located behind the MBR or in "boot" partition or it loads part of stage2 partition which when loaded will load itself fully. As far as changing the disk geometry and etc. GRUB was designed to handle any such situation and that's why you need to read the manual that I pointed to in a later email.
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:redhat-list- > [EMAIL PROTECTED] On Behalf Of Kenneth Goodwin > Sent: Monday, August 04, 2003 11:18 AM > To: [EMAIL PROTECTED] > Subject: RE: GRUB failure > > 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 -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
