can't handle ext2 resize_inode feature

Bug #59620 reported by Rolf Leggewie on 2006-09-09
This bug affects 1 person
Affects Status Importance Assigned to Milestone
parted (Fedora)
Won't Fix
parted (Ubuntu)
partman-auto (Ubuntu)
Colin Watson
partman-basicfilesystems (Ubuntu)
partman-partitioning (Ubuntu)
Colin Watson

Bug Description

I tried to install Xubuntu dapper the other day from the net installer images over PXE to my Thinkpad X24 with a 40GB HD. It failed. The reason seems to be that for some reason parted does not seem to be able to handle my partition layout. There was an error message to that effect "This ext2 filesystem has a rather strange layout! Parted can't resize this (yet)." After that, it could not go on.

Two things. I cannot see how my partition layout is strange. I also set up and formatted my partitions beforehand. No need for parted in this case and therefore I believe parted bailing out should not bring the installation process to a complete halt. I reproduced this error of parted while being booted via Knoppix so I can attach some output here.

root@3[knoppix]# fdisk -l

Platte /dev/hda: 40.0 GByte, 40007761920 Byte
16 Köpfe, 63 Sektoren/Spuren, 77520 Zylinder
Einheiten = Zylinder von 1008 × 512 = 516096 Bytes

    Gerät boot. Anfang Ende Blöcke Id System
/dev/hda1 1 1000 503968+ 83 Linux
/dev/hda2 7752 8236 244440 83 Linux
/dev/hda4 8722 76070 33943896 5 Erweiterte
/dev/hda5 8722 12597 1953472+ 83 Linux
/dev/hda6 12598 13567 488848+ 83 Linux
/dev/hda7 13568 71697 29297488+ 83 Linux
/dev/hda8 71698 72194 250456+ 82 Linux Swap / Solaris
/dev/hda9 * 72195 76070 1953472+ 83 Linux
root@3[knoppix]# parted /dev/hda
GNU Parted 1.6.9
Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003 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 /UNIONFS/dev/hda
Information: The operating system thinks the geometry on /UNIONFS/dev/hda is
77520/16/63. Therefore, cylinder 1024 ends at 503,999M.
(parted) print
Disk geometry for /UNIONFS/dev/hda: 0.000-38154,375 megabytes
Disk label type: msdos
Minor Start End Type Filesystem Flags
1 0,031 492,187 primary ext2
2 3814,945 4053,656 primary ext2
4 4292,367 37440,703 extended
5 4292,398 6200,085 logical ext2
6 6200,117 6677,507 logical ext2
7 6677,539 35288,367 logical ext2
8 35288,398 35532,984 logical linux-swap
9 35533,015 37440,703 logical ext2 boot
(parted) quit
Information: Don't forget to update /etc/fstab, if necessary.

If I start qtparted on Knoppix to move hda2 a bit up front, I also get this "This ext2 filesystem has a rather strange layout! Parted can't resize this (yet)." error message.

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
I have two Redhat partition, a small boot parition in hdb1 and the normal Linux
system in hdb3 (hda is a DVD player). Backup strategy is to boot to the small
backup parition and use parted to copy the main Linux parition to a separate
disk (hdd). This worked find in Redhat 7.3. It continued to work when I
reinstalled Redhat 9 in the boot partition, but it quite working when I
installed Redhat 9 in the main linux partition. When it is asked to make the
copy, parted complains that....

This ext2 filesystem has a rather strange layout! Parted can't resize this (yet)

A forced e2fsck -f /dev/hdb3 reports no errors, so I'm assuming that this is an
incompatibility between e2fsprogs and parted rather than a corrupted disk
partition. Upgrading to parted 1.6.5 hasn't helped.

Version-Release number of selected component (if applicable):
Parted 1.6.3-11 E2fsprogs 1.32-6

How reproducible:

Steps to Reproduce:
1.Run parted and create a partition slightly larger than the main Redhat linux
2. Ask to copy the main partition to the new one.

Actual Results: This ext2 filesystem has a rather strange layout! Parted can't
resize this (yet)

