1 (edited by gedakc 2011-11-13 20:38:36)

Topic: WARNING! Problem Resizing File Systems with GParted

*** We recommend GParted Live 0.6.2-2 or higher for all partition editing operations. ***

WARNING:  Problems resizing file systems can appear with GParted Live 0.4.8-1 through 0.5.2-9.

Several reports of problems resizing file systems using GParted have been posted by users in this forum.  Links to these specific instances of the problem can be found at the bottom of this initial post.  This resizing problem can affect all file systems.

In the case of shrinking an NTFS file system, the error message eventually displayed is:
ERROR: Current NTFS volume size is bigger than the device size!

While this problem was unresolved, we had recommended GParted Live 0.4.6-1 which was the last stable version prior to the first discovery of these file system resizing problems.  We now recommend GParted Live 0.6.2-2 or higher, which includes parted 2.3.

WARNING:  Do not use GParted Live 0.4.6-1 to resize ext4 file systems.  See:
Data corruption after resizing ext4 partitions with GParted Live 0.4.6-1

At the root of this problem is a failure to update the Linux kernel of the changes to the partition table.  Partition editing problems can be experienced using GParted with newer GNU/Linux kernels (2.6.31+), udev (138+), and parted (1.8.8.+ up to 2.2 inclusive).

We believe the problem is solved when GParted is used with parted 2.3 and higher on these newer GNU/Linux kernels.  Old GNU/Linux kernels appear to work well with parted 1.8.8 (non patched version).

Unfortunately once the file system resize error occurs, it requires manual intervention to fix.

If you are keen to try to solve this problem yourself, greegthegreek has started a draft tutorial on how to solve this problem for the NTFS file system:
Proposition of a tutorial for the NTFS size bug

In the case of the ext2/3/4 file systems, soupcan was able to resolve the problem for an ext4 file system:
Ext4-Gparted0.5.2-9-error after partition shrink

Please create a new post for your instance of this problem.
This helps to reduce the chance of making a mistake when reviewing partition and file system information.

To start solving the problem we will need to know the following:
1)  Which partition is experiencing the error?
2)  Which version of GParted or Live CD you used?
3)  The output from the following two commands:

fdisk -l -u

where one of the options is a lower case "L" and not the number one.

parted /path-to-your-device unit s print

where /path-to-your-device is something like /dev/sda.

The first discovery of this problem would occur when using GParted with newer Linux kernels and unpatched parted-1.9.0.

A bug report was opened and has since been closed regarding this problem:
Bug 601574 - ERROR: Current NTFS volume size is bigger than the device size!

*** Patrick Verner reports on Dec. 20, 2009 that parted-2.1 has this same problem.  If this is the case then parted-2.0 probably also has the same problem.  It would be wise to wait until some patches are released for these newer parted versions.

This problem WAS THOUGHT TO have been fixed starting with GParted Live 0.4.8-6.  At least the problem did not occur each and every time as was the case prior to resolving the above listed bug report (601574).

Then sometime near the release of GParted 0.5.0-3 some more users reported continuing problems resizing NTFS file systems even with GParted Live 0.4.8-6 to 0.5.0-3.  We finally were able to reproduce the problem that our users were experiencing.

It is much harder to reproduce this problem with GParted 0.4.8-6 to 0.5.0-3 and perhaps involves a timing issue that does not always occur.

We are tracking this new occurrence of the problem with the following bug report:
Bug 604298 -  Problems resizing file systems with gparted-live-0.5.0-3


Update 2010-01-31:  A work around to this problem has been included in the GParted 0.5.1 release.  This new release is now included in the GParted Live Stable folder.

Update 2010-02-26:  A patch has been committed to the Parted project git repository to work around this problem.  See Parted Patch - linux: add wait time and retries to kernel partition reread.  This patch is included in the Parted 2.2 release.

