Red Hat Bugzilla – Bug 86484
Boot Hangs at "Checking Root" on 200gb hard drive
Last modified: 2005-10-31 17:00:50 EST
Description of problem: I have a western digital wd2000JBRTL 200gig IDE hard drive installed as the second drive in my system (intended for a linux install). I install from CDs without any errors showing up. On boot, it gets as far as "checking root" in the bootup process, then the system hangs, keyboard reboot doesn't work, have to press reset button. Partitions are (physical) /boot 80meg, / 6 gig, /usr 8 gig (logical) 2 gig swap, 80 gig /home remainder of drive unused. The system has an updated bios that is supposed to support lba 48 and reports the correct drive size on the BIOS boot screens. When I boot to windows (on first drive), I can see the 200gb drive's full capacity and layout under Partition magic without problems. When I boot from CD Rescue, I can mount all the partions, look at them and read files ok. hdparm reports the drive's size and features correctly. running hdparm -t on the drive doesn't work, but you can control-C out of it. I have an identical system at work with a smaller hard drive (80 gig western digital) which works fine. Version-Release number of selected component (if applicable): How reproducible: Every time Steps to Reproduce: 1. Install redhat with indicated partitions 2. boot system 3. Actual results: Boot hangs up at "checking root" Expected results: Should boot ok Additional info: System is an athlon 2k, 1gig ram, 120gb IBM hard disk (windows), 200gb Western Digital hard disk (linux), Asus A7N266-E motherboard with NFORCE chipset and 1004 BIOS (latest with 48 bit LBA support).
Red Hat 8 does not support the nForce chipset for IDE (or anything else much) because of lack of documentation. That also means we drive the chipset in PIO mode so LBA48 problems are not _supposed_ to arise. The newer kernels in the beta know about the nForce but I don't know if the newer driver will help here.
Unless I misunderstand the output of HDPARM, the system has selected UDMA5 mode not one of the PIO modes. This is true on both my office system and home system. HDPARM shows it's not using dma (-d1 switch I think) but the drive is in UDMA5 and not one of the PIO modes. In fact, my office system, which is identical to this one except has a 60g hard drive, has been set to mask interrupts, dma on, 32 bit mode on for some time and works fine. Can you recommend a way to try out a newer kernel with a minimum of fuss? Would a Kernel from RedHat Rawhide have the right stuff in it? It would be a lot easier if I could just get a built kernel from somewhere and test it by booting from a floppy, if that's possible. Also, I have a Promise Ultra 100 IDE card I could put in the machine and move the new hard drive to, if you think that would help.
The rawhide kernel might well work a lot better
I'm wondering, when I do the CD install of Linux, it seems to have no trouble accessing the big hard drive and copying stuff to it. The problem comes in when I reboot to run the system for real. This seems to suggest that the kernel the installer uses is accessing the hard drive in a different, more reliable mode than the final configuration does. Is there some way I can force my kernel to access the disks in the same mode that the installer uses? If I could get this system running (even slowly) it would make it far easier to upgrade to a newer kernel.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/