Expected Results: It should have copied the partition

Additional info:

*** Bug 104836 has been marked as a duplicate of this bug. ***

*** Bug 113074 has been marked as a duplicate of this bug. ***

*** Bug 122803 has been marked as a duplicate of this bug. ***

Unfortunately, Parted's ext2 support is a reimplementation of
e2fsprogs. Ideally, we should switch over to using libe2fs, etc.
(which would require changes to libe2fs). I'm happy to help
volunteers, but I don't have time to do this myself.

I suggest that this bug (#90894) should be marked with
priority "high" rather than "normal" for the following reasons:
Any ext2/ext3 filesystems created during the installation procedure
of recent RedHat/Fedora Linux versions, which use the e2fsprogs for
this task, cannot be resized, moved or copied anymore using parted.
In other words: Parted can basically not be appplied to those
partitions/filesystems anymore at all. Unfortunately, the utilities
fdisk, resize2fs, etc. are not really alternatives (i.e. inconvenient
to use) when you have to resize and move partitions and filesystems
on a densely packed hard drive.


*** Bug 128049 has been marked as a duplicate of this bug. ***

I really dont have anything valuable to contribute to the resolution
of this bug, but I would like to know when a resolution is found.

Thanks all,


*** Bug 137793 has been marked as a duplicate of this bug. ***

Created attachment 106657
Add ext_attr support to parted

I think the problem is that parted does not support the ext_attr feature used
for SELinux. All the other features on my ext3 partitions are recognized by
parted. This patch copies the EXT2_FEATURE_COMPAT_EXT_ATTR feature definition
from e2fsprogs and adds recognition of it. I don't think there is any reason
for special handling of ext_attr.

I think Parted needs special handling of ext_attr.

First, Parted's check won't like it, because it will find unreferenced

Second, if it moves an EA block, all the inodes need to be updated.

It probably isn't very hard to fix these two problems, though.

Additional issues:
When using Anaconda under Fedora Core 3 (and probably other versions),
not only the above mentioned problems happen, as well as the ones
mentioned in Bug 128049, but WINDOWS XP SETUP FROM THE CD STOPS
WORKING. It becomes impossible to run the setup program to
troubleshoot a windows installation that won't boot. If one tries to
boot from the CD, setup will hang after displaying "Setup is
inspecting your computer' hardware configuration".

After formatting the linux partitions with redhat 9 and reinstalling
FC3 without formatting the disks, all the above mentioned problems
went away. (I haven't checked the parted part, but I imagine it is
fixed as well).

For anyone with a dual boot FC3/XP configuration, I strongly advise
that you install the windows XP recovery console to allow for
additional recovery options in case of trouble. (normally you would
run it from the XP CD, which does not work with FC3 formatted drives)

I am working on FC2 (2.6.5-1.358), and using Partition Magic and
DriveImage (referenced as PQ tools below):
PQ tools works fine after initial install of the kernel, but after
installation of certain RPMs, the PQ tools does not recognize the root
partitions filesystem properly (Error #510; The version of the file
system is not supported). I found that these RPMs introduced the
ext_attr to the ext3 filesystem.
Are the ext_attr needed ?
I can remove the ext_attr easily the following way:
#debugfs -w /dev/hdb1
debugfs: feature -ext_attr
debugfs: q

Do I have a risk here ?


Doesn't the extended attributes contain, among other things, ACL:s and
SELINUX security contexts? I would think twice before deciding I to
remove those things.

I'm wondering what the point of a partition editor that can't resize
partitions is.

Im having this problem on redhat-release-3AS-12.3 (Fresh copy straight
from installation medias) and parted-1.6.3-29.3.

While trying to resize single big partition into smaller one, i get
error message saying:

Actual Results: No Implementation: This ext2 filesystem has a rather
strange layout! Parted can't resize this (yet).

Mr Katz - is this bug likely to be fixed ever?

Partition Magic 8 doesn't like dir_index, resize_inode or ext_attr in
FC3 ext3 partitions. They must be removed before it will allow a resize.

You must disable SELINUX first.
edit /etc/selinux/config, and set SELINUX=disabled

Get e2fsprogs-1.37.tar.gz from sourceforge, compile and install it.

then do this (in single user mode!)

umount /dev/xxxx
debugfs -w /dev/xxxx -R "features ^resize_inode ^dir_index ^ext_attr"
e2fsck -y -f /dev/xxxx

Then reboot and run Partition Magic

Just to insist on Additional Comment #16 (2005-02-07):

Is this bug likely to be fixed ever?

And to paraphrase Additional Comment #14 (2004-12-06):

What is the point of a partition editor that can't resize

(In reply to comment #17)
> Partition Magic 8 doesn't like dir_index, resize_inode or ext_attr in
> FC3 ext3 partitions. They must be removed before it will allow a resize.

Will removing ext_attr delete any important information stored in the attributes
(i haven't changed any attributes on the filesystem in question myself)? Is it
possible to enable SELinux again after resizing the partition?

hi! I just want to add that i have that not only on RedHat/Fedora, but up to now
since i try to utilize that tool also on SUSE until now to v1.6.24. seems to be
a general prob. not only of RH/FC --> i also interested if there is ANY chance
that that'll be fixed or do i have to buy probrietary software. A friend said
the russian paragon would do. Some specialist please tell us how the chances
are! I'm really desperate. It's extremely rare that i start to compile some SW
myselfe like i had to do with parted now to see if maybe not my distro screwed
up the tool ... ciao, nico.

This is a horrible horrible bug. Many thanks to Comment #11 From J.P. Gonzalez
for explaining why my Windows XP CD and my Windows XP Pro CD would not install
on my computer. I was ready to throw the whole computer out the window. The
Windows disks would say "Setup is inspecting your hardware configuration" and
then I'd get a blank screen and the computer would never recover. There weren't
many hints in that black screen, but I assumed the hardware was working because
I was able to install Fedora Core. Fortunately a Google search found Mr.
Gonzalez' comment above that Fedora Core 3 had caused the whole problem. When I
installed Red Hat 9 on that drive, removing every remnant of Fedora Core 3, the
Windows XP and Windows XP Pro installations worked fine. It seems this a bug in
Fedora Core 3 colliding with a worse bug in Windows XP. But of course Fedora
will get the blame even though Win XP is equally to blame. Please fix this
problem as soon as possible. It's very horrible.

The horrible bug is a completely different bug. You probably mean #115980 or
#138419 (or at least some the issues reported in the bug since people jumping on
one bug). This was by caused by FC3 using a different disk geometry than
Windows which confuses Windows.

My impression is that the problem has been fixed in FC4 and presumably in FC5.
If you have a corrupted partition, wiping the drive and repartitioning it with
later Fedora versions or Windows should fix the problem.

Rolf Leggewie (r0lf) wrote :

According to this might be fixed in version 1.7 of parted which is close to release it seems.

Rolf Leggewie (r0lf) wrote :

Looks like the FAQ is a bit dated. Version 1.7 is of course already released and in edgy: I will try to update the version on Knoppix and update this bug report on how things went.

Rolf Leggewie (r0lf) wrote :

> I will try to update the version on Knoppix and update this bug report on how
> things went.

Unfortunately, that did not go so well. Despite the claim on the home page of parted, I still get that error for even a simple layout as mine. I used the latest version in Debian testing (unstable has the same version) to update the latest Knoppix Live CD. The update succeeded but the failure remains. The error message changed a little.

  root@2[tmp]# No Implementation: This ext2 file system has a rather strange layout! Parted can't resize this (yet).
  No Implementation: This ext2 file system has a rather strange layout! Parted can't resize this (yet).
  No Implementation: This ext2 file system has a rather strange layout! Parted can't resize this (yet).
  No Implementation: This ext2 file system has a rather strange layout! Parted can't resize this (yet).
  No Implementation: This ext2 file system has a rather strange layout! Parted can't resize this (yet).
  Error: File system has an incompatible feature enabled.

I am not sure what kind of incompatible feature that could be.

Rolf Leggewie (r0lf) wrote :

The guys from parted ask to include the following information in a bug report to them. So I guess it makes sense to post the info here as well.

root@2[tmp]# parted /dev/hda print unit s print unit chs print

Disk /dev/hda: 40,0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 32,3kB 516MB 516MB primary ext2
 2 4000MB 4251MB 250MB primary ext2
 4 4501MB 39,3GB 34,8GB extended
 5 4501MB 6501MB 2000MB logical ext2
 6 6501MB 7002MB 501MB logical ext2
 7 7002MB 37,0GB 30,0GB logical ext2
 8 37,0GB 37,3GB 256MB logical linux-swap
 9 37,3GB 39,3GB 2000MB logical ext2 boot

Disk /dev/hda: 78140159s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 63s 1007999s 1007937s primary ext2
 2 7813008s 8301887s 488880s primary ext2
 4 8790768s 76678559s 67887792s extended
 5 8790831s 12697775s 3906945s logical ext2
 6 12697839s 13675535s 977697s logical ext2
 7 13675599s 72270575s 58594977s logical ext2
 8 72270639s 72771551s 500913s logical linux-swap
 9 72771615s 76678559s 3906945s logical ext2 boot

Disk /dev/hda: 77519,15,62
Sector size (logical/physical): 512B/512B
BIOS cylinder,head,sector geometry: 77520,16,63. Each cylinder is 516kB.
Partition Table: msdos

Number Start End Type File system Flags
 1 0,1,0 999,15,62 primary ext2
 2 7751,0,0 8235,15,62 primary ext2
 4 8721,0,0 76069,15,62 extended
 5 8721,1,0 12596,15,62 logical ext2
 6 12597,1,0 13566,15,62 logical ext2
 7 13567,1,0 71696,15,62 logical ext2
 8 71697,1,0 72193,15,62 logical linux-swap
 9 72194,1,0 76069,15,62 logical ext2 boot

Information: Don't forget to update /etc/fstab, if necessary.

Hi all,

I have not heard anything on this bug in a while and I'm wondering if it still

Can one of the reporters test with rawhide? Or FC5? If the problem has been
resolved, I'd like to close the bug.


Parted 1.7.1 in FC5 or Rawhide does not have any support for ext3 filesystems
using ext_attr feature. It will refuse to copy, resize, or move them with an
"File system has an incompatible feature enabled." error.

Paul Dufresne (paulduf) wrote :

I marked bug 14330 as a duplicate as, after searching on:
I find that the X24 is probably made around 2001, which would make it in the range of HPA or even pre-HPA with hidden by BIOS primary partition.

As a note, you may wish to look that you have latest BIOS at:

Paul Dufresne (paulduf) wrote :

I realize my previous link may be hard to begin finding about what hardware X24 is. So I add these page to the specifications:

Rolf Leggewie (r0lf) wrote :
The HPA was introduced with the R/T/X 40 series of ThinkPads.

The X24 thus would not have HPA (but above page says on the bottom that the X31 also sports this technology). The R40 in the other bug report does.

Rolf Leggewie (r0lf) wrote :

According to, IBM used the so called Predesktop Area for reinstallation purposes before HPA. "As opposed to a Hidden Protected Area Recovery partitions are ordinary partitions, accessible through the partition table. As they are ordinary partitions they are accessible by ordinary partitioning tools."

Such a partition is not on my computer, if it were I would have wiped it. Actually, I swapped the HD when I got the X24 so there really should not be any kind of recovery partitions on this thing.

Rolf Leggewie (r0lf) wrote :

I just rebooted and checked that I have 1.32, the newest version of the BIOS.

Paul Dufresne (paulduf) wrote :

Ok, I think I have found:
"> No Implementation: This ext2 filesystem has a rather strange
>layout! Parted can't resize this (yet).
Parted cannot handle newer ext2/3 filesystems, and this results in the message you see. upstream knows about this, but i didn't see any clear intentions to solve this, so i don't think there will be a quick fix for this.
Sven Luther" from
Also as a workaround: "For ext2/3, resize2fs works fine."

This would make this bug a duplicate of bug #7993.

I which I was able to remove bug #14330 as a duplicate, before marking this one as a duplicate of bug #7983. I'll probably have to ask someone in QA Team for that.

Setting as confirmed, because it seems to be known by Debian and by upstream.

Changed in parted:
status: Unconfirmed → Confirmed
Rolf Leggewie (r0lf) wrote :

Could be a dupe of 7973 (how did I miss that one?).

But the debian stuff is more or less irrelevant because a) that bug is about resizing which I never did and never intended plus b) it is old and talks about parted pre-1.7, it is marked as fixed in 1.7 as suggested in the parted FAQ. I did use a post-1.7 parted but still got this error despite the claims in the FAQ that it should be gone.

