The boot process hangs with the message 'GRUB' when booting from a hard disk attached to a SCSI controller.

-just to answer my previous question.

There are two possible causes:

The INT13 extension (LBA addressing) for hard disks has not been activated in the SCSI controller's BIOS.
LBA does not work due to a faulty BIOS in the SCSI controller. The BIOS "informs" the boot loader GRUB that it is using LBA addressing, but uses CHS addressing instead. As a result, GRUB cannot find one of the files required for booting (stage2, which contains GRUB's program code.

The solution is quite simple in the case of cause number one: activate the INT13 extension (LBA addressing) in the SCSI controller's BIOS.

For cause number two, several solutions are possible:

If the controller is equipped with a Flash BIOS, a BIOS update should solve the problem.
If not, disable the INT13 extension in the SCSI BIOS. In this case, note that the partition containing the boot loader files as well as the kernel and INITRD (usually the boot partition) must be located within the first 1024 cylinders (in the first 8 GB). Otherwise, you would encounter the 1024 cylinder problem (see SDB:The Boot Process Hangs with the Message GRUB Geom Error)

From SuSE Linux 8.2 on, you also have the possibility to use the GRUB parameter --force-lba=off, which disables the LBA support. Boot the installed system using the first CD/DVD and insert this parameter in the file /etc/grub.conf. To do this, open this file in a root shell with an editor of your choice (e.g., pico):
pico -w /etc/grub.conf
Insert the parameter in the second line, making sure there are no line breaks. The file might look like this:
root (hd0,4)
install --force-lba=off --stage2=/boot/grub/stage2 /grub/stage1 d (hd0) /grub/stage2 0x8000 (hd0,4)/grub/menu.lst
quit
Save the file (STRG-O), close the editor (STRG-X), and reinstall the boot loader by entering the following command in the root shell:
grub --batch --device-map=/boot/grub/device.map </etc/grub.conf
For more information about this problem, refer to the documentation for GRUB, which is available online at http://www.gnu.org/manual/grub/html_mono/grub.html#FAQ or can be viewed with the shell command info grub.

When I decided to update my recently installed Gentoo AMD64 system, I noted the update to grub and decided to upgrade from grub-0.96-r2 to grub-0.97-r2, the latest stable ebuild. The /boot directory is on the separate partition /dev/sda3 (hd0,2), which chain-loaded from the WinXP bootloader and which worked flawlessly with 0.96-r2, with the following:

Code:

grub> root (hd0,2)
grub> setup (hd0,2)

After the update, grub setup to /dev/sda3, copying the first 512 bytes of /dev/sda3 to a file and overwriting C:\linux.bin on (hd0,0) (configured in C:\boot.ini to boot Linux from the XP bootloader), grub would only boot to the CLI and not to the boot menu (/boot/grub/menu.lst -> grub.conf). However, given 'grub> configfile (hd0,2)/grub/grub.conf' and its analogues, it would find the menu and boot from the menu.

I found many reports online from people looking for answers to the same sort of boot problem, but the user's problem usually involved a mistake by the user, as in the following:

the lack of the symbolic link /boot/boot -> .;
the lack of the symbolic link /boot/grub/menu.lst -> grub.conf;
the lack of understanding about the installation, configuration and boot processes, usually by a new user.

In fact, in the majority of cases, the responses suggested re-installing grub with grub-install, overwriting the MBR, which I hadn't planned to do--ie.

Code:

grub> root (hd0,2)
grub> setup (hd0)

Finally, I gave up, overwrote the MBR and re-configured the system to chain-load XP from grub (instead of chaining grub from the XP bootloader), but I'd still like to understand the problem. Why wouldn't grub-0.97-r2 chain-load from the XP bootloader to the separate /boot partition, when it worked perfectly well in grub-0.96-r2? Is the lack of this functionality a new feature or a missing feature in the newer version?

I have the "After hitting enter at the grub menu the screen goes black"-error. The solution "Turn off framebuffer (typically remove vga=XYZ from your grub.conf) and check the processor architecture in your kernel config. " is not working for me. I do not have framebuffer enabled and I've tried all different arches in kernel config, namely generic x86_64, em64t and athlon64.

I did a stage3 install on a drive from my amd64 box and then hooked it up to my conroe box, a hdd transplant. (Actually I only switched the sata data cable.) In amd64 box the kernel is loaded (and then panics), but on conroe I get the black screen. I didn't have the bootable flag set, but turning it on didn't help. I've tried both -march=nocona and then -march=athlon64 (I can boot amd64 liveDVD), and compiled and installed grub, but it makes no difference. I've tried enabling vesa driver in kernel but it didn't help. When I boot liveDVD isolinux says my BIOS is extremely broken, but I experience no ill effects. I'm really really really out of ideas now. One more thing. If I edit grub.conf to point to a non-existent kernel image it complains about file not found. I only get the black screen for existing kernels.

hakbeest;
This is a bit of a longshot, but when you were configuring your kernel did you turn on any framebuffering in the kernel config options? For me it was a good thing, but when I turned on the kernel framebuffering options in make menuconfig I got a framebuffer console *without* putting any kind of framebuffer parameter on the grub.conf command line. It sounds to me like you might have something wrong set in one of those options that blanks out the screen when the kernel starts to load.

From your description sounds to me like your problem is more kernel related than GRUB related. Given that you get an error when pointing to a non-existent kernel it sounds like GRUB is installed properly and is trying to do the right thing. If the screen is going blank when you start loading an existing kernel it sounds to me like something is wrong with that kernel. Sorry I can't give more of a hint as to what.

Is there any way you can boot the system with a liveCD or some such and look to see what is in dmesg or any other logs that might say what the kernel thinks it's doing?

Gooserider, it does seem that framebuffer console is not working for me. A kernel without framebuffer is now working fine for me. I guess simply having framebuffer support compiled into the kernel does make a difference, even though it is not enabled by the boot options.

Its quite possible to build a kernel with no console screen support at all.
This produces the symptoms you describe. Everything still works but with no console output, its hard to tell.
Genkernel won't do this, but you can do it for yourself with menuconfig (yes - I've done it)