Update 2010-05-02:  An active LVM partition on the same disk will also cause the problem.
See either the May 2 news item, or the following bug report for a list of suggested patches to apply to parted-2.2 to avoid this problem: Bug 608712 - GParted fails to edit/delete partitions if active LVM on same disk device.
These suggested patches have been applied to GParted Live 0.5.2-9 which is available in the GParted Live Stable folder.

Update 2010-05-10:  The parted team has discovered another race condition that can cause the "failure to inform kernel of partition changes" problem.
libparted: avoid race in informing the kernel of partition table changes

It was announced on the parted mailing list that a new release is planned soon.  We will investigate either using this patch, or incorporating the new release if it comes out soon.

Update 2010-06-01:  The parted team has released parted version 2.3 on May 28, 2010.  We will be testing this release to determine if it is suitable for updating the GParted Live image.

Update 2010-06-03:  Testing with GParted using the recently released parted version 2.3 has shown the following:

  • Works well when used with newer GNU/Linux distributions, such as Ubuntu 10.04 and Fedora 12.

  • Always encounters the "failure to inform kernel of partition changes" problem when used with older GNU/Linux distributions, such as Ubuntu 8.04 and Ubuntu 8.10.

Since GParted Live is based on recent Debian distributions, we will further investigate including parted-2.3 on GParted Live in an effort to avoid the "failure to inform kernel of partition changes" problem.

Update 2010-06-17:  The Fedora project has a patched version of parted 2.2 (specifically parted-2.2-5.fc14) that has tested well with the upcoming GParted 0.6.0 release planned for Friday, Jun 18th, 2010.  As such we plan to include this release on the first GParted Live images.  Later we plan to look at parted-2.3 again.

Update 2010-07-14:  Parted 2.3 has been included on gparted-live-0.6.1-2.  Our testing with this version of parted has been very promising.  Also we are aware of at least one user who experienced the "failure to inform kernel of partition changes" problem with some earlier releases of parted, but not with parted-2.3.  This email thread can be found at:
Possible regression
Assuming no major problems are discovered with gparted-live-0.6.1-2 in the next while, then we will move this release from testing over to stable.

Update 2010-07-21:  gparted-live-0.6.1-2 has been moved to the stable release branch.  This release includes parted-2.3.  If you are using this release and encounter the problem outlined later in this post then please create a new post to let us know.

Update 2010-10-20:  Rewrote this post to make it easier to read.

Update 2011-11-13:  Bug 663980 - Avoid redundant file system maximize actions on copy, move, and resize has been opened to help further reduce the occurrences of this problem.

If you are compiling GParted on your own GNU Linux distribution then to try to avoid this resizing problem do not use GParted with an unpatched parted-1.9.0.  Please note that even by following these tips, you might still experience the resizing problem that we are tracking in bug 604298.

The critical patch required for parted-1.9.0 is:
Patch for 'commit to os' for linux
Please note that all patches found at the fedora site link listed below should be applied.

Patched versions of Parted can be found at the fedora site:
http://koji.fedoraproject.org/koji/buil … dID=129982

Instructions on how to apply the fedora patches can be found at the following link:
How to apply fedora patches to parted-1.9.0

We apologize for the grief and frustration that this problem may have caused you.

Curtis Gedak
Maintainer of GParted