In that sense I also feel that the issues in 7973 have been dealt with but this is something else that does look similar.

Paul Dufresne (paulduf) wrote :

Correctings typos, bug #7993, not 7973 or 7983.

>But the debian stuff is more or less irrelevant because a) that bug is >about resizing which I never did and never intended plus
But your bug description was citing:
"This ext2 filesystem has a rather strange layout! Parted can't resize this (yet)."
I insist about can't resize this (yet) part.
Note that you thought it was your partition layout, but it is about the layout of the filesystem itself.

>b) it is old and talks about parted pre-1.7, it is marked as fixed in 1.7
Which version dpkg -l parted gives you.

According to,
Dapper version is gparted (0.1-0ubuntu9)
which seems to indicate that it would be based on parted 1.0 !?

Are you able to tell if you are using ext2 or ext3 filesystems?
I guess cat /etc/fstab is what I would want to see.

Changed in parted:
assignee: nobody → dufresnep
status: Confirmed → Needs Info
Paul Dufresne (paulduf) wrote :

Oh, yeah, bad package.
Dapper version of parted was parted (

And you did report quite extensively your partition. But I had the feeling parted could show ext3 as ext2, but it does indeed show ext3 for me.

Still, if you could really make sure what parted --version gives.
Just to make sure.

Rolf Leggewie (r0lf) wrote :

Paul, sorry to say, but you are doing an abyssmal job here.

You mark as dupe for the wrong bug second time around. You fail to read the stuff that I already posted. All the information you needed was AFAIK in the original report.

Facts you you choose to continue to ignore

1) I never asked for resizing.
2) In fact I never asked for parted to come into the picture when installing. I already had all partitions set up. parted bringing the ubuntu install to a halt is IMNSHO another, serious flaw in the ubuntu installation process. Unfortunately, I do not know what package that should be reported against. There was no job for parted to be done, really.
3) I tried version 1.7 of parted via an updated Knoppix Live CD. The other reports were 1.6 and upstream claims all these have been dealt with in 1.7. I went to the trouble of confirming this is not true only to have you mark my report as dupe falsely twice.
4) You keep asking already answered and irrelevant question (like "give me the output of dpkg -l". Like I said, I stumbled across this when installing ubuntu, I confirmed this with Knoppix. What on earth does my current ubuntu installation have to do with this???)

