Bug 72517 - EXT3 partition failure after crash
EXT3 partition failure after crash
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: mount (Show other bugs)
7.3
i686 Linux
high Severity high
: ---
: ---
Assigned To: Elliot Lee
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-08-24 16:56 EDT by Ike Norton
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: 2002-08-24 16:56:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Ike Norton 2002-08-24 16:56:53 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)

Description of problem:
Cannot mount EXT3 partition and get the following error:
[root@vloc1 root]# mount /dev/hdi1 -t ext3 /data5
mount: wrong fs type, bad option, bad superblock on /dev/hdi1,
       or too many mounted file systems

I can mount it as EXT2.

Output from PARTED:
[root@vloc1 root]# parted /dev/hdi 
GNU Parted 1.4.16
Copyright (C) 1998, 1999, 2000, 2001 Free Software Foundation, Inc.
This program is free software, covered by the GNU General Public License.

This program is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.  See the GNU General Public License for more details.

Using /dev/hdi
Warning: The operating system thinks the geometry on /dev/hdi is 19929/255/63.
Therefore, cylinder 1024 ends at 8032.499M.  You should check that this matches
the BIOS geometry before using this program.
(parted) p
Disk geometry for /dev/hdi: 0.000-156334.500 megabytes
Disk label type: msdos
Minor    Start       End     Type      Filesystem  Flags
1          0.031 156327.824  primary   ext3        
(parted) 


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


How reproducible:
Didn't try

Steps to Reproduce:
1.Power failure
2.Normal mount process
3.
	

Additional info:
Comment 1 Elliot Lee 2002-08-26 11:02:01 EDT
Just doing a dirty reboot doesn't cause problems for me nor anyone else around here. I 
would guess that the partition isn't actually ext3 (parted notwithstanding) since you can 
mount it as ext2 just fine.
Comment 2 Ike Norton 2002-08-26 16:05:31 EDT
This is the second time it has happened to me.  I did not do a reboot, the 
system was crashed by power loss and the journal would have had to be invoked.  
This definitely was an EXT3 partition.  Another EXT3 disk on the same system 
came up fine. This one... no.

I will attempt to find a way to duplicate this so that you can do it there.

Ike
Comment 3 Ike Norton 2002-08-27 15:26:12 EDT
FIXED!
I found a way to fix the file system, from a note by Theodore Tso, with subject:
e2fsck: bad magic number in super-block ... 
URL:https://listman.redhat.com/pipermail/ext3-users/2002-January/002566.html

I used this procedure based on his recommendations:
(he recommends backups, but I already have those on other systems, rsync'd).

mke2fs -S /dev/sdb6  (my broken ext3 file system)
e2fsck -f /dev/sdb6
I then restored ext3, with: 
tune2fs -j /dev/sdb6

and am now able to remount that fs.  I have not yet verified the data, but 
things look very good so far.

Ike

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