LAST EDIT:  November 2, 2011
List of confirmed cases of this problem:
http://gparted-forum.surf4.info/viewtopic.php?id=13840 First report with GParted Live 0.5.0-3
http://gparted-forum.surf4.info/viewtopic.php?id=13875 ext3 file system
http://gparted-forum.surf4.info/viewtopic.php?id=13882 hfs+ file system
http://gparted-forum.surf4.info/viewtopic.php?id=13932 First report with sysresccd-1.3.4
http://gparted-forum.surf4.info/viewtopic.php?id=14077 Report with Fedora 12
http://gparted-forum.surf4.info/viewtopic.php?id=14082 First report with sysresccd-1.5.1
http://gparted-forum.surf4.info/viewtopic.php?id=14090 Report with Ubuntu 9.10 Live CD
http://gparted-forum.surf4.info/viewtopic.php?id=14093 Active LVM and gparted-live-0.5.2-1
http://gparted-forum.surf4.info/viewtopic.php?id=14096 Report with gparted-live-0.5.2-1
http://gparted-forum.surf4.info/viewtopic.php?id=14116 Report with kubuntu 10.04
http://gparted-forum.surf4.info/viewtopic.php?id=14125 Report with gparted-live-0.5.2-9
http://gparted-forum.surf4.info/viewtopic.php?id=14146 ext3 file system
http://gparted-forum.surf4.info/viewtopic.php?id=14172 Solved - ext4 file system
http://gparted-forum.surf4.info/viewtopic.php?id=14183 First report gparted-live-0.6.0-1
http://gparted-forum.surf4.info/viewtopic.php?id=14357 Ubuntu 10.10 Live CD w/gparted 0.6.2 & parted 2.3
http://gparted-forum.surf4.info/viewtopic.php?id=14392 Ubuntu 10.10 Live CD
http://gparted-forum.surf4.info/viewtopic.php?id=14393 Solved - ext2 file system
http://gparted-forum.surf4.info/viewtopic.php?id=14419 Partition Magic 8
http://gparted-forum.surf4.info/viewtopic.php?id=14476 Ubuntu 10.10 Live CD
http://gparted-forum.surf4.info/viewtopic.php?id=14611 Ubuntu Install
http://gparted-forum.surf4.info/viewtopic.php?id=14682 Knoppix Live CD with GParted 0.5.1
http://gparted-forum.surf4.info/viewtopic.php?id=15491 Fedora 15 LXDE installer
http://gparted-forum.surf4.info/viewtopic.php?id=15537 Knoppix 6.2.1 with GParted 0.5.1
http://gparted-forum.surf4.info/viewtopic.php?id=15552 Fedora 15 installer


Re: WARNING! Problem Resizing File Systems with GParted

Can you explain how to produced this bug? I have never seen this happen myself, but 1 Parted Magic user has mentioned this. If I can recreate the problem I might be able to help figure out what has changed in the kernel to cause this.


Re: WARNING! Problem Resizing File Systems with GParted

The crux of the problem appears to be that when a change is made to the partition table using GParted (libparted), the kernel is not aware of the change.  This causes problems when other utilities directly read the partition table from the kernel and perform actions based on this view, which is different than the one recently changed by GParted (libparted).

To recreate symptoms of the problem use:
GParted 0.4.8 (the version does not seem to matter)
Parted 1.9.0
Linux 2.6.30 (the problem does not appear with 2.6.24)

1)  Start GParted
2)  Create a partition table on a new disk device
3)  Create an NTFS partition that spans the whole device
4)  Quit GParted
5)  Check that the partition is recognized using "blkid" command
6)  Start GParted
7a)  Resize the NTFS partition to span only half of the device
       (don't click close on progress window)
7b)  Expand the Details view and observe that in the last entry
        that ntfsresize will grow the partition to fill the whole drive!!!
*** It is at this point that the partition table size (half of drive)
       is a mismatch with the NTFS file system size (whole drive)
7c)  Close the progress window
8)  Close GParted


Re: WARNING! Problem Resizing File Systems with GParted

Parted Magic 4.5 includes linux-2.6.30 and 4.6-rc1 includes linux-

This is the only complaint: http://forums.partedmagic.com/viewtopic … ize!#p2239

There are things to consider. Did they ever resize the file system with the resizer included in Vista or is it a Debian/Ubuntu kernel patch that's causing the issue? I can't reproduce the bug in Parted Magic, I'll try the last test release of GParted Live.


Re: WARNING! Problem Resizing File Systems with GParted