Do as you please. I'm outta here.

Colin Watson (cjwatson) wrote :

Paul, please don't mark bugs as duplicates that are not entirely understood. I've read this bug over twice and I still don't entirely understand what's going on. If you have a better understanding than me, by all means share it, but until then remember that this is not a competition to mark the most bugs as duplicates - the objective is to make sure that as many bugs as possible get fixed, and incorrectly marking bugs as duplicates is a problem for meeting that objective. I would greatly appreciate it if you would confine your efforts to suggesting possible duplicate bugs rather than actually marking them as such. Now you appear to have alienated a bug reporter who might have been able to give more useful information once we figured out what information to ask for!

The current version of parted in Edgy has the "rather strange layout" message commented out, so it's not possible to get this error with the version of parted in Edgy. However, the same problem will cause a different error, so I'd still like to investigate.

Colin Watson (cjwatson) wrote :

The reason that resizing is showing up is probably the automatic partitioner checking to see if it's possible to do automatic resizing (not actually doing the resize). A full copy of /var/log/syslog and /var/log/partman might be useful. I'll create a partman-auto task on this bug because this shouldn't cause partman to fall over and die.

Colin Watson (cjwatson) wrote :

Unassigning Paul from this bug, unless he actually plans to write the code necessary to fix this.

Changed in parted:
assignee: dufresnep → nobody
Colin Watson (cjwatson) wrote :

