From Bugzilla Helper: User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.6-3.1 i686) Description of problem: during install several ext2 partitions were tagged as to be migrated. however, upon subsequent boot, these were claimed to have bad superblocks. I changed their ext3 tag to ext2 in the /etc/fstab file and could then mount these old partitions with no problem. How reproducible: Always Steps to Reproduce: 1.tagged old ext2 as ext3 for migration 2.rebooted 3.partition failed to mount Additional info:
please attach the "tune2fs -l /dev/XXX" output for each of the filesystems.
The two filesystems that had the problems were hda4 and hda5: # tune2fs -l /dev/hda4 tune2fs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09 Filesystem volume name: <none> Last mounted on: <not available> Filesystem UUID: f27b268c-6b5b-11d5-8ec5-b51558c5d935 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: filetype sparse_super Filesystem state: not clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 3204992 Block count: 6397650 Reserved block count: 319882 Free blocks: 937310 Free inodes: 2916379 First block: 0 Block size: 4096 Fragment size: 4096 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 16352 Inode blocks per group: 511 Last mount time: Mon Aug 6 11:45:21 2001 Last write time: Mon Aug 6 17:19:21 2001 Mount count: 4 Maximum mount count: 20 Last checked: Sat Aug 4 16:07:06 2001 Check interval: 15552000 (6 months) Next check after: Thu Jan 31 15:07:06 2002 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 # tune2fs -l /dev/hda5 tune2fs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09 Filesystem volume name: <none> Last mounted on: <not available> Filesystem UUID: e95eed40-6b5b-11d5-8fbf-d4fd2e421e97 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: filetype sparse_super Filesystem state: not clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 193152 Block count: 385552 Reserved block count: 19277 Free blocks: 23904 Free inodes: 112050 First block: 0 Block size: 4096 Fragment size: 4096 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 16096 Inode blocks per group: 503 Last mount time: Mon Aug 6 11:45:21 2001 Last write time: Mon Aug 6 11:45:21 2001 Mount count: 8 Maximum mount count: 20 Last checked: Sat Aug 4 16:07:35 2001 Check interval: 15552000 (6 months) Next check after: Thu Jan 31 15:07:35 2002 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 is the output as I am running now under 'roswell'. I have been booted once back to rh62, which also employs these two partitions, but they should not have modified the data.
*** Bug 50979 has been marked as a duplicate of this bug. ***
We (Red Hat) really need to fix this defect before next release.
We have added a check to make sure a journal was added to each tagged filesystem before proceeding. We check for a error return code from tune2fs, so apparently it dies sometimes w/o returning an error. Our test should catch these situations. We have not seen this type of failure in our testing.