Re:: GRUB failure
Ashley M. Kirchner wrote: This was posted in a precious email. Yes. *previous* -- H| I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
On Mon, Aug 04, 2003 at 12:33:26PM -0600, Ashley M. Kirchner wrote: Otto Haliburton wrote: I have a dual boot system with HDA containing XP PRO and RH9 on HDB GRUB is the boot loader and it is written to the MBR or HDA along with the XP boot loader. I just removed HDB and guess what I got a black screen with GRUB in the left hand corner. Welcome to my world. At that point in the game, I doubt it even knows about hdb, to even go find the config file. It read the MBR, and ... fell off the planet. Hi, Ashley. Sorry to butt my head in so late. When you yanked the 2nd drive, did you go into the BIOS and tell it that it no longer exists? -- Jack Bowling mailto: [EMAIL PROTECTED] -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
Jack Bowling wrote: Hi, Ashley. Sorry to butt my head in so late. When you yanked the 2nd drive, did you go into the BIOS and tell it that it no longer exists? This was posted in a precious email. Yes. -- H| I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
Last time around. It appears that stage2 never gets called nor stage1_5 (I don't even see how it gets setup to call, but if it were called it definitely prints a message GRUB is loading). Also it appears that there is no error in stage1. So I don't believe that Ashley's problem is with GRUB at all. Stage1 is called with the boot, checks all of its parameters and then long jumps to a stage2(which it can't find in memory even though it thinks it read it in correctly). This leads me to believe that block offset for stage2 has changed (probably due to removing hdb) but there is a wild possibility that it was never correct and purely by coincidence it loaded a correct values when hdb was loaded(being a software type this definitely has happened to me before and it blows my mind) It possibly was loading offsets from hdb that were correct for the location of stage2 or something similar. The other thing is that the bios is outdated for the GRUB you are using. In any case the problem is to force GRUB to load correctly with hdb not there. my suggestion is to 1) make a boot disk. 2)(optional) get the latest and greatest GRUB software. There may have been a update to match your bios. 3) follow the procedure in the GRUB manual to manually load GRUB. Specifically with hdb removed and when you are boot from your boot floppy. Also remember to do the cd /sysroot thing to access your hda drive properly for the floppy(I don't use this often and I don't remember the command correctly). you can activate the grub shell. Its should be in sbin on hda and let it do a find on stage 2. The procedure is in the manual. Good luck!!! -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
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. Otto, you may be missing this point.. Grub isn't loading anything. Bios is loading the MBR from the drive. this mbr.. part of grub is being called stage 1. with the additional info from Mr. Kirchner, that the board has scsi interface on board, I wonder if it also has a self modifying portion in its cmos... (I've seen a couple of these) where it keeps track of the scsi devices and bootability. When there are two devices on the ide interface, one of the first two is the boot device, when only one ide is present then the search in bios continues on to the scsi interface. If the scsi interface has something it has ever registered, this may be seen as another bootable device, or in some other way change the base addressing of the drives. Linux doesn't use bios to access the drives past the initial bootloader stages, and thus could ignore bios addressing problems if booting from floppy, (or cd), because it doesn't have to go to the hard drive for booting. If there are two ide devices, the bios shouldn't (yes I know there are new ones not following these old guidelines) even look at the scsi interface in search of boot points. this posibility could be tested if there were a utility to reset the scsi device tables, or even just to read them. Oh well, now that its a moot point. I'll never have my curiosity satisfied (good thing I'm not a cat!) brian :) ;} ** --- [EMAIL PROTECTED] -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
brian davison wrote: with the additional info from Mr. Kirchner, that the board has scsi interface on board, I wonder if it also has a self modifying portion in its cmos... (I've seen a couple of these) where it keeps track of the scsi devices and bootability. Good theory, except I have the SCSI bus disabled in BIOS, so it's not scanning it. At least, it *shouldn't* be. -- H| I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
Otto, you may be missing this point.. Grub isn't loading anything. Bios is loading the MBR from the drive. this mbr.. part of grub is being called stage 1. Yes, this is correct if you read the latter parts of the manual that I published then you know that stage1 is 512 bytes long so it doesn't do much except either load stage1_5 or stage2. but in the manual it listed the error messages from each stage and the output reported doesn't fall into any of the categories reported. And it also rules out any geometry change, etc... The possibility it left open is that it is not able to resolve how the bios reports the disk so it guesses and then uses it device map to resolve the issue and it says it can be quite wrong about this guess. So I'm suggesting that everyone reload, read the manual and go from there. Also I'm noting Ashley's response to this email. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
BTW -- Life is not an exact science, but only an approximation. If it was an exact science then we all would be unhappy because of our own imperfections -Original Message- From: [EMAIL PROTECTED] [mailto:redhat-list- [EMAIL PROTECTED] On Behalf Of Otto Haliburton Sent: Monday, August 04, 2003 2:42 AM To: [EMAIL PROTECTED] Subject: RE: GRUB failure Otto, you may be missing this point.. Grub isn't loading anything. Bios is loading the MBR from the drive. this mbr.. part of grub is being called stage 1. Yes, this is correct if you read the latter parts of the manual that I published then you know that stage1 is 512 bytes long so it doesn't do much except either load stage1_5 or stage2. but in the manual it listed the error messages from each stage and the output reported doesn't fall into any of the categories reported. And it also rules out any geometry change, etc... The possibility it left open is that it is not able to resolve how the bios reports the disk so it guesses and then uses it device map to resolve the issue and it says it can be quite wrong about this guess. So I'm suggesting that everyone reload, read the manual and go from there. Also I'm noting Ashley's response to this email. -- 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
RE: GRUB failure
Ashley Are the drive Manufacturers different? Although EIDE is supposed to be a standard manufacturers will tend to do their own thing in regards to jumpers and how things behave. You could be running into such an issue here and it will affect how the drives respond on the control line/ide-cmd responses to the BIOS reset and query sequences. You see on a normal EIDE drive, you should have either had to change jumpers to single drive mode or leave it as master. It should not impact what the drive looks like or is addressed as being the master. The jumpers control only the drives behaviour in response to the drive select lines. In any case, the consensus seems to be at the moment, that the issue here is how the BIOS perceives the layout and/or addressing for your master drive when you change configurations between master-slave and single drive setups. It seems to be a BIOS or drive firmware issue. There may be nothing you can do to cure it. Using drives from the same manufacturer may help as it is the drives that interact based on master slave. The controller just turns on a drive select bit hooked to a control cable lead usually to select one or the other drive. -the drives/jumpers determine who responses as master or slave. with the same manufacturer you can generally be assured that the drives will behave in the same way. Your A drive is apparently a model in which the drive has to BE Single, Master or Slave some drives allow for MAster to also be the definition for single On top of this your MB bios seems to have a feature by which it's on board ide controllers treats a single drive setup differently from a dual drive setup, changing the perceive drive addressing enough to confuse grub phase 1 The only real concrete suggestion possible here is to make sure your motherboard and the drives ide controller firmware are all up to the latest revision levels. Dont assume just because you bought it a short tiem ago it will be because it might have been on the shelf for a year and be down two revisions from the current level. there might be a way to get grub to rebuild it's MBR boot strap based on the single drive configuration if you setup a floppy/cdrom boot program to do that. short of a partial reinstall of Linux restricted to just the MBR -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ashley M. Kirchner Sent: Sunday, August 03, 2003 4:37 AM To: [EMAIL PROTECTED] Subject: Re: GRUB failure brian davison wrote: Ashley... try not changing the drive to single... leave it as the Master. ( as in don't change the jumper when removing the second drive) No can do. hda has three settings on it: Master, Master w/ Slave, and Slave. Since hdb was installed, it's been set to Master w/ Slave (leaving it as Master resulted in hdb not being detected by the BIOS.) Consequently, removing hdb without changing the jumper on hda resulted in the machine not booting because the BIOS expected a slave since hda's jumper was set as such. Mind you, I've played with this a whole lot already, and it just doesn't work with just leaving the jumper alone and not changing it. If I leave it set to Master, the BIOS won't see hdb. If I leave it on Master w/ Slave, the BIOS complains about not seeing a slave (when hdb gets removed.) So I had to change that anyway. PS: Ashley's a guy. -- H| I haven't lost my mind; it's backed up on tape somewhere. +--- - Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- 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
RE: GRUB failure
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
RE: GRUB failure
- set hda's jumper back to master otherwise BIOS complains and won't boot - shoved floppy in, booted up just fine - ran grub-install /dev/hda, no errors - removed floppy, reboot - BIOS finds hda, knows there's no hdb, goes on to boot - black screen, with 'GRUB' in the corner: system dead I ran the same cycle again, this time issuing: grub-install --root-directory=/boot '(hd0)' as the info page suggests. Same result, won't boot, dead system. ASHLEY - Your grub issue may be that grub-install may only install an already compiled and loaded version of the MBR phase one piece. YOU MAy have to do a GRUB Make to rebuild the MBR piece with the new system architecture taken into account.. Ie you were just installing the same MBR as the existing one, when what you need to do is build a new single drive version of the MBR and install that. In a standard MAKE environment, Make install only rebuilds the executables if the sources they depend on have changed. otherwise they just install the compiled binary image already in the directory from the last full build. In your case, you need to do the GRUB equiivalent of a Make clean which purges all the binarys and the executables and then a make install to built the new binaries and install them. Michael S may know how to direct you there as he seems to have more grub expertise than I and may know the rebuild from scratch commands required. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
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
RE: GRUB failure
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. 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. I would presume when he added in the second drive, Anaconda or something similiar came along and made the necessary internal reference adjustments for the drive changes that occured. maybe its not smart enough to back them out when he pops the drive out. Maybe its 1.5 that fails before it prints out a message? In any case, talking is not going to find the cause, He would need to debug it with grub itself and playin garound with things and it is a moot point to Ahsley for the moment as his system is now operational again. It would nice to know what the cause is so fixes could be implemented for future considerations. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 4 Aug 2003 12:26:05 -0400, Kenneth Goodwin wrote: ASHLEY - Your grub issue may be that grub-install may only install an already compiled and loaded version of the MBR phase one piece. YOU MAy have to do a GRUB Make to rebuild the MBR piece with the new system architecture taken into account.. Ie you were just installing the same MBR as the existing one, when what you need to do is build a new single drive version of the MBR and install that. In a standard MAKE environment, Make install only rebuilds the executables if the sources they depend on have changed. otherwise they just install the compiled binary image already in the directory from the last full build. In your case, you need to do the GRUB equiivalent of a Make clean which purges all the binarys and the executables and then a make install to built the new binaries and install them. Michael S may know how to direct you there as he seems to have more grub expertise than I and may know the rebuild from scratch commands required. I think this goes too far, and I don't see what it would change. IIRC, it has been mentioned that grub-install works flawlessly when slave drive is available and even when slave drive is removed and system is booted with bootdisk. However, the newly written GRUB then fails in MBR as soon as slave drive is not available. How about trying LILO just to see how it behaves? Install the lilo package, create /etc/lilo.conf, probably like this, boot=/dev/hda lba32 prompt timeout=10 default=linux image=/boot/2.4.20-18.7smp initrd=/boot/initrd-2.4.20-18.7smp.img label=linux read-only root=/dev/hda1 then install with lilo -v. Might be interesting. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Lo+P0iMVcrivHFQRAkDTAJ9KwpBYembnoJqP1Fk7yAygOf6KrwCeN8n8 FR9opvjhrjsejWelnEjDIyE= =OTLU -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
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
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
RE: GRUB failure
I think this goes too far, and I don't see what it would change. IIRC, it has been mentioned that grub-install works flawlessly when slave drive is available and even when slave drive is removed and system is booted with bootdisk. However, the newly written GRUB then fails in MBR as soon as slave drive is not available. this was in response solely to Ashleys GRUB_INSTALLS not apparently having an effect - this is only a theory, but it seems a reasonable explanation frogive me if I am redundant here what I am saying is that the MBR may be crafted or rebuild by anaconda for the two drive setup disk info. Anaconda may not be able to go backwards here, may not be able to undo in a return to single drive configuration - most people add hardware, not remove it, it may have not been a tested situation. Something changed on the linux system in response to the addition of the hard drive that is not being undone when he reboots with only one drive installed. If the contents of the MBR in regards to the location of the Phase 1.5 image are the real issue here, then replacing it with a freshly rebuilt version would be required in order to correct the issue. Grub-install. which I have not seen admittedly, may be based on a MAKE environment strategy. IF SO IT ONLY REBUILDS The MBR if and only if some local disk file has changed that a dependency has been declared for. It may not check to see if the hardware environment changed. By cleansing out the existing config info via a MAKE CLEAN or CLOBBER sequence , you should force it to do a fresh rebuild from scratch on the MBR program which should insert the new single drive related information. ie SO FAR your newly written grub is the same image as the old grub that was on the mbr to begin with. You may have changed nothing by running grub-install in regards to the MBR image on sector 0. Ashley just rewrote the same 512 byte block over and over again. To rephrase, What I am saying is the copy of the MBR on drive A is the same as the copy of the MBR image on /boot that grub-install stuffs back onto the MBR, so all the grub installs changed nothing, just rewrote the same info over and over again unchanged for the new single drive configuration he was trying to configure for.. Popping the hard drive on/off changes the underlying hardware/bios info such that it matched/did not match the contents of the MBR. So it worked any time he had the drive configuration matching the corresponding info in the MBR. One would need to rebuild the MBR based on the new single drive architecture to correct this issue - recompile from sources as it were after booting to a single drive setup. The boot floppy does not use the MBR, It is the MBR and probably phase 1.5 as well all rolled into one. So if you boot from it, you will boot linux from /boot directly then do your grub-install which may just be writting the same 512 byte image into the MBR as IS ALREADY THERE. I hope this is now clear -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 4 Aug 2003 13:39:54 -0400, Kenneth Goodwin wrote: what I am saying is that the MBR may be crafted or rebuild by anaconda for the two drive setup disk info. It's grub-install/grub that creates stage1 based on the grub.conf created by anaconda. Grub-install. which I have not seen admittedly, may be based on a MAKE environment strategy. IF SO IT ONLY REBUILDS The MBR if and only if some local disk file has changed that a dependency has been declared for. It may not check to see if the hardware environment changed. By cleansing out the existing config info via a MAKE CLEAN or CLOBBER sequence , you should force it to do a fresh rebuild from scratch on the MBR program which should insert the new single drive related information. ie SO FAR your newly written grub is the same image as the old grub that was on the mbr to begin with. You can get rid of the generated files like this, preferably after removing slave drive and after booting with boot disk: rm /boot/grub/*1_5 /boot/grub/stage* grub-install --recheck --force-lba /dev/hda Option --force-lba might be interesting. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Lp7Y0iMVcrivHFQRAoFkAJ0Z9nIV5jhIQgnmpDLuoJrbg43CgQCfcEWT LMknoC8k84oEiBhxdCtWxb0= =y8mK -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
Kenneth Goodwin wrote: 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. Nope. The machine had ONE drive upon installation. hdb wasn't added till months later and was used only for storage of backup files (it doesn't even stay mounted all the time.) This was explained in a previous email. -- W | I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
I have a dual boot system with HDA containing XP PRO and RH9 on HDB GRUB is the boot loader and it is written to the MBR or HDA along with the XP boot loader. I just removed HDB and guess what I got a black screen with GRUB in the left hand corner. -Original Message- From: [EMAIL PROTECTED] [mailto:redhat-list- [EMAIL PROTECTED] On Behalf Of Michael Schwendt Sent: Monday, August 04, 2003 12:59 PM To: [EMAIL PROTECTED] Subject: Re: GRUB failure -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 4 Aug 2003 13:39:54 -0400, Kenneth Goodwin wrote: what I am saying is that the MBR may be crafted or rebuild by anaconda for the two drive setup disk info. It's grub-install/grub that creates stage1 based on the grub.conf created by anaconda. Grub-install. which I have not seen admittedly, may be based on a MAKE environment strategy. IF SO IT ONLY REBUILDS The MBR if and only if some local disk file has changed that a dependency has been declared for. It may not check to see if the hardware environment changed. By cleansing out the existing config info via a MAKE CLEAN or CLOBBER sequence , you should force it to do a fresh rebuild from scratch on the MBR program which should insert the new single drive related information. ie SO FAR your newly written grub is the same image as the old grub that was on the mbr to begin with. You can get rid of the generated files like this, preferably after removing slave drive and after booting with boot disk: rm /boot/grub/*1_5 /boot/grub/stage* grub-install --recheck --force-lba /dev/hda Option --force-lba might be interesting. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Lp7Y0iMVcrivHFQRAoFkAJ0Z9nIV5jhIQgnmpDLuoJrbg43CgQCfcEWT LMknoC8k84oEiBhxdCtWxb0= =y8mK -END PGP SIGNATURE- -- 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
RE: GRUB failure
This is different from the setup Ashley has but the results are the same. I don't exactly know what that means but it certainly means something. -Original Message- From: [EMAIL PROTECTED] [mailto:redhat-list- [EMAIL PROTECTED] On Behalf Of Otto Haliburton Sent: Monday, August 04, 2003 1:25 PM To: [EMAIL PROTECTED] Subject: RE: GRUB failure I have a dual boot system with HDA containing XP PRO and RH9 on HDB GRUB is the boot loader and it is written to the MBR or HDA along with the XP boot loader. I just removed HDB and guess what I got a black screen with GRUB in the left hand corner. -Original Message- From: [EMAIL PROTECTED] [mailto:redhat-list- [EMAIL PROTECTED] On Behalf Of Michael Schwendt Sent: Monday, August 04, 2003 12:59 PM To: [EMAIL PROTECTED] Subject: Re: GRUB failure -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 4 Aug 2003 13:39:54 -0400, Kenneth Goodwin wrote: what I am saying is that the MBR may be crafted or rebuild by anaconda for the two drive setup disk info. It's grub-install/grub that creates stage1 based on the grub.conf created by anaconda. Grub-install. which I have not seen admittedly, may be based on a MAKE environment strategy. IF SO IT ONLY REBUILDS The MBR if and only if some local disk file has changed that a dependency has been declared for. It may not check to see if the hardware environment changed. By cleansing out the existing config info via a MAKE CLEAN or CLOBBER sequence , you should force it to do a fresh rebuild from scratch on the MBR program which should insert the new single drive related information. ie SO FAR your newly written grub is the same image as the old grub that was on the mbr to begin with. You can get rid of the generated files like this, preferably after removing slave drive and after booting with boot disk: rm /boot/grub/*1_5 /boot/grub/stage* grub-install --recheck --force-lba /dev/hda Option --force-lba might be interesting. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Lp7Y0iMVcrivHFQRAoFkAJ0Z9nIV5jhIQgnmpDLuoJrbg43CgQCfcEWT LMknoC8k84oEiBhxdCtWxb0= =y8mK -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:redhat-list- [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
Re: GRUB failure
Kenneth Goodwin wrote: what I am saying is that the MBR may be crafted or rebuild by anaconda for the two drive setup disk info. Anaconda may not be able to go backwards here, may not be able to undo in a return to single drive configuration - most people add hardware, not remove it, it may have not been a tested situation. Something changed on the linux system in response to the addition of the hard drive that is not being undone when he reboots with only one drive installed. This never occurred to me till now, but...the only time anaconda ran and did anything, was when the system was first installed. Both anaconda and kudzu get removed after installation. I run a tight ship, and don't like having packages installed that aren't needed for daily operations, so they go. When I added the second drive months later, what would cause any kind of configuration being redone, or whatever config file rewritten (other than me manually running fdisk and mkfs.ext3)? -- W | I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
Otto Haliburton wrote: I have a dual boot system with HDA containing XP PRO and RH9 on HDB GRUB is the boot loader and it is written to the MBR or HDA along with the XP boot loader. I just removed HDB and guess what I got a black screen with GRUB in the left hand corner. Welcome to my world. At that point in the game, I doubt it even knows about hdb, to even go find the config file. It read the MBR, and ... fell off the planet. -- W | I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
Welcome to my world. At that point in the game, I doubt it even knows about hdb, to even go find the config file. It read the MBR, and ... fell off the planet. -- You've never said (that I can remember ) what version of RH you are running. If it is an old version then you may not be running the new version of GRUB. But in the manual there is a procedure you can thru to manually reinstall GRUB interactively. The manual says that stage1 does some things before it calls stage1_5 or stage2. Also I want to note that it is not a foregone conclusion that it calls stage1_5. So we don't know how far it gets into the process, it seems it would print an error message if it discovered something which makes me think it just branches off to never, never land. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
Otto Haliburton wrote: You've never said (that I can remember ) what version of RH you are running. 7.3 Also I want to note that it is not a foregone conclusion that it calls stage1_5. So we don't know how far it gets into the process, it seems it would print an error message if it discovered something which makes me think it just branches off to never, never land. I prefer Lalaland. -- W | I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 04 Aug 2003 12:33:26 -0600, Ashley M. Kirchner wrote: Otto Haliburton wrote: I have a dual boot system with HDA containing XP PRO and RH9 on HDB GRUB is the boot loader and it is written to the MBR or HDA along with the XP boot loader. I just removed HDB and guess what I got a black screen with GRUB in the left hand corner. Welcome to my world. At that point in the game, I doubt it even knows about hdb, to even go find the config file. It read the MBR, and ... fell off the planet. Great! It's reproducible on another machine. Now, if Otto is good, he modifies the short assembler code of stage1 and inserts a debug string to confirm that stage1 fails at the end of copy_buffer where it executes the loaded stage2. Stage1 starts with GRUB and certain error conditions given, it prints only a very few and short error messages. If it doesn't print an error message, it has loaded and jumped into stage2 either with LBA or CHS geometry. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Lq5v0iMVcrivHFQRAsPxAJ94QxAvwlpOroJYuH3yDyYYmY9DnQCfY5pk q4cACFIXuiDiY8ICk9qZrZA= =8V5w -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
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
Re: GRUB failure
Michael Schwendt wrote: If it doesn't print an error message, it has loaded and jumped into stage2 either with LBA or CHS geometry. I'm curious, where does stage1_5 come into play, if what you're suggesting is that it jumps from stage1 to stage2? -- W | I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 04 Aug 2003 13:06:19 -0600, Ashley M. Kirchner wrote: If it doesn't print an error message, it has loaded and jumped into stage2 either with LBA or CHS geometry. I'm curious, where does stage1_5 come into play, if what you're suggesting is that it jumps from stage1 to stage2? In stage1 source code, the next stage is called stage2. ;) - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/LrAS0iMVcrivHFQRAolhAJwNGFhjtYWA2WnGnHXGhL6tmEwBAQCeOW9W X7Xf//ENF73ShEow/UVizrI= =rjz6 -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 4 Aug 2003 15:03:08 -0400, Kenneth Goodwin wrote: Phase 1.5 - Grub OS Loader Part one (OS filesystem selector) Knows? os fs structures That one would give considerably more status/error output, in particular: GRUB loading, please wait... - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/LrGl0iMVcrivHFQRAqpsAJwMOy0/Dm+uSO8AwbdXlcnZp7/UbgCfcpIf ciB38xOhXWdB6LZSQ+S9PgQ= =9kov -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
what I am saying is that the MBR may be crafted or rebuild by anaconda for the two drive setup disk info. It's grub-install/grub that creates stage1 based on the grub.conf created by anaconda. Grub-install. which I have not seen admittedly, may be based on a MAKE environment strategy. IF SO IT ONLY REBUILDS The MBR if and only if some local disk file has changed that a dependency has been declared for. It may not check to see if the hardware environment changed. By cleansing out the existing config info via a MAKE CLEAN or CLOBBER sequence , you should force it to do a fresh rebuild from scratch on the MBR program which should insert the new single drive related information. ie SO FAR your newly written grub is the same image as the old grub that was on the mbr to begin with. You can get rid of the generated files like this, preferably after removing slave drive and after booting with boot disk: rm /boot/grub/*1_5 /boot/grub/stage* grub-install --recheck --force-lba /dev/hda Option --force-lba might be interesting. Especially if the MBR was originally created to use LBA based IO routines and the drive now thinks it's is something other than LBA mode or vise versa.. In any case, good luck Ashley.contact the grub developers with your problem. They might be interested. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
-Original Message- From: [EMAIL PROTECTED] [mailto:redhat-list- [EMAIL PROTECTED] On Behalf Of Michael Schwendt Sent: Monday, August 04, 2003 2:12 PM To: [EMAIL PROTECTED] Subject: Re: GRUB failure -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 04 Aug 2003 13:06:19 -0600, Ashley M. Kirchner wrote: If it doesn't print an error message, it has loaded and jumped into stage2 either with LBA or CHS geometry. I'm curious, where does stage1_5 come into play, if what you're suggesting is that it jumps from stage1 to stage2? In stage1 source code, the next stage is called stage2. ;) As I understand stage1_5 it is a sort of extension of stage1 i.e. since stage1 is only 512 bytes long if some reason depending on the architecture it will use stage1_5. I'm not totally clear on this but that is the reason it is written to the area behind the MBR because that is not used most of the time and it provides more space, but if for some reason it can use that area then it just drops stage1_5 and goes directly to stage2. It really is not clear. But in the mean time Ashley you might need to upgrade your GRUB software if you want to solve this particular problem because I don't think you will get the GRUB developers to help you unless you are using the latest and the greatest. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/LrAS0iMVcrivHFQRAolhAJwNGFhjtYWA2WnGnHXGhL6tmEwBAQCeOW9W X7Xf//ENF73ShEow/UVizrI= =rjz6 -END PGP SIGNATURE- -- 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
RE: GRUB failure
Kenneth Goodwin wrote: 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. Nope. The machine had ONE drive upon installation. hdb wasn't added till months later and was used only for storage of backup files (it doesn't even stay mounted all the time.) This was explained in a previous email. I stand corrected. I remember you now stating that, sorry if I added to further confusion here, but the correction does not change anything other than to definitively prove your/our point that Drive B is not an issue in regards to GRUB. It is a side effect of it's removal from the IDE Bus that is behind your mystery and nothing else. I think the Grub Developers might be interested in discussing this with you. Their code should not be having an issue here irregardless of your hardware changes. They probably have not come across whatever the ROM BIOS is presumably doing here before to mess things up. Maybe a new grub tool for floppy is in order here -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
WOULD BE INTERESTING IF THEY BOTH HAVE THE SAME MOTHERBOARD / rom bios NOW WOuLDNT IT.. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Otto Haliburton Sent: Monday, August 04, 2003 2:31 PM To: [EMAIL PROTECTED] Subject: RE: GRUB failure This is different from the setup Ashley has but the results are the same. I don't exactly know what that means but it certainly means something. -Original Message- From: [EMAIL PROTECTED] [mailto:redhat-list- [EMAIL PROTECTED] On Behalf Of Otto Haliburton Sent: Monday, August 04, 2003 1:25 PM To: [EMAIL PROTECTED] Subject: RE: GRUB failure I have a dual boot system with HDA containing XP PRO and RH9 on HDB GRUB is the boot loader and it is written to the MBR or HDA along with the XP boot loader. I just removed HDB and guess what I got a black screen with GRUB in the left hand corner. -Original Message- From: [EMAIL PROTECTED] [mailto:redhat-list- [EMAIL PROTECTED] On Behalf Of Michael Schwendt Sent: Monday, August 04, 2003 12:59 PM To: [EMAIL PROTECTED] Subject: Re: GRUB failure -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 4 Aug 2003 13:39:54 -0400, Kenneth Goodwin wrote: what I am saying is that the MBR may be crafted or rebuild by anaconda for the two drive setup disk info. It's grub-install/grub that creates stage1 based on the grub.conf created by anaconda. Grub-install. which I have not seen admittedly, may be based on a MAKE environment strategy. IF SO IT ONLY REBUILDS The MBR if and only if some local disk file has changed that a dependency has been declared for. It may not check to see if the hardware environment changed. By cleansing out the existing config info via a MAKE CLEAN or CLOBBER sequence , you should force it to do a fresh rebuild from scratch on the MBR program which should insert the new single drive related information. ie SO FAR your newly written grub is the same image as the old grub that was on the mbr to begin with. You can get rid of the generated files like this, preferably after removing slave drive and after booting with boot disk: rm /boot/grub/*1_5 /boot/grub/stage* grub-install --recheck --force-lba /dev/hda Option --force-lba might be interesting. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Lp7Y0iMVcrivHFQRAoFkAJ0Z9nIV5jhIQgnmpDLuoJrbg43CgQCf cEWT LMknoC8k84oEiBhxdCtWxb0= =y8mK -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:redhat-list- [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 -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
yOU DONT GET A BOOT time MESSAGE ABOUTING CHECKING FOR new hardware? tHERE IS A PIECE OF ANACONDA THAT IS THE ADMINISTRATOR WHICH YOU may have removed, but the hardware auto-detect piece may be still installed. If it is, you get the checking for new hardware message on the console which is anaconda running on your system. Need to know because if it is totally purged, we know that you did not cuase any config file changes through anaconda. what do you remember about drive detection during the first install of drive B that might be a clue here? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ashley M. Kirchner Sent: Monday, August 04, 2003 2:31 PM To: [EMAIL PROTECTED] Subject: Re: GRUB failure Kenneth Goodwin wrote: what I am saying is that the MBR may be crafted or rebuild by anaconda for the two drive setup disk info. Anaconda may not be able to go backwards here, may not be able to undo in a return to single drive configuration - most people add hardware, not remove it, it may have not been a tested situation. Something changed on the linux system in response to the addition of the hard drive that is not being undone when he reboots with only one drive installed. This never occurred to me till now, but...the only time anaconda ran and did anything, was when the system was first installed. Both anaconda and kudzu get removed after installation. I run a tight ship, and don't like having packages installed that aren't needed for daily operations, so they go. When I added the second drive months later, what would cause any kind of configuration being redone, or whatever config file rewritten (other than me manually running fdisk and mkfs.ext3)? -- W | I haven't lost my mind; it's backed up on tape somewhere. +--- - Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- 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
Re: [RH List] RE: GRUB failure
Kenneth Goodwin wrote: yOU DONT GET A BOOT time MESSAGE ABOUTING CHECKING FOR new hardware? That's kudzu's job, and it's been long removed. (So the answer to your question is no, I don't.) -- W | I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
On Mon, 04 Aug 2003 13:06:19 -0600, Ashley M. Kirchner wrote: If it doesn't print an error message, it has loaded and jumped into stage2 either with LBA or CHS geometry. I'm curious, where does stage1_5 come into play, if what you're suggesting is that it jumps from stage1 to stage2? In stage1 source code, the next stage is called stage2. ;) Now Mike, This is not Fair! You cant keep changing the nomenclature like this, It just confuses my poor little brain... I thut I thaw a put-tee tat.. So lets see, no stage 1.5 unless you are reading the grub manual by the light of the full moon under a pear tree, divide by 27, carry the 2, divide again by four and multiply by PI R-squared to the Nth power. Lets seeh. Bing...Warp Speed Mr Sulu.. Okay , so we have Stage 1 the MBR or Primary Boot Loader which calls Stage 2 the Main Boot Decision loader which calls Stage 3 the OS loader? Or is it just Stage 1 and Stage 2 followed by the OS LOAD and boot? or it is Stage 1, 1.5 and 2 and carry the 3 if you are using the same motherboard as Ashley? for the unwary - CTS and CHS refer to the same thing For really old ones like me, we refer to disk in terms of Tracks, which was the original nomenclature used with removal pack disk drives later generations like heads better, I guess they changed it because of Winchester technology -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: [RH List] RE: GRUB failure
I thought Kudzu was replaced by Anaconda I dont recall seeing it on my RH 8/9 systems but I may have been asleep at the console at the time... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ashley M. Kirchner Sent: Monday, August 04, 2003 3:35 PM To: [EMAIL PROTECTED] Subject: Re: [RH List] RE: GRUB failure Kenneth Goodwin wrote: yOU DONT GET A BOOT time MESSAGE ABOUTING CHECKING FOR new hardware? That's kudzu's job, and it's been long removed. (So the answer to your question is no, I don't.) -- W | I haven't lost my mind; it's backed up on tape somewhere. +--- - Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- 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
Re: GRUB failure
Kenneth Goodwin wrote: I thought Kudzu was replaced by Anaconda I dont recall seeing it on my RH 8/9 systems but I may have been asleep at the console at the time... You skipped a post somewhere...the machine has 7.3 on it. -- W | I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 4 Aug 2003 15:40:53 -0400, Kenneth Goodwin wrote: In stage1 source code, the next stage is called stage2. ;) Now Mike, This is not Fair! You cant keep changing the nomenclature like this, It just confuses my poor little brain... I thut I thaw a put-tee tat.. GRUB in MBR does not care at all whether the _next_ stage is the final stage as found in file /boot/grub/stage2 or whether it is an intermediate stage that loads another stage. So, in the stage1 source code they call the next stage stage2, which is the stage1.5 we've been referring to all the time. It's that intermediate stage1.5 which provides ext2 fs access and hence can load any ordinary file on GRUB's root partition. The important thing to point out repeatedly is that if stage1 (in MBR) doesn't recognize any error upon determining drive geometry and upon loading the next stage, it doesn't print anything else than GRUB . And what can happen in stage1? In stage1 the BIOS is used to access the disk. CHS/LBA confusion, time-out waiting for hda to respond, what else? - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Lru50iMVcrivHFQRAtjbAJwPU4SCTMXtbZRSfgvnvBNEThbC5gCfbm+h v1qrbCK5S1MMno1+zvUxgmk= =xr0f -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
I thought Kudzu was replaced by Anaconda I dont recall seeing it on my RH 8/9 systems but I may have been asleep at the console at the time... You skipped a post somewhere...the machine has 7.3 on it. actually i missed all the early ones and said so. I only jump in when some poor soul like you is being dragged around hell by the heels. Oh, BTW I skipped from 7.1 to 8.0 and rapidly from there to 9.0 so 7.3 isnt even a faint happy memory. It never existed. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
Kenneth Goodwin wrote: Oh, BTW I skipped from 7.1 to 8.0 and rapidly from there to 9.0 I went 5.2 - 6.2 - 7.3 - and currently I have only one machine that has 8 on it. None has 9... -- W | I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: [RH List] RE: GRUB failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 4 Aug 2003 15:43:38 -0400, Kenneth Goodwin wrote: I thought Kudzu was replaced by Anaconda I dont recall seeing it on my RH 8/9 systems but I may have been asleep at the console at the time... Kudzu and Anaconda are two separate things. The former is a hardware detection and configuration tool. The latter is Red Hat's installer. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Lr4N0iMVcrivHFQRAot/AJ0WxUEmuAqkS35935l9GCrfkWTX/wCfZiZo C8VW4t2C3Oxz6d9z2mV3lS4= =yzwJ -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: [RH List] RE: GRUB failure
Every time I run Anaconda during installs, it does device detection Probing. looking for hardware, does this mean it is silently calling kudzu underneath? IMWTK (Inquiring Minds Want To Know.) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Michael Schwendt Sent: Monday, August 04, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: Re: [RH List] RE: GRUB failure -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 4 Aug 2003 15:43:38 -0400, Kenneth Goodwin wrote: I thought Kudzu was replaced by Anaconda I dont recall seeing it on my RH 8/9 systems but I may have been asleep at the console at the time... Kudzu and Anaconda are two separate things. The former is a hardware detection and configuration tool. The latter is Red Hat's installer. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Lr4N0iMVcrivHFQRAot/AJ0WxUEmuAqkS35935l9GCrfkWTX/wCf ZiZo C8VW4t2C3Oxz6d9z2mV3lS4= =yzwJ -END PGP SIGNATURE- -- 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
RE: [RH List] RE: GRUB failure
They both are there trust me. In RH8/9 -Original Message- From: [EMAIL PROTECTED] [mailto:redhat-list- [EMAIL PROTECTED] On Behalf Of Kenneth Goodwin Sent: Monday, August 04, 2003 2:44 PM To: [EMAIL PROTECTED] Subject: RE: [RH List] RE: GRUB failure I thought Kudzu was replaced by Anaconda I dont recall seeing it on my RH 8/9 systems but I may have been asleep at the console at the time... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ashley M. Kirchner Sent: Monday, August 04, 2003 3:35 PM To: [EMAIL PROTECTED] Subject: Re: [RH List] RE: GRUB failure Kenneth Goodwin wrote: yOU DONT GET A BOOT time MESSAGE ABOUTING CHECKING FOR new hardware? That's kudzu's job, and it's been long removed. (So the answer to your question is no, I don't.) -- W | I haven't lost my mind; it's backed up on tape somewhere. +--- - Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- 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
RE: [RH List] RE: GRUB failure
Otto , Ashley stated he REMOVED THEM BOTH , I was just confirming that all of them was gone, not just a piece at the admin level. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Otto Haliburton Sent: Monday, August 04, 2003 4:23 PM To: [EMAIL PROTECTED] Subject: RE: [RH List] RE: GRUB failure They both are there trust me. In RH8/9 -Original Message- From: [EMAIL PROTECTED] [mailto:redhat-list- [EMAIL PROTECTED] On Behalf Of Kenneth Goodwin Sent: Monday, August 04, 2003 2:44 PM To: [EMAIL PROTECTED] Subject: RE: [RH List] RE: GRUB failure I thought Kudzu was replaced by Anaconda I dont recall seeing it on my RH 8/9 systems but I may have been asleep at the console at the time... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ashley M. Kirchner Sent: Monday, August 04, 2003 3:35 PM To: [EMAIL PROTECTED] Subject: Re: [RH List] RE: GRUB failure Kenneth Goodwin wrote: yOU DONT GET A BOOT time MESSAGE ABOUTING CHECKING FOR new hardware? That's kudzu's job, and it's been long removed. (So the answer to your question is no, I don't.) -- W | I haven't lost my mind; it's backed up on tape somewhere. +--- - Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- 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 -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 4 Aug 2003 16:16:46 -0400, Kenneth Goodwin wrote: I dont have the RH 7.2 version of the grub source to look at. Might have 7.1 levels. The MBR is probably the same. If you have source - What does it do after printing out GRUB, everything or just a few last things before jumping to the newly loaded image? RHL 7.3: grub-0.91-4 RHL 9: grub-0.93-6 And surprise, the stage1 code is exactly the same. It prints GRUB , then does a few BIOS software interrupt calls to look whether LBA is supported, else falls back to CHS scheme. It also contains a bit of floppy probing code. If it doesn't print anything else than GRUB, it assumes it has loaded the next stage and executes it. A bit more sane code (if space permits) would print a few dots right before executing the next stage or would even verify whether the loaded next stage starts with a proper signature. Open questions: - is BIOS set to LBA? - does grub-install with --force-lba work? - does LILO work? - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Lsco0iMVcrivHFQRAm9BAJ9CtMyWU/qpnoLoKhT7tIm010aXkgCcDVFi ko2oaeln8AVlwEnTQarX1kk= =V+e7 -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
Michael Schwendt wrote: - is BIOS set to LBA? Last I checked, it was. - does grub-install with --force-lba work? No errors. - does LILO work? Ain't trying that. The server is up and running as it should be, and I can't take it down in the name of science right now. -- W | I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
If this hasn't been tried yet the bioses don't all need/ want the drives to be set any way but master or slave. Ashley... try not changing the drive to single... leave it as the Master. ( as in don't change the jumper when removing the second drive) the addressing of the drive can be different between the two settings. The symptoms you reported are consistent with the bios loading the first part of the grub loader, and grub not being able to find itself (2nd stage) to continue the boot. those symptoms say the drive isn't at the address grub is looking at. Since it IS there with the other settings, it is probably the jumper changes causing the problem. brian... hth. :) /// At --- [EMAIL PROTECTED] -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
Kenneth... I feel Your on the right track here... you may have missed her post where she said nothing was changed and went on to say she did switch jumper positions... this changes same parts of the hardware addressing. so a hard coded go there might not see what a bios call would brian :)/ At 07:38 PM 8/1/03 -0400, Kenneth Goodwin wrote: Maybe I misunderstand here, but this seems to be a situation where - A working Linux system using GRUB with MBR on HD-A, .conf file on HD-A had a new disk drive HD-B added to it. They did nothing apparently to reconfigure the box bootwise. They added the filesystems onto HD-B and used them for whatever. HD-B croaked. When they removed HD-B from the ide BUS, things with GRUB broke AND THEY DONT UNDERSTAND WHY? Since everything for GRUB should be on HD-A which is still operational. Grub should not have a problem locating the .conf file since it should still exist on HD-A. Why would GRUB whose ENTIRE RESOURCES SHOULD BE STILL INTACT On DRIVE A fail to work when DRIVE B is Removed from the IDE Chain? The problem is, I have understood the problem. You can't boot when GRUB can't find grub.conf. GRUB doesn't even come that far as was explained in the first message. If it booted into GRUB shell and then wouldn't find the config file, that would be a minor problem. You can when it can. When you remove hdb GRUB can't find the .conf file and that is why you can't boot. OTTO's REPLY I agree with the what you are saying. Something is changing when HDB is removed. I don't know what. I can tell you that the same thing will happen if you add/delete a partition on 'HAD'. We conjectured that it could be hardware, but they say its not so I don't know, but we do know for a fact that it can't locate the .conf file by what projection has taken place. It could be as simple as the partition are being renumbered or as complicated as a GRUB problem. But the addition and removal of the drive is changing something. I have not seen grub source, but Grub is apparently a multi-load phase boot loader, the MBR piece loads the rest of the boot loader off of the /boot partition which then loads the OS etc. Okay, Most boot loaders do not record things as Partition numbers in the MBR piece. Ie from an OS / LINUX perspective of hardware, it wont be /dev/hda00 or whatever in the MBR. Instead, It will be hardcoded as a disk drive number from a hardware perspective IDE Controller, unit select info, the stuff you see in the messages file during boot and a Block offset on the disk from whence to start looking for the superblock. This will be the first block number on the ide disk that /boot starts physically at. However, The MBR record should have the correct pointers to the HD-A drive and /boot partition since the system was initially setup that way. If you stick drive B back on the bus and change nothing else, things work again from what I understand here. I think your GRUB prompt is coming out of the MBR piece but you would have to check the source code. Since the /boot filesystem is where the CONF file and the rest of grub is apparently located and is supposed to be the first partition on the drive this should always work. Now if you make /boot further in on the drive and then change the sizes of the partition(s) before the /boot partition and dont tell grub's MBR piece about the change you will have the kinda problem that Otto apparently had with Grub, thats because grub cant find the real start of the /boot partition since the block offset into the disk just changed. Otto would have to confirm that was the case in his situation. I think that Otto was on the right track, but was not explaining his position clearly. The issue here is apparently why does adding in Drive B Not mess up the MBR's sense of where Drive A is on the IDE chain , but when drive B is removed the MBR can't find drive A. There must be a radical shift in how the BIOS is dealing with the drives since the original create of LINUX in a single drive configuration, the addition of the second drive and subsequent removal there of. (Of course, this is only a theory mind you...) Sort of an example to give you the idea of where I am going here - At Create time of LINUX Drive A - bus address 123456 - recorded that way in MBR Add in Drive B ROM BIOS reconfiguration of it's device tables. Drive A - bus address 123456 MBR points to 123456 Drive B - bus address 123455 Remove drive B - ROM BIOS reconfiguration of it's device tables. Drive A - bus address 123454 MBR points to 123456 Rom Bios loads
Re: GRUB failure
brian davison wrote: Ashley... try not changing the drive to single... leave it as the Master. ( as in don't change the jumper when removing the second drive) No can do. hda has three settings on it: Master, Master w/ Slave, and Slave. Since hdb was installed, it's been set to Master w/ Slave (leaving it as Master resulted in hdb not being detected by the BIOS.) Consequently, removing hdb without changing the jumper on hda resulted in the machine not booting because the BIOS expected a slave since hda's jumper was set as such. Mind you, I've played with this a whole lot already, and it just doesn't work with just leaving the jumper alone and not changing it. If I leave it set to Master, the BIOS won't see hdb. If I leave it on Master w/ Slave, the BIOS complains about not seeing a slave (when hdb gets removed.) So I had to change that anyway. PS: Ashley's a guy. -- H| I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
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
Re: GRUB failure
Otto Haliburton wrote: 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. You really don't believe me when I say there's -NOTHING- on the drive, do you? How about this? I've actually killed everything, including partitions on said drive. GRUB comes up just fine as long as that device is connected. As soon as it's disconnected, it fails. But, you want to see, so here, there is nothing on it: /root fdisk -l /dev/hdb Disk /dev/hdb: 255 heads, 63 sectors, 7476 cylinders Units = cylinders of 16065 * 512 bytes Device BootStart EndBlocks Id System /root It boots up fine when it's connected, but not when removed from the chain. 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. I've been over this time and time again: I HAVE DONE THAT. - removed hdb - set hda's jumper back to master otherwise BIOS complains and won't boot - shoved floppy in, booted up just fine - ran grub-install /dev/hda, no errors - removed floppy, reboot - BIOS finds hda, knows there's no hdb, goes on to boot - black screen, with 'GRUB' in the corner: system dead I ran the same cycle again, this time issuing: grub-install --root-directory=/boot '(hd0)' as the info page suggests. Same result, won't boot, dead system. As soon as I plug hdb back in, whether the drive has partitions on it or not, it boots just fine. I even tried a completely different drive, one that has an NTFS partition on it, and the system boots just fine with it. I doubt GRUB is actually trying to READ anything of the drive. So I ask you again, how can GRUB possibly be reading ANYTHING from hdb when there's -NOTHING- on it (or when there is something, but totally different, such as the NTFS drive I tried)? -- H| I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
No, actually I wanted to see if when it booted it was creating a partition or swap space on drive b. Don't be so sensitive. I also wanted to see if it was chaining the partitions together in a way that would cause it to renumber the partitions so that it could not locate the GRUB directory. What kind of disk contoller do you have and what kind of computer system(manufacturer) is this computer. -Original Message- From: [EMAIL PROTECTED] [mailto:redhat-list- [EMAIL PROTECTED] On Behalf Of Ashley M. Kirchner Sent: Sunday, August 03, 2003 4:41 AM To: [EMAIL PROTECTED] Subject: Re: GRUB failure Otto Haliburton wrote: 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. You really don't believe me when I say there's -NOTHING- on the drive, do you? How about this? I've actually killed everything, including partitions on said drive. GRUB comes up just fine as long as that device is connected. As soon as it's disconnected, it fails. But, you want to see, so here, there is nothing on it: /root fdisk -l /dev/hdb Disk /dev/hdb: 255 heads, 63 sectors, 7476 cylinders Units = cylinders of 16065 * 512 bytes Device BootStart EndBlocks Id System /root It boots up fine when it's connected, but not when removed from the chain. 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. I've been over this time and time again: I HAVE DONE THAT. - removed hdb - set hda's jumper back to master otherwise BIOS complains and won't boot - shoved floppy in, booted up just fine - ran grub-install /dev/hda, no errors - removed floppy, reboot - BIOS finds hda, knows there's no hdb, goes on to boot - black screen, with 'GRUB' in the corner: system dead I ran the same cycle again, this time issuing: grub-install --root-directory=/boot '(hd0)' as the info page suggests. Same result, won't boot, dead system. As soon as I plug hdb back in, whether the drive has partitions on it or not, it boots just fine. I even tried a completely different drive, one that has an NTFS partition on it, and the system boots just fine with it. I doubt GRUB is actually trying to READ anything of the drive. So I ask you again, how can GRUB possibly be reading ANYTHING from hdb when there's -NOTHING- on it (or when there is something, but totally different, such as the NTFS drive I tried)? -- H| I haven't lost my mind; it's backed up on tape somewhere. +--- - Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- 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
Re: GRUB failure
Otto Haliburton wrote: What kind of disk contoller do you have and what kind of computer system(manufacturer) is this computer. I can tell you Monday when I get to the office and pull the specs on the board. It's a (custom built) white box containing an Intel board. One IDE bus, and 2 aic7899 Ultra160 SCSI ports on it (which aren't being used). I don't remember which specific board model it is, so you'll have to wait till Monday. IDE info from dmesg: SvrWks OSB4: IDE controller at PCI slot 00:0f.1 SvrWks OSB4: chipset revision 0 SvrWks OSB4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x54d0-0x54d7, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0x54d8-0x54df, BIOS settings: hdc:DMA, hdd:DMA Yes, it lists both ide0 and ide1, however there is no physical ide1 connector on the board. Only ide0, and the two scsi connectors. I'd also like to point out that this has now become a moot point since I already have hdb in and the system works. -- H| I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 3 Aug 2003 04:13:09 -0500, Otto Haliburton wrote: 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. Unfortunately, the shown grub.conf does not agree with this theory at all. It does not contain any reference to hd1, so there's no single reason why grub-install /dev/hda would work without errors, but the booting from hda would fail. It apparently thinks that linux is on the second drive. This conclusion is beyond me. 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. 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. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/LRZ70iMVcrivHFQRAmf+AJ4qbjgdK+3rpvdCsXgz47rIeh6SPgCfQlWU sYhitwThMNCKrXCfpgBk1kU= =kcXm -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
-Original Message- From: [EMAIL PROTECTED] [mailto:redhat-list- [EMAIL PROTECTED] On Behalf Of Michael Schwendt Sent: Sunday, August 03, 2003 9:05 AM To: [EMAIL PROTECTED] Subject: Re: GRUB failure -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 3 Aug 2003 04:13:09 -0500, Otto Haliburton wrote: 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. Unfortunately, the shown grub.conf does not agree with this theory at all. It does not contain any reference to hd1, so there's no single reason why grub-install /dev/hda would work without errors, but the booting from hda would fail. It apparently thinks that linux is on the second drive. This conclusion is beyond me. 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. 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. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/LRZ70iMVcrivHFQRAmf+AJ4qbjgdK+3rpvdCsXgz47rIeh6SPgCfQlWU sYhitwThMNCKrXCfpgBk1kU= =kcXm -END PGP SIGNATURE- -- 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
RE: GRUB failure
BTW the MBR is on HDA -Original Message- From: [EMAIL PROTECTED] [mailto:redhat-list- [EMAIL PROTECTED] On Behalf Of Michael Schwendt Sent: Sunday, August 03, 2003 9:05 AM To: [EMAIL PROTECTED] Subject: Re: GRUB failure -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 3 Aug 2003 04:13:09 -0500, Otto Haliburton wrote: 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. Unfortunately, the shown grub.conf does not agree with this theory at all. It does not contain any reference to hd1, so there's no single reason why grub-install /dev/hda would work without errors, but the booting from hda would fail. It apparently thinks that linux is on the second drive. This conclusion is beyond me. 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. 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. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/LRZ70iMVcrivHFQRAmf+AJ4qbjgdK+3rpvdCsXgz47rIeh6SPgCfQlWU sYhitwThMNCKrXCfpgBk1kU= =kcXm -END PGP SIGNATURE- -- 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
RE: GRUB failure
On Sun, 2003-08-03 at 02:27, brian davison wrote: Kenneth... I feel Your on the right track here... you may have missed her post where she said nothing was changed and went on to say she did switch jumper positions... this changes same parts of the hardware addressing. so a hard coded go there might not see what a bios call would brian :)/ Just curious what is in the device.map file? This is where grub assigns device numbers used in grub.conf. I don't know if this is used in the installation of grub on the mbr or after but since I don't remember anything about this I thought I would ask. If it was posted already I appologize. Bret -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 3 Aug 2003 09:28:56 -0500, Otto Haliburton wrote: 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 code in MBR does not know about directories at all. It has a physical harddisk location hardcoded and uses a BIOS function to read some sectors at a fixed position, usually the first cylinder following the MBR. Please do us all a favour and reboot after removing the stage2 file in /boot/grub. That will be enlightening experience for you. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/LU5O0iMVcrivHFQRAnydAJ93m6agCWc9C8qBoZ8TOz057x2/YwCfcH1R XUjrYjdwdxbqtOwbPvmS4Qc= =lG59 -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
-Original Message- From: [EMAIL PROTECTED] [mailto:redhat-list- [EMAIL PROTECTED] On Behalf Of Michael Schwendt Sent: Sunday, August 03, 2003 1:03 PM To: [EMAIL PROTECTED] Subject: Re: GRUB failure -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 3 Aug 2003 09:28:56 -0500, Otto Haliburton wrote: 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 code in MBR does not know about directories at all. It has a physical harddisk location hardcoded and uses a BIOS function to read some sectors at a fixed position, usually the first cylinder following the MBR. Please do us all a favour and reboot after removing the stage2 file in /boot/grub. That will be enlightening experience for you. Knowing where the GRUB directory is doesn't have anything to do with knowing where things are located. The MBR is in the 1st sector of the drive we agree. Once GRUB is called it goes to a particular location on the disk to load stage1 (that particular location on linux just happens to be /boot/grub). I suggest you go to /boot/grub and see what is in that directory. Again I am saying something very simple. If it knows where stage1 is then it knows where stage2 is!!!1 -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 3 Aug 2003 13:13:46 -0500, Otto Haliburton wrote: Knowing where the GRUB directory is doesn't have anything to do with knowing where things are located. The MBR is in the 1st sector of the drive we agree. Once GRUB is called it goes to a particular location on the disk to load stage1 (that particular location on linux just happens to be /boot/grub). I suggest you go to /boot/grub and see what is in that directory. Again I am saying something very simple. If it knows where stage1 is then it knows where stage2 is!!!1 *sigh* No. Because 1) stage1 is the MBR and NOT the file in grub directory, 2) two completely different techniques are used to load stage1.5 and stage2. While the physical location of stage1.5 is hardcoded into the MBR, the location of stage2 is not. At a later point in the booting process, GRUB is able to access the ext2 file-system directly and *then* can access stage2 and any file on its root partition. But all this is irrelevant. Ashley is confronted with a problem where GRUB stage1 (the MBR!) fails/hangs. IMO, and I've mentioned that earlier, the only reason can be that it gets a wrong BIOS drive Id or loads wrong sectors due to geometry mismatch. We don't know what role primary slave drive plays when it is removed. Hence I don't have any other comment. Btw, since I'm tired of your replies in this thread, welcome to my ~/.procmailrc! Don't expect another reply from me. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/LVbU0iMVcrivHFQRAsXmAJ9BndNBko84D+EutCyewq0VPBsHAACfUAro 429/pTz0rncvSaMZLzbO34k= =gJCZ -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
thanks -Original Message- From: [EMAIL PROTECTED] [mailto:redhat-list- [EMAIL PROTECTED] On Behalf Of Michael Schwendt Sent: Sunday, August 03, 2003 1:39 PM To: [EMAIL PROTECTED] Subject: Re: GRUB failure -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 3 Aug 2003 13:13:46 -0500, Otto Haliburton wrote: Knowing where the GRUB directory is doesn't have anything to do with knowing where things are located. The MBR is in the 1st sector of the drive we agree. Once GRUB is called it goes to a particular location on the disk to load stage1 (that particular location on linux just happens to be /boot/grub). I suggest you go to /boot/grub and see what is in that directory. Again I am saying something very simple. If it knows where stage1 is then it knows where stage2 is!!!1 *sigh* No. Because 1) stage1 is the MBR and NOT the file in grub directory, 2) two completely different techniques are used to load stage1.5 and stage2. While the physical location of stage1.5 is hardcoded into the MBR, the location of stage2 is not. At a later point in the booting process, GRUB is able to access the ext2 file-system directly and *then* can access stage2 and any file on its root partition. But all this is irrelevant. Ashley is confronted with a problem where GRUB stage1 (the MBR!) fails/hangs. IMO, and I've mentioned that earlier, the only reason can be that it gets a wrong BIOS drive Id or loads wrong sectors due to geometry mismatch. We don't know what role primary slave drive plays when it is removed. Hence I don't have any other comment. Btw, since I'm tired of your replies in this thread, welcome to my ~/.procmailrc! Don't expect another reply from me. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/LVbU0iMVcrivHFQRAsXmAJ9BndNBko84D+EutCyewq0VPBsHAACfUAro 429/pTz0rncvSaMZLzbO34k= =gJCZ -END PGP SIGNATURE- -- 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
RE: GRUB failure
This is excerpts from the GNU GRUB manual. The manual suggests that you may have a problem with the device map in /boot/grub (this maybe where it is located). It says that GRUB doesn't know how to translate from bios disk to OS designations so it uses the device map in the grub directory. So Ashley you might check that out to see if it is corrupted or contains hdb which is causing a problem when you remove the device. The grub manual is located at http://www.gnu.org/manual/grub/index.html GRUB features = Recognize multiple executable formats Support non-Multiboot kernels Load multiples modules Load a configuration file Provide a menu interface Have a flexible command-line interface Support multiple filesystem types Support multiple filesystem types transparently, plus a useful explicit blocklist notation. The currently supported filesystem types are BSD FFS, DOS FAT16 and FAT32, Minix fs, Linux ext2fs, ReiserFS, JFS, XFS, and VSTa fs. *Note Filesystem::, for more information. Support automatic decompression Access data on any installed device Support reading data from any or all floppy or hard disk(s) recognized by the BIOS, independent of the setting of the root device. Be independent of drive geometry translations Unlike many other boot loaders, GRUB makes the particular drive translation irrelevant. A drive installed and running with one translation may be converted to another translation without any adverse effects or changes in GRUB's configuration. Detect all installed RAM Support Logical Block Address mode In traditional disk calls (called CHS mode), there is a geometry translation problem, that is, the BIOS cannot access over 1024 cylinders, so the accessible space is limited to at least 508 MB and to at most 8GB. GRUB can't universally solve this problem, as there is no standard interface used in all machines. However, several newer machines have the new interface, Logical Block Address (LBA) mode. GRUB automatically detects if LBA mode is available and uses it if available. In LBA mode, GRUB can access the entire disk. Support network booting GRUB is basically a disk-based boot loader but also has network support. You can load OS images from a network by using the TFTP protocol. Support remote terminals Errors reported by the Stage 1 == The general way that the Stage 1 handles errors is to print an error string and then halt. Pressing `CTRL-ALT-DEL' will reboot. The following is a comprehensive list of error messages for the Stage 1: Hard Disk Error The stage2 or stage1.5 is being read from a hard disk, and the attempt to determine the size and geometry of the hard disk failed. Floppy Error The stage2 or stage1.5 is being read from a floppy disk, and the attempt to determine the size and geometry of the floppy disk failed. It's listed as a separate error since the probe sequence is different than for hard disks. Errors reported by the Stage 1.5 The general way that the Stage 1.5 handles errors is to print an error number in the form `Error NUM' and then halt. Pressing `CTRL-ALT-DEL' will reboot. The error numbers correspond to the errors reported by Stage 2. *Note Stage2 errors::. Errors reported by the Stage 2 == The general way that the Stage 2 handles errors is to abort the operation in question, print an error string, then (if possible) either continue based on the fact that an error occurred or wait for the user to deal with the error. The following is a comprehensive list of error messages for the Stage 2 (error numbers for the Stage 1.5 are listed before the colon in each description): -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
Bret Hughes wrote: Just curious what is in the device.map file? This is where grub assigns device numbers used in grub.conf. I don't know if this is used in the installation of grub on the mbr or after but since I don't remember anything about this I thought I would ask. If it was posted already I appologize. This was posted already, but here it is again: # this device map was generated by anaconda (fd0) /dev/fd0 (hd0) /dev/hda -- H| I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 1 Aug 2003 19:36:17 -0500, Otto Haliburton wrote: Is your configuration a SCSI? If it is then there is a explanation That wouldn't access the harddisk drives as /dev/hda and /dev/hdb, respectively. Btw, it would be great if you could trim your quotes. There's no need in quoting list footers and superfluous things. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/K2ie0iMVcrivHFQRAqV/AJ4z41SxMKRnYTzo/JGOHaOv1RfvrgCfVr7C bdY0YAUR8Q3njzv7VO4t0V0= =o+v2 -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 1 Aug 2003 19:47:47 -0400, Kenneth Goodwin wrote: Anyone know for certain who is printing out the INitial GRUB message? The MBR or phase two piece. MBR (stage1) prints only GRUB because of space constraints. It has only very few and short error messages. The next code (stage 1.5) is still loaded directly from harddisk, but after that GRUB is able to access the ext2 file-system and load stage2 and other files. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/K3OP0iMVcrivHFQRAlmSAJsHpc5Cflh8QAKQQwdLR2sB3ojmKACePGFL mlDPw65Adctvdcrs0lbSEn8= =hKPX -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB Failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 1 Aug 2003 19:40:49 -0500, Otto Haliburton wrote: There is also a explanation if the volumes are LVM or RAID. No. LVM is not available before the initrd is loaded and the kernel is started. Same for Software-RAID. You boot from a physical device, not a logical one. With Hardware-RAID, the two drives would not appear as individual drives hda and hdb. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/K3Ql0iMVcrivHFQRAiMJAJsGF5HbdJvuHdxDg+d4o3wnrGbFeACfb7EH 1ea25xkELlxijz59z0GM6Rs= =HadU -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
This is a test message to see the format. Do not respond to this message. It has already been sent. HIII ISSSAAATTTEE T. -Original Message- From: [EMAIL PROTECTED] [mailto:redhat-list- [EMAIL PROTECTED] On Behalf Of Michael Schwendt Sent: Saturday, August 02, 2003 2:31 AM To: [EMAIL PROTECTED] Subject: Re: GRUB failure -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 1 Aug 2003 19:36:17 -0500, Otto Haliburton wrote: Is your configuration a SCSI? If it is then there is a explanation That wouldn't access the harddisk drives as /dev/hda and /dev/hdb, respectively. Btw, it would be great if you could trim your quotes. There's no need in quoting list footers and superfluous things. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/K2ie0iMVcrivHFQRAqV/AJ4z41SxMKRnYTzo/JGOHaOv1RfvrgCfVr7C bdY0YAUR8Q3njzv7VO4t0V0= =o+v2 -END PGP SIGNATURE- -- 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
RE: GRUB failure
This is a test message to see the format. Do not respond to this message. It has already been sent. HIII ISSSAAATTTEE T. HIII ISSSAAATTTEET. On Sat, 2003-08-02 at 09:50, Otto Haliburton wrote: This is a test message to see the format. Do not respond to this message. It has already been sent. HIII ISSSAAATTTEE T. -Original Message- From: [EMAIL PROTECTED] [mailto:redhat-list- [EMAIL PROTECTED] On Behalf Of Michael Schwendt Sent: Saturday, August 02, 2003 2:31 AM To: [EMAIL PROTECTED] Subject: Re: GRUB failure -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 1 Aug 2003 19:36:17 -0500, Otto Haliburton wrote: Is your configuration a SCSI? If it is then there is a explanation That wouldn't access the harddisk drives as /dev/hda and /dev/hdb, respectively. Btw, it would be great if you could trim your quotes. There's no need in quoting list footers and superfluous things. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/K2ie0iMVcrivHFQRAqV/AJ4z41SxMKRnYTzo/JGOHaOv1RfvrgCfVr7C bdY0YAUR8Q3njzv7VO4t0V0= =o+v2 -END PGP SIGNATURE- -- 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
RE: GRUB failure
This is a test message to see the format. Do not respond to this message. It has already been sent. HIII ISSSAAATTTEE T. HIII ISSSAAATTTEE T. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Otto Haliburton Sent: Saturday, August 02, 2003 10:02 AM To: [EMAIL PROTECTED] Subject: RE: GRUB failure This is a test message to see the format. Do not respond to this message. It has already been sent. HIII ISSSAAATTTEE T. HIII ISSSAAATTTEE T. On Sat, 2003-08-02 at 09:50, Otto Haliburton wrote: This is a test message to see the format. Do not respond to this message. It has already been sent. HIII ISSSAAATTTEE T. -Original Message- From: [EMAIL PROTECTED] [mailto:redhat-list- [EMAIL PROTECTED] On Behalf Of Michael Schwendt Sent: Saturday, August 02, 2003 2:31 AM To: [EMAIL PROTECTED] Subject: Re: GRUB failure -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 1 Aug 2003 19:36:17 -0500, Otto Haliburton wrote: Is your configuration a SCSI? If it is then there is a explanation That wouldn't access the harddisk drives as /dev/hda and /dev/hdb, respectively. Btw, it would be great if you could trim your quotes. There's no need in quoting list footers and superfluous things. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/K2ie0iMVcrivHFQRAqV/AJ4z41SxMKRnYTzo/JGOHaOv1RfvrgCfVr7C bdY0YAUR8Q3njzv7VO4t0V0= =o+v2 -END PGP SIGNATURE- -- 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
Re: GRUB failure
On Fri, 2003-08-01 at 15:22, Ashley M. Kirchner wrote: Recently I had to remove /dev/hdb from a server to get it replaced. The OS is installed entirely on /dev/hda (including swap), and hdb was a mere backup drive (it was actually added AFTER the server was initially installed, up and running.) Nothing on the OS depended on this drive being there, or being accessible. However, to my surprise, after removing the drive and attempting to start the server back up, I was presented with a black screen with the word GRUB in the upper left hand corner. Nothing else, it wouldn't boot, it just sat there. The only way I was able to get the server running again was to either put hdb back into the system, or boot off of the boot floppy I always keep around. That boots the system up and runs just fine, but it won't boot any other way. So, why is that? Why is Grub refusing to boot after I removed that drive? Can you post the output of df with hdb, and a copy of grub.conf? -- Michael Gargiullo [EMAIL PROTECTED] Warp Drive Networks -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
Michael Gargiullo wrote: Can you post the output of df with hdb, and a copy of grub.conf? This has never changed. It's been the same since the machine was first installed (or last upgraded): --- # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You do not have a /boot partition. This means that # all kernel and initrd paths are relative to /, eg. # root (hd0,0) # kernel /boot/vmlinuz-version ro root=/dev/hda1 # initrd /boot/initrd-version.img #boot=/dev/hda default=0 timeout=10 splashimage=(hd0,0)/boot/grub/splash.xpm.gz title Red Hat Linux (2.4.20-18.7smp) root (hd0,0) kernel /boot/vmlinuz-2.4.20-18.7smp ro root=/dev/hda1 vga=4 initrd /boot/initrd-2.4.20-18.7smp.img title Red Hat Linux (2.4.20-18.7) root (hd0,0) kernel /boot/vmlinuz-2.4.20-18.7 ro root=/dev/hda1 vga=4 initrd /boot/initrd-2.4.20-18.7.img --- As for df (note that the swap partition is on hda7): --- FilesystemSize Used Avail Use% Mounted on /dev/hda1 3.9G 1.2G 2.5G 31% / /dev/hda2 6.5G 393M 5.7G 7% /home /dev/hdb1 56G 32M 56G 0% /home2 /dev/hde1 37G 20G 15G 56% /home3 none 503M 0 503M 0% /dev/shm /dev/hda6 2.0G 33M 1.8G 2% /tmp /dev/hda5 2.0G 194M 1.6G 11% /var/log /dev/hda3 3.9G 3.4G 427M 89% /var/www /dev/hdg1 56G 19G 34G 35% /var/backup/weekly logs:/mnt/logs/stigmata 12G 3.7G 8.1G 32% /var/log/httpd --- As you can see, there is nothing on /dev/hdb1 that Grub should be concerned about to even be there. I even removed it from fstab, not that doing so would have any effect what so ever on how Grub boots. -- W | I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 01 Aug 2003 13:22:57 -0600, Ashley M. Kirchner wrote: Recently I had to remove /dev/hdb from a server to get it replaced. The OS is installed entirely on /dev/hda (including swap), and hdb was a mere backup drive (it was actually added AFTER the server was initially installed, up and running.) Nothing on the OS depended on this drive being there, or being accessible. However, to my surprise, after removing the drive and attempting to start the server back up, I was presented with a black screen with the word GRUB in the upper left hand corner. Nothing else, it wouldn't boot, it just sat there. The only way I was able to get the server running again was to either put hdb back into the system, or boot off of the boot floppy I always keep around. That boots the system up and runs just fine, but it won't boot any other way. So, why is that? Why is Grub refusing to boot after I removed that drive? Give us a look at your /boot/grub/device.map and /boot/grub/grub.conf, please. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/KsuJ0iMVcrivHFQRAlz4AJ4wvuS5wRz5hjnDeTCbn2QOJ2f08wCdGwm/ jndTntCYno7i6ps22sRQTm4= =H2kQ -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
Michael Schwendt wrote: Give us a look at your /boot/grub/device.map and /boot/grub/grub.conf, please. cat /boot/grub/device.map # this device map was generated by anaconda (fd0) /dev/fd0 (hd0) /dev/hda grub.conf was posted a moment ago. -- W | I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
Just do a grub-install /dev/hda to reinitialize grub on the correct partition and everything should be fine, KISS. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Schwendt Sent: Friday, August 01, 2003 4:20 PM To: [EMAIL PROTECTED] Subject: Re: GRUB failure -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 01 Aug 2003 13:22:57 -0600, Ashley M. Kirchner wrote: Recently I had to remove /dev/hdb from a server to get it replaced. The OS is installed entirely on /dev/hda (including swap), and hdb was a mere backup drive (it was actually added AFTER the server was initially installed, up and running.) Nothing on the OS depended on this drive being there, or being accessible. However, to my surprise, after removing the drive and attempting to start the server back up, I was presented with a black screen with the word GRUB in the upper left hand corner. Nothing else, it wouldn't boot, it just sat there. The only way I was able to get the server running again was to either put hdb back into the system, or boot off of the boot floppy I always keep around. That boots the system up and runs just fine, but it won't boot any other way. So, why is that? Why is Grub refusing to boot after I removed that drive? Give us a look at your /boot/grub/device.map and /boot/grub/grub.conf, please. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/KsuJ0iMVcrivHFQRAlz4AJ4wvuS5wRz5hjnDeTCbn2QOJ2f08wCdGwm/ jndTntCYno7i6ps22sRQTm4= =H2kQ -END PGP SIGNATURE- -- 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
RE: GRUB failure
Barry Johnson wrote: Just do a grub-install /dev/hda to reinitialize grub on the correct partition and everything should be fine, KISS. You'd think it'd be that easy. It wasn't. I did try that, and got the same result. For some reason now, it absolutely must have an /dev/hdb otherwise it just won't boot. I know this isn't a BIOS issue because that's working just fine, with or without the drive. This is a Grub booting problem and I can't figure out -what- exactly. -- W | I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 01 Aug 2003 14:21:13 -0600, Ashley M. Kirchner wrote: cat /boot/grub/device.map # this device map was generated by anaconda (fd0) /dev/fd0 (hd0) /dev/hda grub.conf was posted a moment ago. Interesting. I had hoped to find hd0 and hd1 being swapped and GRUB trying to access hda with the drive id of hdb. Provided that it is not a hardware problem (master/slave configuration on hda), boot with boot disk or rescue mode and run grub-install /dev/hda as root. That should fix it. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Ks/U0iMVcrivHFQRArfKAJ468X9UcY4cq1QnAQ84VFV/kQynGACgiGdU 0gI8WBZwsvJvZ9srW8YOzTQ= =/tPF -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
Let's analyze it. Grub needs the grub.conf file. You deleted hdb and now Grub can't find the .conf file. So you need to do something that points GRUB to grub.conf. So maybe you had a link or something else that pointed GRUB to the .conf file. On Fri, 2003-08-01 at 15:27, Ashley M. Kirchner wrote: Barry Johnson wrote: Just do a grub-install /dev/hda to reinitialize grub on the correct partition and everything should be fine, KISS. You'd think it'd be that easy. It wasn't. I did try that, and got the same result. For some reason now, it absolutely must have an /dev/hdb otherwise it just won't boot. I know this isn't a BIOS issue because that's working just fine, with or without the drive. This is a Grub booting problem and I can't figure out -what- exactly. -- W | I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
Otto Haliburton wrote: Let's analyze it. Grub needs the grub.conf file. You deleted hdb and now Grub can't find the .conf file. So you need to do something that points GRUB to grub.conf. So maybe you had a link or something else that pointed GRUB to the .conf file. You're not reading everything I'm telling you guys: THERE IS NOTHING ON hdb! Everything is on hda. hdb is completely devoid of information but for the lost+found folder, nothing else. In fact, when the system was originally installed, it ONLY had hda, and it worked fine and booted fine. Months later I added hdb as a backup drive, and used it to manually copy stuff from one drive to the other. Nothing was moved, no partitions changed, all the system files and OS in general stayed on hda. As time went by, we started shuffling things around on the OTHER drives you see in the df output, hdb was never made an active partition, except for when it was needed for backup. Now that I removed it, grub's not booting. -- W | I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
What I'm saying is that we know what the problem is and that is GRUB can't find the .conf file period. Your solution lies in getting GRUB to find the .conf file. On Fri, 2003-08-01 at 15:45, Ashley M. Kirchner wrote: Otto Haliburton wrote: Let's analyze it. Grub needs the grub.conf file. You deleted hdb and now Grub can't find the .conf file. So you need to do something that points GRUB to grub.conf. So maybe you had a link or something else that pointed GRUB to the .conf file. You're not reading everything I'm telling you guys: THERE IS NOTHING ON hdb! Everything is on hda. hdb is completely devoid of information but for the lost+found folder, nothing else. In fact, when the system was originally installed, it ONLY had hda, and it worked fine and booted fine. Months later I added hdb as a backup drive, and used it to manually copy stuff from one drive to the other. Nothing was moved, no partitions changed, all the system files and OS in general stayed on hda. As time went by, we started shuffling things around on the OTHER drives you see in the df output, hdb was never made an active partition, except for when it was needed for backup. Now that I removed it, grub's not booting. -- W | I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
Michael Schwendt wrote: Interesting. I had hoped to find hd0 and hd1 being swapped and GRUB trying to access hda with the drive id of hdb. Provided that it is not a hardware problem (master/slave configuration on hda), boot with boot disk or rescue mode and run grub-install /dev/hda as root. That should fix it. Hardware wise, everything checks out. BIOS wise, everything checks out. And I did try re-installing grub again, but that didn't help either. As it is, this is fast becoming a moot point since the replacement drive is in and the machine boots as it should again. Once again, let me make it clear: there is absolutely NOTHING on hdb1. I created the partition and formatted it, nothing else. Now Grub boots again. As soon as I disconnect the drive (and update the BIOS,) grub fails. -- W | I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
Otto Haliburton wrote: What I'm saying is that we know what the problem is and that is GRUB can't find the .conf file period. Your solution lies in getting GRUB to find the .conf file. And my question since the very beginning was: WHY? There is nothing on hdb that should affect how grub boots. There is nothing in any of grub's files that tells it to go find hdb. As far is I'm concerned, grub shouldn't even care whether hdb is there or not, leave it to the mounting process later in the game. And reinstalling grub on hda (where it has been all along) didn't make any difference either, it still wouldn't boot. -- W | I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
On Fri, 2003-08-01 at 15:55, Ashley M. Kirchner wrote: Otto Haliburton wrote: What I'm saying is that we know what the problem is and that is GRUB can't find the .conf file period. Your solution lies in getting GRUB to find the .conf file. And my question since the very beginning was: WHY? There is nothing on hdb that should affect how grub boots. There is nothing in any of grub's files that tells it to go find hdb. As far is I'm concerned, grub shouldn't even care whether hdb is there or not, leave it to the mounting process later in the game. And reinstalling grub on hda (where it has been all along) didn't make any difference either, it still wouldn't boot. -- W | I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. Something is changing when you remove hdb that causes GRUB not to be able to find the .conf file. Maybe the partitions are being renumbered or something to that effect. I suggest you get a listing before removing the hdb and after removing with the idea that something is causing GRUB to lose where the .conf file is located. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: GRUB failure
I missed your previous input and you cut out all the running dialog so i have no clue as to what has already been discussed , so soorry for anything stupid here... but here's two cents worth Sort sounds like your hardware configuration is not correct anymore, like you forgot to undo something you changed when you installed the second drive. Did ya change the master/slave jumper on the HDa drive to single drive when you removed the hdb drive by any chance? Is this a compaq by any chance that would now prefer you switched to cable select? Does the drive show up in the bios? does it actually try to boot? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ashley M. Kirchner Sent: Friday, August 01, 2003 4:45 PM To: [EMAIL PROTECTED] Subject: RE: GRUB failure Otto Haliburton wrote: Let's analyze it. Grub needs the grub.conf file. You deleted hdb and now Grub can't find the .conf file. So you need to do something that points GRUB to grub.conf. So maybe you had a link or something else that pointed GRUB to the .conf file. You're not reading everything I'm telling you guys: THERE IS NOTHING ON hdb! Everything is on hda. hdb is completely devoid of information but for the lost+found folder, nothing else. In fact, when the system was originally installed, it ONLY had hda, and it worked fine and booted fine. Months later I added hdb as a backup drive, and used it to manually copy stuff from one drive to the other. Nothing was moved, no partitions changed, all the system files and OS in general stayed on hda. As time went by, we started shuffling things around on the OTHER drives you see in the df output, hdb was never made an active partition, except for when it was needed for backup. Now that I removed it, grub's not booting. -- W | I haven't lost my mind; it's backed up on tape somewhere. +--- - Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- 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
RE: GRUB failure
Maybe grub knows about the second drive through Kudzu finding it or something, it is listed in grubs config file and grubs barfs when it cant find it even though it is irrelavant, if true then this is a probably a bug in grub (pun intended) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ashley M. Kirchner Sent: Friday, August 01, 2003 4:52 PM To: [EMAIL PROTECTED] Subject: Re: GRUB failure Michael Schwendt wrote: Interesting. I had hoped to find hd0 and hd1 being swapped and GRUB trying to access hda with the drive id of hdb. Provided that it is not a hardware problem (master/slave configuration on hda), boot with boot disk or rescue mode and run grub-install /dev/hda as root. That should fix it. Hardware wise, everything checks out. BIOS wise, everything checks out. And I did try re-installing grub again, but that didn't help either. As it is, this is fast becoming a moot point since the replacement drive is in and the machine boots as it should again. Once again, let me make it clear: there is absolutely NOTHING on hdb1. I created the partition and formatted it, nothing else. Now Grub boots again. As soon as I disconnect the drive (and update the BIOS,) grub fails. -- W | I haven't lost my mind; it's backed up on tape somewhere. +--- - Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- 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
RE: GRUB failure
I agree that what is suggested here could also be a possibility to chech out. On Fri, 2003-08-01 at 16:04, Kenneth Goodwin wrote: I missed your previous input and you cut out all the running dialog so i have no clue as to what has already been discussed , so soorry for anything stupid here... but here's two cents worth Sort sounds like your hardware configuration is not correct anymore, like you forgot to undo something you changed when you installed the second drive. Did ya change the master/slave jumper on the HDa drive to single drive when you removed the hdb drive by any chance? Is this a compaq by any chance that would now prefer you switched to cable select? Does the drive show up in the bios? does it actually try to boot? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ashley M. Kirchner Sent: Friday, August 01, 2003 4:45 PM To: [EMAIL PROTECTED] Subject: RE: GRUB failure Otto Haliburton wrote: Let's analyze it. Grub needs the grub.conf file. You deleted hdb and now Grub can't find the .conf file. So you need to do something that points GRUB to grub.conf. So maybe you had a link or something else that pointed GRUB to the .conf file. You're not reading everything I'm telling you guys: THERE IS NOTHING ON hdb! Everything is on hda. hdb is completely devoid of information but for the lost+found folder, nothing else. In fact, when the system was originally installed, it ONLY had hda, and it worked fine and booted fine. Months later I added hdb as a backup drive, and used it to manually copy stuff from one drive to the other. Nothing was moved, no partitions changed, all the system files and OS in general stayed on hda. As time went by, we started shuffling things around on the OTHER drives you see in the df output, hdb was never made an active partition, except for when it was needed for backup. Now that I removed it, grub's not booting. -- W | I haven't lost my mind; it's backed up on tape somewhere. +--- - Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- 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
Re: [RH List] RE: GRUB failure
Kenneth Goodwin wrote: Did ya change the master/slave jumper on the HDa drive to single drive when you removed the hdb drive by any chance? Is this a compaq by any chance that would now prefer you switched to cable select? Does the drive show up in the bios? does it actually try to boot? Hardware wise, everything checks out. Without the second drive, hda gets set to master (jumper gets removed), and with it gets set to master with slave, and hdb set as slave. (I don't believe in cable select because it caused me more problems that it's worth.) And no, it's not an inferior Compaq. BIOS wise, everything checks out again. It sees what it has and moves on. And yes, it does try to boot up which is how I get the GRUB line on the screen, but nothing else. Dropping the boot floppy in the system, it boots fine. And now that I've reinstalled hdb, it all works again, however as soon as I disconnect it (and revert all jumper and bios settings back to single drive), grub fails. [ answering your second message here as well ] Maybe grub knows about the second drive through Kudzu finding it or something, Kudzu's not installed on the machine. it is listed in grubs config file and grubs barfs when it cant find it Do you see it listed in grubs config (which I posted earlier)? I certainly don't. -- W | I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01 Aug 2003 15:51:02 -0500, Otto Haliburton wrote: What I'm saying is that we know what the problem is and that is GRUB can't find the .conf file period. Your solution lies in getting GRUB to find the .conf file. No, no, no. You haven't understood the problem, it seems. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Ktxr0iMVcrivHFQRAvE7AJ4gWXCnUfqYvTNF2IkXvMS+/jurigCeJWso ++HYAcD/kcSL2vnS4MU+HxM= =eKVi -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
The problem is, I have understood the problem. You can't boot when GRUB can't find grub.conf. You can when it can. When you remove hdb GRUB can't find the .conf file and that is why you can't boot. That's your problem. You are trying analyze why it can't find that file and that is your question. I'm suggesting that something is changing which is causing GRUB not to be able to find this file. I have had a similar problem when I deleted a partition, so I fully understand what is going on. Thanks. On Fri, 2003-08-01 at 16:32, Michael Schwendt wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01 Aug 2003 15:51:02 -0500, Otto Haliburton wrote: What I'm saying is that we know what the problem is and that is GRUB can't find the .conf file period. Your solution lies in getting GRUB to find the .conf file. No, no, no. You haven't understood the problem, it seems. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Ktxr0iMVcrivHFQRAvE7AJ4gWXCnUfqYvTNF2IkXvMS+/jurigCeJWso ++HYAcD/kcSL2vnS4MU+HxM= =eKVi -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 01 Aug 2003 14:27:48 -0600, Ashley M. Kirchner wrote: Barry Johnson wrote: Just do a grub-install /dev/hda to reinitialize grub on the correct partition and everything should be fine, KISS. You'd think it'd be that easy. It wasn't. I did try that, and got the same result. For some reason now, it absolutely must have an /dev/hdb otherwise it just won't boot. I know this isn't a BIOS issue because that's working just fine, with or without the drive. This is a Grub booting problem and I can't figure out -what- exactly. Without /dev/hdb installed, what do you get when you boot with boot disk, then start grub and execute find /boot/grub/grub.conf in GRUB shell? As a second test, also without /dev/hdb installed, what do you get for grub-install --recheck /dev/hda ; cat /boot/grub/device.map ? In fact, when the system was originally installed, it ONLY had hda, and it worked fine and booted fine. Months later I added hdb as a backup drive, That, however, suggests that you introduced a hardware problem. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Kt9h0iMVcrivHFQRAkmVAKCIlYU444s24u2gyFme00SIvx+KtgCdHb2k VkNSrsk2b3FzWaoc45xNvwc= =jRrC -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
You are getting GRUB when you boot because it is properly transferring to the MBR, but when it tries to determine where to locate the kernel image it can't fine the .conf file which tells it where that image is located. If you added a string to the boot instruction telling it where the .conf file is it will boot. On Fri, 2003-08-01 at 16:41, Otto Haliburton wrote: The problem is, I have understood the problem. You can't boot when GRUB can't find grub.conf. You can when it can. When you remove hdb GRUB can't find the .conf file and that is why you can't boot. That's your problem. You are trying analyze why it can't find that file and that is your question. I'm suggesting that something is changing which is causing GRUB not to be able to find this file. I have had a similar problem when I deleted a partition, so I fully understand what is going on. Thanks. On Fri, 2003-08-01 at 16:32, Michael Schwendt wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01 Aug 2003 15:51:02 -0500, Otto Haliburton wrote: What I'm saying is that we know what the problem is and that is GRUB can't find the .conf file period. Your solution lies in getting GRUB to find the .conf file. No, no, no. You haven't understood the problem, it seems. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Ktxr0iMVcrivHFQRAvE7AJ4gWXCnUfqYvTNF2IkXvMS+/jurigCeJWso ++HYAcD/kcSL2vnS4MU+HxM= =eKVi -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01 Aug 2003 16:41:17 -0500, Otto Haliburton wrote: The problem is, I have understood the problem. You can't boot when GRUB can't find grub.conf. GRUB doesn't even come that far as was explained in the first message. If it booted into GRUB shell and then wouldn't find the config file, that would be a minor problem. You can when it can. When you remove hdb GRUB can't find the .conf file and that is why you can't boot. As was shown, the config file is on /dev/hda1 and /dev/hdb does not appear anywhere. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/KuBg0iMVcrivHFQRAi4nAJ4/hOWZw+ZQi5jwybAgZQVEnjsMNgCff5p1 8+i+mKCfBFF6sUAbDcIieQA= =E7F/ -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01 Aug 2003 16:46:29 -0500, Otto Haliburton wrote: You are getting GRUB when you boot because it is properly transferring to the MBR, but when it tries to determine where to locate the kernel image it can't fine the .conf file which tells it where that image is located. If you added a string to the boot instruction telling it where the .conf file is it will boot. Replies at the top only mess up the context. The boot process does not even come as far as GRUB stage2, so forget about adding any boot parameters. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/KuES0iMVcrivHFQRAtIuAJ9bxz1aFBKqQnPJ8JuwU1Qj9haWYQCeKVsH AB6xmvntWVGj03cGSqNw3Nk= =NjZe -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RE: [RH List] RE: GRUB failure
Did ya change the master/slave jumper on the HDa drive to single drive when you removed the hdb drive by any chance? Is this a compaq by any chance that would now prefer you switched to cable select? Does the drive show up in the bios? does it actually try to boot? Hardware wise, everything checks out. Without the second drive, hda gets set to master (jumper gets removed), and with it gets set to master with slave, and hdb set as slave. (I don't believe in cable select because it caused me more problems that it's worth.) And no, it's not an inferior Compaq. BIOS wise, everything checks out again. It sees what it has and moves on. And yes, it does try to boot up which is how I get the GRUB line on the screen, but nothing else. Dropping the boot floppy in the system, it boots fine. And now that I've reinstalled hdb, it all works again, however as soon as I disconnect it (and revert all jumper and bios settings back to single drive), grub fails. [ answering your second message here as well ] Maybe grub knows about the second drive through Kudzu finding it or something, Kudzu's not installed on the machine. substitute anaconda for kudzu... it is listed in grubs config file and grubs barfs when it cant find it Do you see it listed in grubs config (which I posted earlier)? I certainly don't. unfortuantely I did not see that earlier posting like i said in my first posting so no I did not. In any case, perhaps grub utilizes another file that has the hardware configuration defined in it and hangs when it detects a disk drive change due to confusion.. I suggest your answer lies with the people that wrote grub unless you care to read the source yourself. -- W | I haven't lost my mind; it's backed up on tape somewhere. +--- - Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- 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
Re: GRUB failure
Again, you're not understanding the problem. When you boot you transfer to the MBR which loads GRUB. GRUB then loads the config file and prints the boot images and identifies to itself where the kernels images are located. When you select one it transfers to that kernel image location. Sines it can't find the .conf file it has nothing to post so it crashes. On Fri, 2003-08-01 at 16:49, Michael Schwendt wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01 Aug 2003 16:41:17 -0500, Otto Haliburton wrote: The problem is, I have understood the problem. You can't boot when GRUB can't find grub.conf. GRUB doesn't even come that far as was explained in the first message. If it booted into GRUB shell and then wouldn't find the config file, that would be a minor problem. You can when it can. When you remove hdb GRUB can't find the .conf file and that is why you can't boot. As was shown, the config file is on /dev/hda1 and /dev/hdb does not appear anywhere. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/KuBg0iMVcrivHFQRAi4nAJ4/hOWZw+ZQi5jwybAgZQVEnjsMNgCff5p1 8+i+mKCfBFF6sUAbDcIieQA= =E7F/ -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
For you to solve this problem I think that you need to read what happens when you boot. I'm not trying to insult you but from what you are stating you don't understand how the computer boots and therefore what happens in GRUB. On Fri, 2003-08-01 at 16:52, Michael Schwendt wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01 Aug 2003 16:46:29 -0500, Otto Haliburton wrote: You are getting GRUB when you boot because it is properly transferring to the MBR, but when it tries to determine where to locate the kernel image it can't fine the .conf file which tells it where that image is located. If you added a string to the boot instruction telling it where the .conf file is it will boot. Replies at the top only mess up the context. The boot process does not even come as far as GRUB stage2, so forget about adding any boot parameters. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/KuES0iMVcrivHFQRAtIuAJ9bxz1aFBKqQnPJ8JuwU1Qj9haWYQCeKVsH AB6xmvntWVGj03cGSqNw3Nk= =NjZe -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
On Fri, 2003-08-01 at 16:52, Michael Schwendt wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01 Aug 2003 16:46:29 -0500, Otto Haliburton wrote: You are getting GRUB when you boot because it is properly transferring to the MBR, but when it tries to determine where to locate the kernel image it can't fine the .conf file which tells it where that image is located. If you added a string to the boot instruction telling it where the .conf file is it will boot. Replies at the top only mess up the context. The boot process does not even come as far as GRUB stage2, so forget about adding any boot parameters. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/KuES0iMVcrivHFQRAtIuAJ9bxz1aFBKqQnPJ8JuwU1Qj9haWYQCeKVsH AB6xmvntWVGj03cGSqNw3Nk= =NjZe -END PGP SIGNATURE- sorry about replying at the top. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01 Aug 2003 16:56:58 -0500, Otto Haliburton wrote: For you to solve this problem I think that you need to read what happens when you boot. I'm not trying to insult you but from what you are stating you don't understand how the computer boots and therefore what happens in GRUB. It's not me who has the problem. It's Ashley. ;) I suggest you dig out the very first message and read it again. If you want to see how it looks like, try the following: $ su - # mv /boot/grub/stage2 /boot/grub/stage2.bak # reboot Then from what you see on the black screen, drop everything except the word GRUB in the upper left corner. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/KuT10iMVcrivHFQRAkaxAJ92e/v8upGLr5FPoJ6uvz/R9pRkLACfXMIu zebxM/XZ7HZ0aosfvesoMBA= =o07C -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: GRUB failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01 Aug 2003 16:54:23 -0500, Otto Haliburton wrote: Again, you're not understanding the problem. When you boot you transfer to the MBR which loads GRUB. GRUB then loads the config file and prints the boot images and identifies to itself where the kernels images are located. When you select one it transfers to that kernel image location. Sines it can't find the .conf file it has nothing to post so it crashes. I won't repeat myself a third time after this one: If you had read Ashley's original post, you would have seen this description: : I was presented with a black screen with the word GRUB in the : upper left hand corner. Nothing else, it wouldn't boot, it just : sat there. What does that tell you? Certainly not that GRUB doesn't find the config file. It doesn't not even load stage2 from within stage1.5. Period. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/KuW00iMVcrivHFQRAg4PAJ4qM5d54+iOoZHLOtS5iukGa/p9owCgg4Qr llH9e6XtQJG1/Bzmc3WVAV8= =Mr5o -END PGP SIGNATURE- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