Oh, hmm, it may be that parted throws this exception when you ask it to simply check the partition, not even resize it. That would be unfortunate.

Colin Watson (cjwatson) wrote :

Rolf: it is possible that this has been partially fixed in 1.7.1 (the version released with Edgy). One of the sets of changes was this:

        * fs/ext2/ext2.c (ext2_open): removed call to ext2_determine_itoffset;
        also moving it from this file to ext2_resize.c.
        * fs/ext2/ext2_resize.c (ext2_resize): added call to
        ext2_determine_itoffset and show a warning if not successful.

I think that's the "rather strange layout" warning. This change will arrange for that code only to be run when you actually try to resize a partition, not merely when libparted opens the partition, which should make us a lot less likely to run into this in the installer.

Would it be possible for me to get the output of:

  for x in 1 2 5 6 7 9; do sudo tune2fs -l /dev/hda$x; done

... run from e.g. an Edgy live CD (or Knoppix would probably do as well)? That should tell me what features are enabled on each filesystem, and thus which ones libparted is unable to handle.

Rolf Leggewie (r0lf) wrote :

First of all, let me say that I do appreciate the great effort that Paul was making. Quite obviously he was very enthusiastic about his task which is testified to by the amount of related information he dug up. I hope he continues with his passion to make ubuntu and FOSS in general a better and more bug-free place.

