Bug 6727 - fsck.ext2 gets signal 11 (1.17)
fsck.ext2 gets signal 11 (1.17)
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: e2fsprogs (Show other bugs)
6.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Florian La Roche
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-11-04 12:13 EST by grtllama
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-11-15 11:26:40 EST
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 grtllama 1999-11-04 12:13:03 EST
Last night as my system booted, it was maximal mount count
time.  This in and of itself is probably a good thing, but
when it got to hdb6 (my /usr, about 1.5G) fsck.ext2 died on
signal 11 after fully checking the partition and reporting
contiguousness, etc.  It never marked the filesystem as
having been checked (which caught me in a loop), so I'm
guessing that's where the problem was.
fsck gave a segmentation fault when I ran it from the root
prompt.
The system was fine other than this... there was no data
loss or anything.  (just had to mount the filesystems by
hand and telinit 3)
This problem was solved by removing the e2fsprogs errata for
6.1
Comment 1 Bill Nottingham 1999-11-05 10:58:59 EST
Could you extract the e2fsck binary from the e2fsprogs-1.17, and try
and help track down *where* it's crashing? This would be
very helpful.
Comment 2 grtllama 1999-11-05 15:01:59 EST
bash# fsck -C -c /dev/hdb6
Parallelizing fsck version 1.17 (26-Oct-1999)
e2fsck 1.17, 26-Oct-1999 for EXT2 FS 0.5b, 95/08/09
Checking for bad blocks (read-only test): done
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/hdb6: ***** FILE SYSTEM WAS MODIFIED *****
/dev/hdb6: 54002/415744 files (5.6% non-contiguous), 900667/1657120
blocks
Warning... fsck.ext2 for device /dev/hdb6 exited with signal 11.

During the boot process (when it hits max mount count) it has the same
failure and drops to a root prompt.  It reports that this particular
partition has reached the maximal mount count on the next boot also,
and the following, and the following...
The segfault only occurs when the filesystem is being scanned.  After
I used the older e2fsprogs (1.15) to scan and mark the filesystem as
being scanned (which had no problems), at boot time the newer
e2fsprogs just gave the usual "clean" messsage.  The only time it
segfaults is when it actually scans the disk or tries to fix errors.

The filesystem mounts just fine when I tell it to mount from the
prompt.  The only oddity is that there are character and block devices
in the lost+found directory of the partition that seem to have been
created with random(?) modes.  They can't be removed because the
system responds with "No such device."  I tried to remove them with
debugfs also, but that was to no avail.

Sorry.  For now this is the best I can do.  I can (hopefully) provide
more detailed information later on.  I'm not meaning to be a pain
about it, it's just a matter of time constraints.
Comment 3 grtllama 1999-11-05 16:28:59 EST
bash# fsck -C -c /dev/hdb6
Parallelizing fsck version 1.17 (26-Oct-1999)
e2fsck 1.17, 26-Oct-1999 for EXT2 FS 0.5b, 95/08/09
Checking for bad blocks (read-only test): done
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/hdb6: ***** FILE SYSTEM WAS MODIFIED *****
/dev/hdb6: 54002/415744 files (5.6% non-contiguous), 900667/1657120
blocks
Warning... fsck.ext2 for device /dev/hdb6 exited with signal 11.

During the boot process (when it hits max mount count) it has the same
failure and drops to a root prompt.  It reports that this particular
partition has reached the maximal mount count on the next boot also,
and the following, and the following...
The segfault only occurs when the filesystem is being scanned.  After
I used the older e2fsprogs (1.15) to scan and mark the filesystem as
being scanned (which had no problems), at boot time the newer
e2fsprogs just gave the usual "clean" messsage.  The only time it
segfaults is when it actually scans the disk or tries to fix errors.

The filesystem mounts just fine when I tell it to mount from the
prompt.  The only oddity is that there are character and block devices
in the lost+found directory of the partition that seem to have been
created with random(?) modes.  They can't be removed because the
system responds with "No such device."  I tried to remove them with
debugfs also, but that was to no avail.

Sorry.  For now this is the best I can do.  I can (hopefully) provide
more detailed information later on.  I'm not meaning to be a pain
about it, it's just a matter of time constraints.
Comment 4 Bill Nottingham 1999-11-10 15:30:59 EST
Ted fixed this in e2fsprogs-1.18. You can get packages from
Raw Hide RSN; in the meantime, you can get a version to test
from from people.redhat.com/notting/ext2/
Comment 5 grtllama 1999-11-10 19:38:59 EST
Seems to have done the trick.  Thanks much.

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