1 Topic by TomRoche (edited by TomRoche 2011-08-08 15:54:54)

  • TomRoche
  • New member
  • Offline
  • Registered: 2010-02-28
  • Posts: 9

Topic: gparted-live-0.9.0-7: ext3 partition corrupted attempting move/shrink

summary: I've got a box running ubuntu lucid (otherwise up-to-date) with a single internal HD with all (non-swap) filesystems on ext3. I'm attempting to grow partitions at the beginning and middle of the HD, hence first want to shrink the partition at the end of the HD and move its filesystem to the right. GParted shrank the filesystem, but not its superblock. How to fix?

details:

$ lsb_release -ds
> Ubuntu 10.04.3 LTS
$ uname -rv
> 2.6.32-33-generic #71-Ubuntu SMP Wed Jul 20 17:27:30 UTC 2011

This laptop (running ubuntu lucid) has a single internal HD:

$ sudo fdisk -l -u
> Disk /dev/sda: 250.1 GB, 250059350016 bytes
> 255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x0009c48f

Its partitions are
/dev/sda1  /
/dev/sda5  swap
/dev/sda6  /home

>    Device Boot      Start         End      Blocks   Id  System
> /dev/sda1   *           1    29296875    14648437+  83  Linux
> /dev/sda2        29296876   488397167   229550146    5  Extended
> /dev/sda5        29296877    36837890     3770507   82  Linux swap / Solaris
> /dev/sda6        36837892   475808627   219485368   83  Linux
$ sudo parted /dev/sda unit s print
> Model: ATA ST9250410AS (scsi)
> Disk /dev/sda: 488397168s
> Sector size (logical/physical): 512B/512B
> Partition Table: msdos
>
> Number  Start      End         Size        Type      File system     Flags
>  1      1s         29296875s   29296875s   primary   ext3            boot
>  2      29296876s  488397167s  459100292s  extended
>  5      29296877s  36837890s   7541014s    logical   linux-swap(v1)
>  6      36837892s  475808627s  438970736s  logical   ext3

The swap partition (/dev/sda5) is too small, and the root partition (/dev/sda1) could also use more free space, so my plan is to perform the following actions in GParted:

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

  2. Move /dev/sda5 [swap] to the right and grow it. This should consume some 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.

Unfortunately, in my first attempt to do step=1, GParted abended with an error after shrinking partition=/dev/sda6 and attempting to move its filesystem. I did not record the error (since I did not know how to Save Details to somewhere retrievable--how could anything go wrong ?-), but noted it was from e2fsck. I again restarted the box from its HD, and searched/found this howto for Save Details, then retried step=1 again with GParted, and saved this error:

> GParted 0.9.0
> Libparted 2.3

> Move /dev/sda6 to the right and shrink it from 209.32 GiB to 209.32 GiB  00:00:01    ( ERROR )

> calibrate /dev/sda6  00:00:00    ( SUCCESS )

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

> check file system on /dev/sda6 for errors and (if possible) fix them  00:00:01    ( ERROR )

> 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

> e2fsck 1.42-WIP (02-Jul-2011)

The physical size=54871342 looks like what I wanted (in blocks), so I'm guessing GParted correctly resized the partition, but then was unable to write the superblock. The bad news is, neither can I. The good news is, the filesystem appears to be otherwise OK, except that when I reboot to lucid (i.e., on the internal HD), before login I get

Errors were found while checking the disk drive for /home
F to attempt to fix the errors, I to ignore, S to skip mounting or M for manual recovery

But I can then login, and everything appears to work (particularly, /home automounts). While mounted in lucid, for the helluvit, I tried

me@it:~$ sudo resize2fs -f /dev/sda6
> resize2fs 1.41.11 (14-Mar-2010)
> Filesystem at /dev/sda6 is mounted on /home; on-line resizing required
> On-line shrinking from 54871597 to 54871342 not supported.

So I rebooted the GParted liveCD and ran

user@debian:~$ sudo resize2fs -f /dev/sda6
> resize2fs 1.42-WIP (02-Jul-2011)
> Resizing the filesystem on /dev/sda6 to 54871342 (4k) blocks.
> resize2fs: Attempt to read block from filesystem resulted in short read while trying to resize /dev/sda6
> Please run 'e2fsck -fy /dev/sda6' to fix the filesystem
> after the aborted resize operation.
user@debian:~$ sudo e2fsck -fy /dev/sda6
> e2fsck 1.42-WIP (02-Jul-2011)
> 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