Back to the task and thanks for taking over, Collin. I am now booted into Knoppix. I believe it is the latest version.

knoppix@1[knoppix]$ cat /etc/knoppix-version
5.0.1 2006-06-01

Knoppix still has version 1.6.9 of parted. Thus I again updated this via "wget;wget;dpkg -r parted-bf;dpkg -i libparted*;dpkg -i parted_1.7.1-2.1_i386.deb" to version 1.7.1. Looking at the developper information for debian parted, I believe this is the same version I had used when writing this report.

OK, here the dissection. While I still have 1.6.9, I get

root@1[knoppix]# parted /dev/hda check 1
No Implementation: This ext2 filesystem has a rather strange layout! Parted
can't resize this (yet).
Information: Don't forget to update /etc/fstab, if necessary.

for partitions 1,2,3,5,6 and 7. Partition 9 gives

root@1[knoppix]# parted /dev/hda check 9
Error: Filesystem has incompatible feature enabled
Information: Don't forget to update /etc/fstab, if necessary.

After the upgrade to 1.7.1 the errors for partitions 1 to 8 are gone, the parted check passes. Partition 9 still has the same error. I will also attach the information from tune2fs that you requested. It seems I added hda3 partition in the meantime, so I include that one as well. hda2 now runs from cylinder 1001 to 1485 and hda3 from 1486 to 8721. Furthermore, I have cleared all bootable flags. The rest of the partition are as per the original report.

Rolf Leggewie (r0lf) wrote :

hda9 has the following features which are not present on the other partitioins: resize_inode dir_index. I admit to not knowing what they do and how they got there ;-)

Paul Dufresne (paulduf) wrote :

>First of all, let me say that I do appreciate the great effort that Paul >was making. ... I hope he continues with his passion to make ubuntu >and FOSS in general a better and more bug-free place.
Thanks, it does makes me feels better to read this.
Don't worry, I'll continue, trying to avoid previous mistakes.
I would have wished that my mistakes would not have to be fixed by
Colin, AGAIN. I hope my future work will be good enough to compensate the overwork I have put on his shoulders by mistakes I have done lately while l am learning to become a better bug triager.

I'd like to bring everyone on this bug report up to speed on where parted
currently sits with regard to the original reported issue.

