Re: 1.6.4, 1.6.5: Filesystem has incompatible feature enabled

[Greg Roelofs]

Like Shaul Karl and Chris M, I too am having trouble doing much of anything
with ext3 partitions.  I'm using parted 1.6.5, booting off the floppy images
(kernel 2.4.18-xfs), and I simply wanted to move or copy the damn thing:

    Disk geometry for /dev/hda: 0.000-4126.992 megabytes
    Disk label type: msdos
    Minor    Start       End     Type      Filesystem  Flags
    1          0.031   1638.984  primary   fat32       boot
    2       1638.984   4016.250  extended              
    8       1639.046   2347.734  logical   ext3        
    5       2347.765   3049.101  logical   ext3        
    6       3049.132   3979.335  logical   ext2        
    7       3979.367   4016.250  logical   linux-swap  
    4       4016.250   4119.609  primary               

    (parted) rm 8               [it was empty]
    (parted) move 5 1638.984
    Error: Filesystem has incompatible feature enabled

    (parted) rescue 1639.046 2347.734
    (parted) cp 5 8
    Error: Filesystem has incompatible feature enabled

Both 5 and 8 were created with "mke2fs -c -j /dev/hda<#>" under Slackware
9.0.  I ended up doing a tar-copy from 5 to 8 (which worked fine), but I
decided to check the bug archives before nuking 5 and attempting a resize
on 8, and I'm glad I did.

I thought the internal journal might be the problem, but it appears from
the other reports that I'm the only one using one of those, so that's not
it:

        Shaul:  dir_index filetype sparse_super
        Chris:  dir_index filetype needs_recovery sparse_super
        me:     has_journal dir_index filetype sparse_super

Why is parted not able to specify the incompatible feature?  Does it
know but refuse to tell, or is it just getting a generic errno or some-
thing from a system call?  "dir_index", "filetype", and "sparse_super"
all seem relatively innocuous, and certainly in the case of moving or
copying a partition, I'd naively expect that parted could figure out how
to create an identically sized target partition and then do a byte-for-
byte copy into it.  Is there something really subtle that I'm missing
here?  I understand that resizing is more complex, but copying doesn't
seem like a big deal--even dd can do that (according to something I
read, anyway).

Of course, the whole point of moving/copying minor 5 into space formerly
occupied by minor 1 was to prepare to resize it (ideally keeping the "5"
label), so it looks like I'm out of luck anyway... ;-/

Regards,
-- 
Greg Roelofs            address@hidden             http://pobox.com/~newt/
Newtware, PNG Group, Info-ZIP, AlphaWorld Map, Philips Semiconductors, ...