Bug 86484 - Boot Hangs at "Checking Root" on 200gb hard drive
Boot Hangs at "Checking Root" on 200gb hard drive
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
8.0
i386 Linux
high Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-23 22:10 EST by Greg Corson
Modified: 2005-10-31 17:00 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:40:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Greg Corson 2003-03-23 22:10:17 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).
Comment 1 Alan Cox 2003-03-24 07:22:06 EST
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.
Comment 2 Greg Corson 2003-03-24 10:43:28 EST
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.
Comment 3 Alan Cox 2003-03-24 12:39:55 EST
The rawhide kernel might well work a lot better
Comment 4 Greg Corson 2003-03-30 15:34:28 EST
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.
Comment 5 Bugzilla owner 2004-09-30 11:40:41 EDT
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/

Note You need to log in before you can comment on or make changes to this bug.