I created a new disk in Virtual box and made an NTFS file system on it. I moved, shrunk, grew, moved the beginning and moved the end on Parted Magic with kernel's 2.6.30 and 2.6.31. I couldn't get it to fail. I downloaded the GParted Live 0.4.8 and started with a fresh disk in Virtual box. It failed the first time I tried to grow it after I shrunk it. I altered the partition 20 times or more in Parted Magic without any issues.

Parted Magic uses a vanilla kernel with only official reiser4 and a unionfs patches. Debian and Ubuntu patch the living bajesus out of their kernels. The fault might be a Debian patch of some sort.

I'll try System Rescue CD and RIP too.


Re: WARNING! Problem Resizing File Systems with GParted

I can reproduce the error with any file system type using GParted Live 0.4.8, even ext2/ext3/ext4.


Re: WARNING! Problem Resizing File Systems with GParted

System Rescue CD works just fine. I'm almost certain it's a Debian induced bug. I hope this bug isn't included in Ubuntu 9.10, this could get ugly. sad


Re: WARNING! Problem Resizing File Systems with GParted

Thank you Patrick for your help with this problem.

I suspected that the problem would appear with other file systems as well (e.g, ext2/ext3/ext4).

Sometimes the problem does not appear right away.  I find this strange and haven't been able to pin down an exact set of steps that reproduces the problem 100% of the time.  Instead I have resorted to testing multiple times and carefully checking the result each time.

I have a confirmed case with SysRescCd 1.3.1 which uses gparted-0.4.6 and parted-1.9.0.
Since this uses Gentoo, I think the problem is not limited to just Debian.

I have also recreated the problem with Karmic Ubuntu 9.10, gparted-0.4.6 and parted-1.9.0.

I am continuing to investigate.

I have confirmed the problem exists with the testing version of Parted Magic 4.6 (pmagic-4.6.iso-08Nov,003720.zip) which uses gparted-0.4.8-git, parted-1.9.0, and linux kernel


Re: WARNING! Problem Resizing File Systems with GParted

Do you think calling partprobe in GParted might make things more reliable? Wouldn't that force the kernel to reread the partition table instead of relying on it to do it itself? If the partprobe command doesn't complete or shows an error, stop before issuing the next step.

partprobe is a program that informs the operating system kernel of partition table changes, by requesting that the operating system re-read the partition table.

I'll try to hack it in and see if it helps.


Re: WARNING! Problem Resizing File Systems with GParted

I am interested to learn how you make out with your theory.

So far, the problem only seems to appear with some combinations of GParted, Parted, and newer Linux kernels.

The following scenario _does not_ exhibit the resizing problem:
GParted 0.4.8
Parted 1.9.0
Linux 2.6.24-23 (Kubuntu Hardy Heron 8.04)

The following scenario _does_ exhibit the resizing problem:
GParted 0.4.8
Parted 1.9.0
Linux 2.6.31-14 (Ubuntu Karmic Kameleon 9.10)

The following scenario _does not_ exhibit the resizing problem:
GParted 0.4.8
Linux 2.6.31-14 (Ubuntu Karmic Kameleon 9.10)