Is there any evidence the boot process contines after the screen go black ?
Does the display go into standby ?_________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

the kernel booted fine on my other machine, so it did have proper console support. I don't know for sure if the boot process continues, but by recompiling the working kernel I have now with framebuffer support added and vga=0x31b boot option I get the black screen. So it seems my 7900GT doesn't work with framebuffer.

Some of you may have been watching my battle with trying to get my system to boot off the hard drive starting back in part 6.

If I tried to boot off the hard drive I got a grub error "GRUB Hard Disk Error" I didn't find anything in the Grub Error Collection document (I put in a bug about that ) So I went to the GNU grub documentation and found this sort of explanation... "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."

My interpretation of this is that POST is completing, the system is finding the hard drive, and reading the boot sector (Head 0, Track 0, Sector 0) OK, but for some reason it is bombing when it gets to figuring out the hard drive geometry as part of loading stage1.5 or 2, which is the part of grub that actually gives you the menu or grub prompt on the display.

However, if I put grub on a boot floppy and told that grub to boot the kernel on the hard drive everything worked fine I ended up making a boot floppy with my grub.conf menu on it, and that worked, but I felt it was a really ugly hack of a solution. But I wrote that up and submitted it as a proposed LAST RESORT fix for that error.

Some of the suggestions I found and tried...
I tried changing the addressing mode of the hard drive in the BIOS. NOPE, didn't help!
I tried scrapping the entire install, repartitioning the drive from scratch, and doing a completely new install, using 2005.1 instead of 2005.0
Got the same results
Re-installed Grub more times than I can count, using both the manual and automatic installers, never got any error messages, (except when I KNEW I was doing something wrong to prove it wouldn't work) and never got a better result.

I kept poking at things however, and opened dialogs with the tech support folks at both Gigabyte (mobo maker) and Samsung (hard drive) Neither of whom turned out to be terribly useful. Samsung had no clue about what to do with a Linux box, it's bad when you have to tell the TIER 2 tech support guy how Grub is supposed to work,... Gigabyte was in some ways even more useless - they kept asking me questions about my hardware setup that I had answered in the first post of my thread with them.

I did find eventually that my motherboard had a fairly early BIOS rev. (F2) and that there were several updates (latest is F11) Of course even though Gigabyte claims their on-board "Q-Flash" upgrade utility is O/S independent, they don't tell you that all the upgrade files are in a proprietary Windows 9x+ format. They just have a .exe extension and won't work straight in the upgrade utility (instead you get a non-informative error message). (Did I mention that I don't have a recent Winblows setup?)

One of my partitions has DOS 6x on it, but the file won't execute, tells me it needs Win32. I figure maybe its a self extracting ZIP, but gunzip won't touch it either. Finally I looked at the file with the "strings" utility and found a hint that it was a Windows RAR archive. After I asked in another thread, I found there actually is an "unrar" utility that can open them under Linux. This finally let me get them into a format that I could transfer to a floppy with mtools, and use to upgrade the BIOS.

I didn't test the intermediate files, and just bumped it from rev. F2 to rev. F11, but when I did the reboot after the upgrade, MY HARD DRIVE WORKED!!!

I now start Grub directly off the hard disk, and everything boots up fine, so I can class this problem as solved!

Thanks Jmbsvicetto, it was one of those things that kept bugging me and I didn't want to let it go until I fixed it. It was also keeping me from doing some of the other things I was wanting to do like move my working setups to the new box since I didn't want to risk needing to do another re-install.

Now that I have things working I can do some consolidation and finish installing stuff I'd been holding off on.

I am somewhat dissapointed though that this problem and fix doesn't seem like it is going to make it into the Grub Error Collection document. I filed a bug about this, and it keeps getting closed. I will grant that my fixes aren't as straightforward and elegant as many of the other problems discussed, and I agree that my initial fix of the boot floppy is an ugly hack of a band-aid for the underlying problem, but it did work.

I also agree that strictly speaking, it isn't a Grub problem, but it appears as one, and Grub generates the error message, so I think it should be dealt with, or at least acknowledged in the documentation. Fortunately, as far as I can tell the error is very rare judging by how seldom it is mentioned in these many threads That doesn't mean it shouldn't be mentioned, even if that mention is fairly short.

As a final note, I think my boot floppy trick might be useful for more problems than just mine. I've gotten the distinct impression that a significant number of the errors we see in these threads are because Grubs sees the drives differently than the way the user thinks does. This leads to the question of what the real configuration should be. Since the floppy is a single interface that can usually be made to boot first, (I remember the bad old days when the floppy always tried to boot first...) a bootable grub floppy makes a good reliable starting point.
Then one can use the manual boot process and tab-completion to find out what grub thinks the configuration really is. It can also be used to test whether a given problem is a really a grub issue or if there is a kernel configuration problem.

(BTW, this isn't meant as a flame / rant, at the document maintainers, but I felt the need to vent a bit - this is the sort of thing that makes me feel less inclined to try to contribute when what I offer doesn't seem appreciated.)

let me try and see if I can convince people to include two lessons from your experience: "make sure you have a recent and stable version of your BIOS firmware - if you still can't boot from the disk after checking everything, the firmware might be the cause; an excellent tool to help diagnose problems is to use a GRUB floppy".
What do you think?_________________Jorge.

jmbsvicetto
Gooserider,
let me try and see if I can convince people to include two lessons from your experience: "make sure you have a recent and stable version of your BIOS firmware - if you still can't boot from the disk after checking everything, the firmware might be the cause; an excellent tool to help diagnose problems is to use a GRUB floppy".
What do you think?

Seems like a reasonable solution, and is essentially what I was attempting to contribute. My experience strongly suggests that the error is caused by a hardware incompatibility, and that updating the BIOS may fix the problem. If it doesn't, or if this can't be done for some reason, then the GRUB floppy is at least a workaround.

The only other discussion mentioning the same error that I recall seeing suggested making sure the drive was configured to use LBA addressing, but it wasn't real clear if that actually solved the problem. In my case I think the automatic configuration had already picked LBA, and making it manually specified didn't help that I could tell.

I did write up a fairly lengthy piece on creating a GRUB floppy, but that was mostly because I was told the maintainers didn't want to point people at a non-Gentoo article, or something on the wiki. Since they didn't, I attempted to combine the command sequences from a couple different articles (fair use) with my own instructions to make something that could be incorporated into the document without going to a non-acceptable source. I don't insist on it being used in the main document, but it might be nice if it were kept somewheres that people could find it if needed.

Quote:

hakbeest
seems like a useful contribution, but who uses floppy drives anymore these days? USB sticks and cdroms, yes.

Perhaps, though I still see a fair number of boxes being sold with floppy drives, and most cases that I see still have 3.5" external floppy bays, (useless for CD's) - Whether anyone ever sticks something in them or not is a seperate question. Even on boxes sold w/o floppies, how many of them don't have a legacy floppy interface?

At any rate, of the 6 boxes currently on my home network or in semi-active use, I count the following removeable media
Five w/ 3.5" floppys
One w/ a DVD burner, four more that can only read CD's
One w/ USB 1.0 only ports, One w/ USB 2.0 - 1.0 ports....

The one box w/o a CD is the GF's old Mac (MacOS 6.x IIRC), and the one without a floppy is her Windows notebook from work (I think it has a swappable drive that could make the CD into a floppy, but I'm not sure...)

Bottom line, I can read and write a floppy on any machine I need to, but no other media gives me that choice. (I will grant that I probably have more legacy vintage hardware in active use than most - but don't we advocate for Linux by pointing out that it works well on legacy hardware that doesn't work well w/ Windblows?)

I agree that floppies are a vanishing species, but I suspect (without any hard numbers to prove it) that you will still find them the lowest common medium for exchange.

Finally, as it applies to this case in particular, I did use a floppy, and made my report based on that use. While I suspect that one could do similar things w/ optical media or USB sticks, etc. (and said so in the stuff I put in for the bug report) I didn't try to do it, so I can't definitely say that you can, nor can I tell you how...

A few other factors that make the floppy an arguably better choice for this application is that every BIOS I've seen either is hard coded for the floppy to attempt booting before the hard drive (mostly older systems, especially pre-cd vintage) or makes if very easy to set that up. The standard floppy interface only supported two drives maximum, and most people only have one. Thus IMHO it is far easier to make the system find a boot floppy and try to load it than any other kind of device that might be in a multitude of different hardware locations, in combination with an unknown number and types of other devices. Since at least some of the problems I see on this thread relate to confusion about what physical drives / partitions actually match what we are trying to boot off of, I think a simple interface is preferable to one that might be harder to work with. It is also worth remembering that the floppy has been used as a boot device ever since the earliest days of PC's, so there is no question that if you see a working floppy, you can boot off it with a properly formatted disk and the right BIOS settings. The ability to boot was added to CD's and USB's later, and may not be quite as well supported on some hardware, or be fussier to make work.

Bottom line, the floppy may be obsolete in may ways, but it's still stone axe simple to work with, and dead stone reliable...

You can't mount an Extended Partition, only the Logical partitions it contains.
Either you made an error when you installed grub or with grub.conf.
Remember grub counts drives and partitions from 0, not from 1._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

You can't mount an Extended Partition, only the Logical partitions it contains.
Either you made an error when you installed grub or with grub.conf.
Remember grub counts drives and partitions from 0, not from 1.

Ned,

I realise that Extended Partitions can't be mounted, there is no reference to hda2 anywhere as far as I can see, not in /etc/fstab or in /boot/grub/grub.conf or in /boot/grub/menu.1st

Rink_________________"I'm a Snake if we Disagree" - Jethro Tull, "Bungle in the Jungle"