So `resize2fs` and `e2fsck` are not playing well together. I'm wondering:

  1. How to fix /dev/sda6? Particularly, its superblock.

  2. How to move the filesystem on /dev/sda6 to the right, so as to proceed with my plan (above)? Though I'm hoping GParted will do this, if I can fix the superblock on /dev/sda6 ...

2 Reply by gedakc

  • gedakc
  • Developer
  • Offline
  • Registered: 2007-11-30
  • Posts: 4,593

Re: gparted-live-0.9.0-7: ext3 partition corrupted attempting move/shrink

Error messages such as "Attempt to read block from filesystem resulted in short read while trying to resize /dev/sda6" can occur if the drive is beginning to fail.  I suspect that this is the problem that was originally encountered by GParted when it tried to resize the file system with e2fsresize.

Please note that I suspect that the hard drive might be failing (or have a lose connection).  As such if you have not already done so then I recommend that you back up all of your data.

To try to fix the problem I would suggest increasing the size of the sda6 partition back to it's original size.  You could use the command line fdisk to perform such an operation since fdisk does not write it's changes to the partition table until you instruct it to do so.

Next run "e2fsck -f -y -v /dev/sda6" on the file system to try to repair any problems.

3 Reply by TomRoche

  • TomRoche
  • New member
  • Offline
  • Registered: 2010-02-28
  • Posts: 9

Re: gparted-live-0.9.0-7: ext3 partition corrupted attempting move/shrink

Thanks for your reply, but I could use a bit more assistance with 

fdisk

:

TomRoche wrote:
user@debian:~$ sudo resize2fs -f /dev/sda6
> resize2fs 1.42-WIP (02-Jul-2011)
> Resizing the filesystem on /dev/sda6 to 54871342 (4k) blocks.
> resize2fs: Attempt to read block from filesystem resulted in short read while trying to resize /dev/sda6
> Please run 'e2fsck -fy /dev/sda6' to fix the filesystem
> after the aborted resize operation.
user@debian:~$ sudo e2fsck -fy /dev/sda6
> e2fsck 1.42-WIP (02-Jul-2011)
> 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
gedakc wrote:

Error messages such as "Attempt to read block from filesystem resulted in short read while trying to resize /dev/sda6" can occur if the drive is beginning to fail.

That's possible, but note that I have had no problems with this HD other than failure to hibernate after extended use (e.g., if I've watched a flash video or otherwise made the system use swap).

gedakc wrote:

if you have not already done so then I recommend that you back up all of your data.

I do have backups, and in fact backed up before starting this (both with duplicity and with clonezilla),

gedakc wrote:

To try to fix the problem I would suggest increasing the size of the sda6 partition back to it's original size.  You could use the command line fdisk

What's the syntax to use to increase the size of a partition? I've looked at 

info fdisk

and 

info cfdisk

and am not seeing that.

4 Reply by TomRoche

  • TomRoche
  • New member
  • Offline
  • Registered: 2010-02-28
  • Posts: 9

Re: gparted-live-0.9.0-7: ext3 partition corrupted attempting move/shrink

TomRoche wrote:

I'm wondering:

  1. How to fix /dev/sda6? Particularly, its superblock.

  2. How to move the filesystem on /dev/sda6 to the right, so as to proceed with my plan (above)? Though I'm hoping GParted will do this, if I can fix the superblock on /dev/sda6 ...

gedakc wrote:

You could use the command line fdisk to [restore the original size of /dev/sda6]. Next run "e2fsck -f -y -v /dev/sda6" on the file system to try to repair any problems.

New results:

  1. The superblock on /dev/sda6 didn't need fixed, I needed only to use a backup superblock.

  2. GParted is failing to "shrink partition from 209.32 GiB to 209.32 GiB"

What I found:

I stumbled upon the backup superblocks doing

$ sudo dumpe2fs /dev/sda6 | fgrep -e 'Block size'
> dumpe2fs 1.41.11 (14-Mar-2010)
> Block size:               4096
$ sudo dumpe2fs /dev/sda6 | fgrep -ie 'superblock' | wc -l
> dumpe2fs 1.41.11 (14-Mar-2010)
> 15
$ sudo dumpe2fs /dev/sda6 | fgrep -ie 'superblock'
> dumpe2fs 1.41.11 (14-Mar-2010)
>   Primary superblock at 0, Group descriptors at 1-14
>   Backup superblock at 32768, Group descriptors at 32769-32782
...

so I booted gparted-live-0.9.0-7 again and did

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