This leads me to believe that there is some interaction between Parted and newer Linux kernels that causes the resizing problem.  Using this knowledge I have been trying to reproduce the problem with Parted alone (no GParted).  So far I have been unsuccessful in this endeavour.  ;(


Re: WARNING! Problem Resizing File Systems with GParted

Patrick Verner wrote:

Do you think calling partprobe in GParted might make things more reliable? Wouldn't that force the kernel to reread the partition table instead of relying on it to do it itself?

Following is the piece of code near the end of the GParted_Core.cc file that is responsible for committing partition changes to disk.  In theory the ped_disk_commit_to_os() call should update the operating system with the changes to the partition table.

The reason for the dmraid logic around the call is that an error is thrown if ped_disk_commit_to_os() is called on a dmraid device.

bool GParted_Core::commit_to_os( std::time_t timeout ) 
    DMRaid dmraid ;
    bool succes ;
    if ( dmraid .is_dmraid_device( lp_disk ->dev ->path ) )
        succes = true ;
        succes = ped_disk_commit_to_os( lp_disk ) ;

    settle_device( timeout ) ;

    return succes ;


Re: WARNING! Problem Resizing File Systems with GParted

I'm not having any luck using partprobe. I even tried sleeping for 3 seconds, executing partprobe, and then sleeping for 3 seconds again before ntfsresize actually grows the file system.

I just hard coded the command into ntfs.cc for my test like this: sleep 3 && partprobe /dev/hda1 && sleep 3 && ntfsresize...

Maybe it would be better to use the -s flag in conjunction with the size called in the GUI instead of leaving the flags out and allowing the program to blindly fill the partition to what the kernel is saying the partition size is. It might not be ideal, but it's better than having the file system completely corrupted. If I tell GParted to resize my partition and filesystem to 500MB it shouldn't grow the file system to 1.5GB on a 1GB flash drive. I know it's not parted or GParted that's doing this, it's the external programs and the kernel being grossly off from each other. The device itself is always the correct size in the end with this failure, it's the file systems that wrong.

I'm going to look at the source code for ntfsresize and see how they are determining how big to make the file system if no size flags are present.


Re: WARNING! Problem Resizing File Systems with GParted

Patrick Verner wrote:

Maybe it would be better to use the -s flag in conjunction with the size called in the GUI instead of leaving the flags out and allowing the program to blindly fill the partition to what the kernel is saying the partition size is. It might not be ideal, but it's better than having the file system completely corrupted.

I had thought of this as a possible solution too, and it is a good idea, but the problem is even bigger than just resizing. 

The key to the problem is that the kernel is not recognizing new partition boundaries.  Hence even formatting a partition that was changed by GParted can result in the format command seeing an old partition size.  I have come across this problem myself in my testing.

I am trying to build a small C program that performs the same steps as GParted to see if I can come up with a small test case that will reproduce this problem.  If I am successful with this, then I will have something to report to the Parted team that they can evaluate.


Re: WARNING! Problem Resizing File Systems with GParted

How reliable would this be for verifying sizes before growing the file system?

cat /sys/block/sda1/size


Re: WARNING! Problem Resizing File Systems with GParted

Great News!

Many thanks go to Francois Dupoux who has found patches for parted which fix this problem.

See the following email for more details:
http://sourceforge.net/mailarchive/foru … rted-devel


Re: WARNING! Problem Resizing File Systems with GParted

Nothing has changed. I downloaded systemrescuecd-x86-1.3.3-beta2.iso and the problem still exists. I can reproduce the error just as easy as before. Download it and see for yourself. I also used those patches and compiled it myself for Parted Magic and the problem is there also. I don't think parted is doing anything wrong. I think somebody introduced something into the kernel that's making it slower in some way and GParted is just rifling though the resize commands before the kernel has time to sync itself. I tried to reproduce this bug with parted alone and I can get it to fail no matter how many times I try.



Re: WARNING! Problem Resizing File Systems with GParted

Hmm... that is strange.  The screen shot you posted certainly shows a problem.

I did download systemrescuecd-x86-1.3.3-beta2.iso and have been running it in a virtual machine.  So far it has been resizing NTFS partitions flawlessly for me.  I also applied the patch to the parted-1.9.0 file libparted/disk.c under Ubuntu 9.10 and the problem disappeared there too.

Is there anything special that you can think of that you do when you recreate the problem with systemrescuecd-x86-1.3.3-beta2.iso?

Would you be able to try wiping the MBR and NTFS PBR from the device you are using for testing, then reboot and try again?

You can wipe out the first section of the drive with a command such as:
     dd if=/dev/zero of=/path-to-your-device-to-erase bs=512 count=1000

I am also very interested in the steps you use to re-create the problem using parted alone.


Re: WARNING! Problem Resizing File Systems with GParted

I miss typed. It was supposed to be "cannot" with parted alone. I said "can". oops.

1) create an new partition table and an ntfs filesystem.
2) reboot the virtual machine.
3) resize the partition with gparted to the smallest size allowed.
4) move it to the right about 3/4 of the way across the empty space.
5) failure after a few tries and sometimes right away.