Parted is currently at 1.8.0 which is mostly a bug fix release with some updates
to support new disk label types and partition IDs on new hardware (e.g., new
Macs). We [the parted team] are working on parted 2.0 while continuing the 1.x
branch for bug fixes.

The problem originally reported in this report is definitely a bug, but not a
simple fix in libparted. Currently, all of the filesystem code in libparted was
written from scratch. It does not make use of any filesystem libraries
available (e2fsprogs, and so on). This puts libparted at a severe disadvantage
when the filesystems introduce new features. Our decision was to rewrite the
filesystem layer to use those libraries directly rather than add support as
needed to parted. We can't guarantee that the latter method will work for
future filesystem versions, but we can guarantee a better level of compatibility
by using the libraries written by the same people that write the filesystems.

Our plan for parted 2.0 will add the support necessary to fix the problem
reported above.

Currently the _only_ tool that can resize ext3 filesystems is resize2fs
available in e2fsprogs. While annoying, you can use resize2fs to resize the
filesystem and then use fdisk or parted to resize the partition boundary to
match the new filesystem size. With parted 2.0, we'll be able to do this in one

Rolf Leggewie (r0lf) on 2006-12-06
Changed in parted:
status: Needs Info → Unconfirmed
Colin Watson (cjwatson) wrote :

I'm going to reject the Debian task on this bug; while the bug undoubtedly exists in Debian too, it's not very useful to have this task here. If we can come up with a patch set it can more easily be forwarded to Debian in other ways.

Colin Watson (cjwatson) wrote :

The main "offending" feature is resize_inode. I spent a while the other day trying to beat support for this feature into libparted, but it's not easy work. I may get there, or I may not ...

One thought I had was that perhaps partman could detect the presence of unsupported features and degrade to using resize2fs instead of libparted. This doesn't offer a progress bar in a way that we can sanely handle in partman, which isn't great, but it would be better than not being able to resize at all.

Changed in parted:
importance: Undecided → Medium
status: Unconfirmed → Confirmed
Colin Watson (cjwatson) wrote :

Also, while dir_index doesn't cause libparted to fall over completely like resize_inode, it's not supported by the resize code. We probably need to make libparted at least tolerate resize_inode outside the resize code even if it can't deal with resizing it.

Changed in parted:
importance: Medium → High
Nick Moffitt (nick-moffitt) wrote :

I attempted to do a separate resize2fs/e2fsck, but parted refuses to move or resize a partition that has this flag in the fs. So falling back to resize2fs probably isn't likely to help.

^rooker (rooker) wrote :

I ran into the same problem when trying to install Edgy together on my Feisty installation. Resizing the ext3 partition (created by Feisty) during Edgy install failed with some non-verbose error like "unable to resize partition".
I've opened another terminal (Alt+F2) and tried parted. It gave me the following error message: "Error: File system has an incompatible feature enabled".

According to "parted --version", Edgy's using v1.7.1.

Colin Watson (cjwatson) wrote :

I've worked around this for Feisty as follows:

partman-partitioning (47ubuntu2) feisty; urgency=low

  * Use tune2fs/resize2fs to handle ext2/ext3 resizing, since libparted
    can't deal with the resize_inode feature (LP: #59620).

 -- Colin Watson <email address hidden> Mon, 19 Mar 2007 11:41:11 +0000

I understand that eventually the amount of filesystem code duplication in libparted will be decreased, making it easier to fix this bug properly there.

Changed in partman-partitioning:
assignee: nobody → kamion
importance: Undecided → High
status: Unconfirmed → Fix Released
Colin Watson (cjwatson) wrote :