Note -b means, per `info e2fsck`,

> -b superblock
>    Instead of using the normal superblock, use an alternative
>    superblock specified by superblock. This option is normally used
>    when the primary superblock has been corrupted. The location of
>    the backup superblock is dependent on the filesystem's blocksize.
>    For filesystems with 1k blocksizes, a backup superblock can be
>    found at block 8193; for filesystems with 2k blocksizes, at block
>    16384; and for 4k blocksizes, at block 32768

... and I know my blockize (not to mention the position of the backup superblocks) per `dumpe2fs` above. So back to the results of `sudo e2fsck -b 32768 -fvy /dev/sda6`:

> e2fsck 1.42-WIP (02-Jul-2011)
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> Free blocks count wrong for group #1 (26596, counted=26645).
> Fix? yes

... 99 more "Free blocks count wrong" omitted

> Directories count wrong for group #1565 (27, counted=26).
> Fix? yes

> Free inodes count wrong for group #1571 (16381, counted=16383).
> Fix? yes

> Free inodes count wrong (27023121, counted=27023056).
> Fix? yes

> /dev/sda6: ***** FILE SYSTEM WAS MODIFIED *****

>   420144 inodes used (1.53%)
>    10853 non-contiguous files (2.6%)
>      316 non-contiguous directories (0.1%)
>          # of inodes with ind/dind/tind blocks: 47497/3765/2
> 32648103 blocks used (59.50%)
>        0 bad blocks
>        8 large files

>   388030 regular files
>    30383 directories
>        0 character device files
>        0 block device files
>        2 fifos
>        0 links
>     1713 symbolic links (1658 fast symbolic links)
>        7 sockets
> --------
>   420135 files

which looked good to me, particularly the "0 bad blocks." So I started GParted the app (before was using Terminal) and was pleased to see that it also showed /dev/sda6 having the correct size, followed by unallocated space. So I tried to just make the free space precede the partition, which GParted interpreted as the action

Move /dev/sda6 to the right and shrink it from 209.32 GiB to 209.32 GiB

which I applied. The good news is, GParted got farther before failing; but the bad news is, it still failed. Note steps numbered by me:

> 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 )

> e2fsck -f -y -v /dev/sda6
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> 420148 inodes used (1.53%)
> 10854 non-contiguous files (2.6%)
> 316 non-contiguous directories (0.1%)
> # of inodes with ind/dind/tind blocks: 47497/3765/2
> 32648113 blocks used (59.50%)
> 0 bad blocks
> 8 large files
> 388034 regular files
> 30383 directories
> 0 character device files
> 0 block device files
> 2 fifos
> 0 links
> 1713 symbolic links (1658 fast symbolic links)
> 7 sockets
> --------
> 420139 files
> e2fsck 1.42-WIP (02-Jul-2011)

> [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)

> [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)

> [5] check file system on /dev/sda6 for errors and (if possible) fix them  00:00:00    ( ERROR )

> e2fsck -f -y -v /dev/sda6
> Possibly non-existent device?
> e2fsck 1.42-WIP (02-Jul-2011)
> e2fsck: No such file or directory while trying to open /dev/sda6

> [6] grow file system to fill the partition  00:00:00    ( ERROR )

> resize2fs /dev/sda6
> resize2fs 1.42-WIP (02-Jul-2011)
> open: No such file or directory while opening /dev/sda6
> libparted messages    ( INFO )

> [7] Error informing the kernel about modifications to partition /dev/sda5 -- Device or resource busy. This means Linux won't know about any changes you made to /dev/sda5 until you reboot -- so you shouldn't mount it or use it in any way before rebooting.
> Failed to add partition 5 (Device or resource busy)

So what I'm wondering is,

  1. How could GParted possibly fail step 4? To "shrink partition from 209.32 GiB to 209.32 GiB" sounds like a NOP to me--am I missing something?

  2. How to get GParted over that hurdle? Or should I use another tool?

5 Reply by gedakc

  • gedakc
  • Developer
  • Offline
  • Registered: 2007-11-30
  • Posts: 4,593

Re: gparted-live-0.9.0-7: ext3 partition corrupted attempting move/shrink

From the last error message, it appears that for some reason there was a failure to inform the kernel about modifications to the partition table.

You might try rebooting your computer and then trying the operation again.

A year or two back the problem was prevalent with newer GNU/Linux distributions and the new versions of parted.  For the most part this problem has been addressed with recent GNU/Linux and parted, but based on your error log it would appear that this problem has not been completely eradicated.