I can do it over and over again with the sysresccd iso. It usually only takes a few tries.

I wish I could say it's fixed.

"War, yes. It affects us all." -Treebeard

This is how I see this issue. We all need to figure this out one way or another, it's fargin war! tongue


Re: WARNING! Problem Resizing File Systems with GParted

No worries on the typo.  I've done those a few times myself wink

Thanks for the testing steps you use.  I have repeated them several times with systemrescuecd-x86-1.3.3-beta2.iso and all moves and resizes have performed flawlessly.

Still there must be something different if you can still reproduce this resizing problem where parted fails to inform the kernel of partition changes.

I am using all of the default options in GParted 0.4.8 (i.e., "Round to cylinders" is enabled / checked).

For a virtual machine I am using VMware Player Version 2.5.0 build-118166.

The one drawback to using VMware Player I have found is that once I write data to the first drive (/dev/sda), then I am unable to boot the virtual machine off of a CD or .iso image again.  It always wants to try to boot from the first drive if the drive has a valid partition table.

My work around is to do my testing on the second drive (/dev/sdb) if I want to be able to reboot from a CD (such as the test steps you describe).

I will also perform some testing directly on my computer (no virtual machine) to see if I can reproduce the problem using the steps in post #18.

Patrick, did you have a chance to try wiping the drive and then rebooting?
Does it make any difference in your testing?

I have done testing directly on my computer (not through a virtual machine) and I cannot reproduce the problem with systemrescuecd-x86-1.3.3-beta2.iso.  Hence the problem does appear to be solved from my perspective.

The md5sum on the image I am using is:
162a5e2b11a2baa961d3a4e7c12ee841  systemrescuecd-x86-1.3.3-beta2.iso

Perhaps the md5sum on the image you are using differs???


Re: WARNING! Problem Resizing File Systems with GParted

I'm using the same systemrescuecd-x86-1.3.3-beta2.iso you are. tongue

I couldn't reproduce the error after the disk was wiped. Simply creating a new partition table doesn't make the disk "clean" enough. I wiped the disk with dd, created a new partition table, and then created an NTFS file system. After this, the error cannot be reproduced with systemrescuecd-x86-1.3.3-beta2.iso.

I think it's fixed too.


Re: WARNING! Problem Resizing File Systems with GParted

Thank you Patrick for your work on the problem and for confirming that it is now fixed.

The help is appreciated.  big_smile


Re: WARNING! Problem Resizing File Systems with GParted

Tried to downsize my NTFS partition using GParted Live CD 0.5.0-3 and now I'm seeing this same volume size error.
Can I recover my partition by using GParted Live 0.4.6-1 or is it too late?


Re: WARNING! Problem Resizing File Systems with GParted

Unfortunately once the NTFS resize error occurs, it requires manual intervention to fix.

Please create a new post for your instance of this problem.

To start solving the problem we will need to know which partition is experiencing the error, which version of GParted or Live CD you used, and also the output from the following two commands:

fdisk -l -u

where one of the options is a lower case "L" and not the number one.

parted /path-to-your-device unit s print

where /path-to-your-device is something like /dev/sda.

24 (edited by Patrick Verner 2009-12-14 02:58:06)

Re: WARNING! Problem Resizing File Systems with GParted

