Bug 64958 - Hangs after checking /var during filesystem check on boot
Hangs after checking /var during filesystem check on boot
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: e2fsprogs (Show other bugs)
7.3
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Florian La Roche
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-05-14 22:02 EDT by Ted Kaczmarek
Modified: 2007-04-18 12:42 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-05-26 09:35:28 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 Ted Kaczmarek 2002-05-14 22:02:07 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.1 (X11; Linux i686; U;) Gecko/20020417

Description of problem:
If I say yes during the boot process after a crash it will get stuck on /var. In
single user fsck has no problems.
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/sda7              1004024    137504    815516  15% /
/dev/sda1                46636     19617     24611  45% /boot
/dev/sda3              2016044    199776   1713856  11% /home
none                    257056         0    257056   0% /dev/shm
/dev/sda8               774040     37080    697604   6% /tmp
/dev/sda2             11551080   3315532   7648776  31% /usr
/dev/sda5              1209572    384396    763732  34% /var

I have seen this problem with both 7.2 and 7.3. 


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Crash System(nvidia tweaks)
2.Reboot
3.Say yes to check filesystem
	

Actual Results:  It will get to /var, give you the impression it is going along
fine and then just hang. I made sure to give it plenty of time :-).

Expected Results:  Should complete cheching partition and continue booting.

Additional info:

SCSI subsystem driver Revision: 1.00
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.5
        <Adaptec aic7899 Ultra160 SCSI adapter>
        aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.5
        <Adaptec aic7899 Ultra160 SCSI adapter>
        aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs

  Vendor: SEAGATE   Model: ST318406LW        Rev: 0108
  Type:   Direct-Access                      ANSI SCSI revision: 03
(scsi0:A:0): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
scsi0:A:0:0: Tagged Queuing enabled.  Depth 253
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sda: 35843670 512-byte hdwr sectors (18352 MB)
 sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 >
Comment 1 Ted Kaczmarek 2002-05-26 09:35:23 EDT
Today I decided to try 2.4.19 with the pre8 patch, this seems to have resolved
the problem so far. It finishes checking /var and proceeds to the next
partitions and the boot process completes.

After my next full backup I will try to reproduce this again with 2.4.18-4.I did
notice some fixes in the changelog, but It is beyond my scope to try to relate
these. It almost looks like more of an ide problem if you want my two cents. The
reason I say that is the next partiton after /var is /dev/dev/hdb1 that it checks.
Comment 2 Florian La Roche 2002-08-02 04:40:45 EDT
fsck stalls can be a kernel VM problem, e2fsck should be fine.

Thanks,

Florian La Roche

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