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):
Steps to Reproduce:
1. Install redhat with indicated partitions
2. boot system
Boot hangs up at "checking root"
Should boot ok
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
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/