partman-auto (62ubuntu7) feisty; urgency=low

  * Make use of changes in partman-partitioning 47ubuntu2 to use
    tune2fs/resize2fs to handle ext2/ext3 resizing (LP: #59620).

 -- Colin Watson <email address hidden> Mon, 19 Mar 2007 12:04:46 +0000

Changed in partman-auto:
assignee: nobody → kamion
status: Unconfirmed → Fix Released
Changed in parted:
importance: High → Medium
Rolf Leggewie (r0lf) wrote :

I am happy to say that this report I made just saved my a**. On the weekend I somehow managed to completely kill my partition table (still unsure as to what did it). Thanks to the information I was able to restore the drive quickly.

Thanks, Launchpad!

Rolf Leggewie (r0lf) wrote :

"Thanks to the information about my HD layout that I recorded in this report I was able to restore it quickly" should be more understandable.

Closing as UPSTREAM. We know about it upstream and are working on it. No point
in tracking it as a RHEL or Fedora bug.

Please can you add the upstream bugzilla number so that commenters/reporters for
this bug can track it, as well as any future Fedora users that encounter the bug
before it is fixed.

Rolf Leggewie (r0lf) on 2007-09-25
Changed in parted:
status: New → Invalid
Colin Watson (cjwatson) on 2008-05-27
Changed in parted:
status: Invalid → Unknown
status: New → Confirmed
Changed in parted:
status: Unknown → Invalid
James Dupin (james.dupin) wrote :

The thing is I believe resize_inode is out of the way as I already "disabled" it with tune2fs.

The only 2 attributes left are ext_attr and sparse_super, both of them I cannot remove with tune2fs.
dumpe2fs /dev/sda4 | grep feature
dumpe2fs 1.40.8 (13-Mar-2008)
Filesystem features: ext_attr sparse_super

The problem is the same for the resize options of parted but this I simply overtake the problem by resizing the FS and then deleting/recreating the partition.

There is also the problem of not being able to set the resize_inode feature again without formatting the partition (or at least I haven't found how)

(using hardy btw)

Colin Watson (cjwatson) wrote :

Looks like partman-basicfilesystems needs to work around this too (for ext2 with unusual features); Carl Karsten is going to attach some logs. (This is quite rare FWIW.)

Changed in partman-basicfilesystems:
importance: Undecided → High
status: New → Triaged
Carl Karsten (carlfk) wrote :
Carl Karsten (carlfk) wrote :
Carl Karsten (carlfk) wrote :

/tmp/misc # tune2fs -l /dev/sdc1
tune2fs 1.41.0 (10-Jul-2008)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: c8d7d2a8-ce89-4fdb-b000-225bb3baeaa2
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 655776
Block count: 2622603
Reserved block count: 131130
Free blocks: 2141345
Free inodes: 655756
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 640
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8096
Inode blocks per group: 506
Filesystem created: Thu Oct 2 14:54:21 2008
Last mount time: Thu Oct 2 14:56:12 2008
Last write time: Thu Oct 2 18:24:49 2008
Mount count: 1
Maximum mount count: 36
Last checked: Thu Oct 2 14:54:21 2008
Check interval: 15552000 (6 months)
Next check after: Tue Mar 31 14:54:21 2009
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Default directory hash: tea
Directory Hash Seed: 51325a80-f2a4-4b86-b12d-e7895bad659c

Changed in parted:
status: Invalid → Fix Released
epictete (p-latreyte) wrote :

I have exactly the same problem as in bug #37137 which is reported as a duplicate of this bug, with the same messages "file system has an incompatible feature enabled" and then "Ext2 partition has unrecoverable system error" using the installer of both Ubuntu and Kubuntu 9.04 JAUNTY.

The ext2 partition is my boot partition. If I ignore the messages and go on for the installation, it seems that everything works well. But for a newcomer to linux this may be dissuasive and crippling before he could have a chance to see anything of Linux and Ubuntu!

Phillip Susi (psusi) wrote :

Why are some of the tasks for this fixed, and some are still open? It seems that this issue was fixed in Ubuntu, wasn't it? The ability for parted to resize is depreciated and going to be removed so the installer should not be using it.

Phillip Susi (psusi) on 2011-12-15
affects: parted → ubuntu
no longer affects: ubuntu
Changed in parted (Ubuntu):
status: Confirmed → Won't Fix
Changed in partman-basicfilesystems (Ubuntu):
status: Triaged → Fix Released
Changed in parted (Fedora):
importance: Unknown → High
status: Fix Released → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.