[Trilug-ontopic] GParted choking on my disk: alternatives?

Tom Roche Tom_Roche at pobox.com
Mon Aug 8 17:37:48 EDT 2011

summary: Is there a tool or tools folks would recommend for linux
(specifically ext3) partition management *other than* GParted? which is
failing on my disk.


While I'm now *definitely* planning to using LVM on my laptop (gotta
admit, I had thought it was more of a server thing), at the moment I'm
trying to just fix the disks (mostly ext3) partitions, as detailed @

> The swap partition is too small (hibernation often fails), and the
> root partition could use more free space, so I attempted to perform
> the following actions in a GParted 0.9.0-7 (latest stable) liveCD:

First step:

> 1 Move /dev/sda6 [home] to the right and shrink it.
>   This should produce unallocated space between /dev/sda5 and /dev/sda6.

This failed, as previously described, with a superblock problem:

> [running GParted:$] e2fsck -f -y -v /dev/sda6
> The filesystem size (according to the superblock) is 54871597 blocks
> The physical size of the device is 54871342 blocks
> Either the superblock or the partition table is likely to be corrupt!
> Abort? yes

The fix for the superblock error appears to be, use a backup superblock.
I did the following in a Terminal run from the GParted LiveCD:

user at debian:~$ sudo e2fsck -b 32768 -fvy /dev/sda6

(see `info e2fsck`) and life was good: lots "Free blocks count wrong"
but no bad blocks. So I retried step=1 again in GParted ... and got a
different failure. Save Details saved (and I slightly annotated)

> GParted 0.9.0
> Libparted 2.3

> [action:] Move /dev/sda6 to the right and shrink it from 209.32 GiB to 209.32 GiB  00:08:25    ( ERROR )

> [steps:]

> [1] calibrate /dev/sda6  00:00:00    ( SUCCESS )

> path: /dev/sda6
> start: 36837892
> end: 475808627
> size: 438970736 (209.32 GiB)

> [2] check file system on /dev/sda6 for errors and (if possible) fix them  00:07:51    ( SUCCESS )

This had failed before, so presumably the previous run of `e2fsck -b`
silently fixed the primary superblock.

> [3] shrink file system  00:00:34    ( SUCCESS )

> resize2fs /dev/sda6 219484343K
> Resizing the filesystem on /dev/sda6 to 54871085 (4k) blocks.
> The filesystem on /dev/sda6 is now 54871085 blocks long.
> resize2fs 1.42-WIP (02-Jul-2011)

but then

> [4] shrink partition from 209.32 GiB to 209.32 GiB  00:00:00    ( ERROR )

> old start: 36837892
> old end: 475808627
> old size: 438970736 (209.32 GiB)

Which strikes me as just odd: isn't "shrinking" from one size to
THE SAME @#$%^&! SIZE a no-op? How could that possibly fail? But it did!
apparently unmounting /dev/sda6, and hosing all subsequent steps in that

So I'm wondering, is there something else I should use besides GParted
to move the free space from following the partition/filesystem to
preceding it? I've been happily using GParted for years (on and off :-)
but, on this disk, it seems to be hosed. Your suggestions are

The remaining actions I want to do are

> 2 Move /dev/sda5 [swap] to the right and grow it.
>   This should consume most of the unallocated space, placing the
>   remainder at the beginning of /dev/sda5, which is at the beginning of /dev/sda2.

> 3 Move /dev/sda2 [extended] to the right and shrink it.
>   This should produce unallocated space between /dev/sda1 and /dev/sda2.

> 4 Grow /dev/sda1 [root].
>   This should consume the unallocated space between /dev/sda1 and /dev/sda2.

and I plan to try them again in GParted ... provided I can clear the
hurdle of step=1.

TIA, Tom Roche <Tom_Roche at pobox.com>

More information about the Trilug-ontopic mailing list