Re: EXT2 corruption -- After running 2.5.46, my root partition cannot be mounted by older kernels

[Miles Lane <miles.lane@attbi.com>]

Ted Tso wrote:

> Send the output of dumpe2fs -h to be sure, but it's almost certainly
> one of two things: 
> 
> 1) You didn't unmount the filesystem cleanly when you previously
> booted a kernel with ext3 compiled in , and your 2.4 kernel has ext3
> as a module, but you either don't have an initrd or the initrd doesn't
> have the ext3 module in it.

I do also have initrd support compiled into the kernel:

# Block devices
#
...
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y

I added this because I have been basing my latest kernel configs
off if the default Redhat 8.0 configuration.  Hmm.  

> 2) You managed to enable a new ext3 feature, such as htree, or
> extended attributes which was supported in the newer kernel, 
> but not in the 2.4 kernel.

I have, indeed, compiled my 2.5.46 kernel with ACL support.
Mea culpa for not studying the effect on the filesystem 
before testing this new code.  I usually try to do compile 
testing on a lot of options, whether or not I exercize the 
code.  I didn't realise that ACL support would modify the 
filesystem whether or not I applied ACLs to a particular file.
Or is that what has happened?

# File systems
#
CONFIG_QUOTA=y
CONFIG_QUOTACTL=y
CONFIG_EXT3_FS=m
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_JBD=y
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y

>> dumpe2fs -h /dev/hda12
dumpe2fs 1.27 (8-Mar-2002)
Filesystem volume name:   /
Last mounted on:          <not available>
Filesystem UUID:          0a3ccf38-e09c-4ce8-af56-4c086b7adce4
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal filetype needs_recovery sparse_super
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1982464
Block count:              3962022
Reserved block count:     198101
Free blocks:              2862850
Free inodes:              1800406
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16384
Inode blocks per group:   512
Last mount time:          Wed Nov  6 18:09:02 2002
Last write time:          Wed Nov  6 18:09:02 2002
Mount count:              6
Maximum mount count:      23
Last checked:             Wed Nov  6 16:29:29 2002
Check interval:           15552000 (6 months)
Next check after:         Mon May  5 17:29:29 2003
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal UUID:             <none>
Journal inode:            54
Journal device:           0x0000
First orphan inode:       345436

> (1) tends to be the most likely cause, given the confused users who
> ask these sorts of questions on th ext3-users mailing list.  As a
> result, I've developed a very strong distaste for initrd, and
> generally strongly encourage people to compile ext3 and whatever
> device drivers you require into the kernel, and to not try to use
> initrd.  initrd turns out to be a confusing stumbling block for far
> too many users.

I'm not sure how best to proceed.

Thanks very much for your help!

	Miles