Hey Curtis, try the newest test version of Parted Magic. It has Linux 2.6.32 included. Maybe this is fixed in the new kernel. If you look through the change log there are some mentions about SCSI not being read correctly. I looked at your list of "cases" in the other thread and every single one of them is a SCSI/SATA (sdx) device. I'm not sure if this could be the problem. I tried very hard in the test version of Parted Magic and I cannot get it to fail.

From the linux-2.6.32 changelog:

[SCSI] fix oops during scsi scanning
    Chris Webb reported:
      p0# uname -a
      Linux f7ea8425-d45b-490f-a738-d181d0df6963.host.elastichosts.com #2 SMP PREEMPT Thu Aug 20 14:30:50 BST 2009 x86_64 Intel(R) Xeon(R) CPU E5420 @ 2.50GHz GenuineIntel GNU/Linux
      p0# zgrep SCAN_ASYNC /proc/config.gz
      # CONFIG_SCSI_SCAN_ASYNC is not set
      p0# cat /var/log/kern/2009-08-20
      15:27:10.485 kernel: scsi9 : iSCSI Initiator over TCP/IP
      15:27:11.493 kernel: scsi 9:0:0:0: RAID              IET      Controller       0001 PQ: 0 ANSI: 5
      15:27:11.493 kernel: scsi 9:0:0:0: Attached scsi generic sg6 type 12
      15:27:11.495 kernel: scsi 9:0:0:1: Direct-Access     IET      VIRTUAL-DISK     0001 PQ: 0 ANSI: 5
      15:27:11.495 kernel: sd 9:0:0:1: Attached scsi generic sg7 type 0
      15:27:11.495 kernel: sd 9:0:0:1: [sdg] 4194304 512-byte hardware sectors: (2.14 GB/2.00 GiB)
      15:27:11.495 kernel: sd 9:0:0:1: [sdg] Write Protect is off
      15:27:11.495 kernel: sd 9:0:0:1: [sdg] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
      15:27:13.012 kernel: sdg:<6>scsi 9:0:0:1: [sdg] Unhandled error code
      15:27:13.012 kernel: scsi 9:0:0:1: [sdg] Result: hostbyte=0x07 driverbyte=0x00
      15:27:13.012 kernel: end_request: I/O error, dev sdg, sector 0
      15:27:13.012 kernel: Buffer I/O error on device sdg, logical block 0
      15:27:13.012 kernel: ldm_validate_partition_table(): Disk read failed.
      15:27:13.012 kernel: unable to read partition table
      15:27:13.014 kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
      15:27:13.014 kernel: IP: [<ffffffff803f0d77>] disk_part_iter_next+0x74/0xfd
      15:27:13.014 kernel: PGD 82ad0b067 PUD 82cd7e067 PMD 0
      15:27:13.014 kernel: Oops: 0000 [#1] PREEMPT SMP
      15:27:13.014 kernel: last sysfs file: /sys/devices/platform/host9/session4/iscsi_session/session4/ifacename
      15:27:13.014 kernel: CPU 5
      15:27:13.014 kernel: Modules linked in:
      15:27:13.014 kernel: Pid: 13999, comm: async/0 Not tainted #2 X7DBN
      15:27:13.014 kernel: RIP: 0010:[<ffffffff803f0d77>]  [<ffffffff803f0d77>] disk_part_iter_next+0x74/0xfd
      15:27:13.014 kernel: RSP: 0018:ffff88066afa3dd0  EFLAGS: 00010246
      15:27:13.014 kernel: RAX: ffff88082b58a000 RBX: ffff88066afa3e00 RCX: 0000000000000000
      15:27:13.014 kernel: RDX: 0000000000000000 RSI: ffff88082b58a000 RDI: 0000000000000000
      15:27:13.014 kernel: RBP: ffff88066afa3df0 R08: ffff88066afa2000 R09: ffff8806a204f000
      15:27:13.014 kernel: R10: 000000fb12c7d274 R11: ffff8806c2bf0628 R12: ffff88066afa3e00
      15:27:13.014 kernel: R13: ffff88082c829a00 R14: 0000000000000000 R15: ffff8806bc50c920
      15:27:13.014 kernel: FS:  0000000000000000(0000) GS:ffff88002818a000(0000) knlGS:0000000000000000
      15:27:13.014 kernel: CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      15:27:13.014 kernel: CR2: 0000000000000010 CR3: 000000082ade3000 CR4: 00000000000426e0
      15:27:13.014 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      15:27:13.014 kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      15:27:13.014 kernel: Process async/0 (pid: 13999, threadinfo ffff88066afa2000, task ffff8806c2bf05e0)
      15:27:13.014 kernel: Stack:
      15:27:13.014 kernel: 0000000000000000 ffff88066afa3e00 ffff88066afa3e00 ffff88082c829a00
      15:27:13.014 kernel: ffff88066afa3e40 ffffffff80306feb ffff88082b58a000 0000000000000000
      15:27:13.014 kernel: 0000000000000001 ffff8806bc50c920 ffff88066afa3e40 ffff88082b58a000
      15:27:13.014 kernel: Call Trace:
      15:27:13.014 kernel: [<ffffffff80306feb>] register_disk+0x122/0x13a
      15:27:13.014 kernel: [<ffffffff803f0b0f>] add_disk+0xaa/0x106
      15:27:13.014 kernel: [<ffffffff80493609>] sd_probe_async+0x198/0x25b
      15:27:13.014 kernel: [<ffffffff80270482>] async_thread+0x10c/0x20d
      15:27:13.014 kernel: [<ffffffff802545ff>] ? default_wake_function+0x0/0xf
      15:27:13.014 kernel: [<ffffffff80270376>] ? async_thread+0x0/0x20d
      15:27:13.014 kernel: [<ffffffff8026ad89>] kthread+0x55/0x80
      15:27:13.014 kernel: [<ffffffff8022be6a>] child_rip+0xa/0x20
      15:27:13.014 kernel: [<ffffffff8026ad34>] ? kthread+0x0/0x80
      15:27:13.014 kernel: [<ffffffff8022be60>] ? child_rip+0x0/0x20
      15:27:13.014 kernel: Code: c8 ff 80 e1 0c b9 00 00 00 00 0f 44 c1 41 83 cd ff 48 8d 7a 20 48 be ff ff ff ff 08 00 00 00 48 b9 00 00 00 00 08 00 00 00 eb 50 <8b> 42 10 41 bd 01 00 00 00 eb db 4c 63 c2 4e 8d 04 c7 4d 8b 20
      15:27:13.015 kernel: RIP  [<ffffffff803f0d77>] disk_part_iter_next+0x74/0xfd
      15:27:13.015 kernel: RSP <ffff88066afa3dd0>
      15:27:13.015 kernel: CR2: 0000000000000010
      15:27:13.015 kernel: ---[ end trace 6104b56ef5590e25 ]---
    The problem is caused because the async scanning split in sd.c doesn't hold
    any reference to the device when it kicks off the async piece.  What's
    happening is that an iSCSI disconnect is destorying the device again *before*
    the async sd scanning thread even starts.  Fix this by taking a reference
    before starting the thread and dropping it again when the thread completes.
    Reported-by: Chris Webb <chris@arachsys.com>
    Cc: Stable Tree <stable@kernel.org>
    Signed-off-by: James Bottomley <James.Bottomley@suse.de>


Re: WARNING! Problem Resizing File Systems with GParted

Your help to solve this problem is always appreciated Patrick.

There might be something to your SCSI theory and the Linux kernel version.  We do have at least one user with an IDE drive reporting the problem with GParted Live 0.5.0-3:

I also found that Parted Magic did not appear to have the resizing problem.  Neither does the System Rescue CD which happens to be using Linux kernel (with btrfs patches).  This problem is being tracked with the following bug report:
Bug 604298 -  Problems resizing file systems with gparted-live-0.5.0-3