After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 604298 - Problems resizing file systems with gparted-live-0.5.0-3
Problems resizing file systems with gparted-live-0.5.0-3
Status: RESOLVED FIXED
Product: gparted
Classification: Other
Component: livecd
0.5.0
Other Linux
: Normal normal
: ---
Assigned To: gparted maintainers alias
gparted maintainers alias
: 596415 609097 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-12-10 18:36 UTC by Curtis Gedak
Modified: 2010-02-23 22:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GParted Live 0.5.0-3 package list (35.58 KB, text/plain)
2009-12-14 22:07 UTC, Curtis Gedak
  Details
resize-using-libparted.c (2.93 KB, text/x-csrc)
2009-12-21 18:44 UTC, Curtis Gedak
  Details
test-partition-resize.sh (3.43 KB, application/x-sh)
2009-12-21 18:47 UTC, Curtis Gedak
  Details
Screen shot of the problem occurring on iteration 242 (125.18 KB, image/png)
2009-12-22 00:50 UTC, Curtis Gedak
  Details
Screen shot of the problem occurring on iteration 9841 on fedora 12 (125.89 KB, image/png)
2009-12-22 17:22 UTC, Curtis Gedak
  Details
Screen shot of the problem occurring on iteration 4615 on fedora 12 (127.43 KB, image/png)
2009-12-23 17:22 UTC, Curtis Gedak
  Details
Screen shot of the problem occurring on iteration 8177 with parted-2.1 on fedora 12 (124.99 KB, image/png)
2010-01-01 18:01 UTC, Curtis Gedak
  Details
Screen shot of problem never occurring even after 42 hours and 33046 iterations with SysRescCD-1.3.4 (49.76 KB, image/png)
2010-01-07 19:13 UTC, Curtis Gedak
  Details
Screen shot of the problem occurring on iteration 244 on fedora 12 (HAL not running) (131.28 KB, image/png)
2010-01-07 20:01 UTC, Curtis Gedak
  Details
Screen shot of the problem occurring on iteration 241 on ubuntu 9.10 (133.81 KB, image/png)
2010-01-09 18:00 UTC, Curtis Gedak
  Details
Screen shot of the problem occurring on iteration 8180 on fedora 12 (154.41 KB, image/png)
2010-01-16 16:04 UTC, Curtis Gedak
  Details
Screen shot of successful completion of 99,999 iterations on fedora 12 using libparted patch (146.48 KB, image/png)
2010-01-23 23:45 UTC, Curtis Gedak
  Details
Screen shot of the problem occurring on iteration 989 on fedora 12 with git head of parted (127.76 KB, image/png)
2010-01-27 20:08 UTC, Curtis Gedak
  Details
Screen shot of successful completion of 99,999 iterations on fedora 12 using libparted git patch (130.96 KB, image/png)
2010-02-02 17:02 UTC, Curtis Gedak
  Details
Patch for master branch of parted git repository as of Feb 2, 2010 (1.80 KB, patch)
2010-02-02 17:42 UTC, Curtis Gedak
none Details | Review

Description Curtis Gedak 2009-12-10 18:36:34 UTC
The problem outlined in bug #601574 still occurs occasionally with GParted Live 0.5.0-3.

Bug 601574 - ERROR: Current NTFS volume size is bigger than the device size!
https://bugzilla.gnome.org/show_bug.cgi?id=601574

This problem can occur with any file system, not just NTFS.

When this problem occurs, a libparted message similar to the following can be found in the details log for the resizing operation (gparted_details.htm)

     "Error informing the kernel about modifications to partition
     /dev/sda1 -- Device or resource busy. This means Linux won't
     know about any changes you made to /dev/sda1 until you
     reboot -- so you shouldn't mount it or use it in any way
     before rebooting."

This problem has been opened under the component "livecd" instead of "application" because I suspect the root cause is related to a package or library other than the GParted code.
Comment 1 Curtis Gedak 2009-12-10 21:24:30 UTC
I have repeated resize testing with System Rescue CD, and so far every resize operation has completed successfully.  The two versions of SysRescCd that I tested were:
systemrescuecd-x86-1.3.3-rc1.iso
systemrescuecd-x86-1.3.4-beta2.iso

This leads me to believe that the cause of the problem has to do with some difference between the packages or patches used on SysRescCd versus those used on GParted Live.

SysRescCd is based on Gentoo, GParted Live is based on Debian.

Both Live distributions use a patched version of parted-1.9.0.
SysRescCd uses an additional patch for the mfstres bug which is over and above the patches used in parted-1.9.0-14_fc12.  See:
http://systemrescuecd.svn.sourceforge.net/viewvc/systemrescuecd/trunk/portage-overlay/sys-apps/parted/
I highly doubt that this difference is the cause of the problem.

systemrescuecd-x86-1.3.3rc1 uses Linux-2.6.31.6 (with btrfs patches)
gparted-live-0.5.0-3        uses Linux-2.6.31-1


systemrescuecd-x86-1.3.3rc1 uses udev-146-r1 (with additional patches)
gparted-live-0.5.0-3        uses udev-148


Since the problem does not occur every time on GParted Live 0.5.0-3, I suspect that it has to do with something like a timing issue.  This leads me to suspect a problem with the udev package, though I have no proof of such at this time.  This is only a guess.
Comment 2 Curtis Gedak 2009-12-10 22:53:30 UTC
I have also repeated resize testing with the Parted Magic CD, and so far every resize operation has completed successfully.  The version of Parted Magic I tested was:
pmagic-4.7.iso-09Dec,200309.zip

This uses a patched version of parted-1.9.0, Linux-2.6.32, and udev-149.
Comment 3 Curtis Gedak 2009-12-13 19:47:39 UTC
The problem does not appear to occur on every resize operation.  Instead it seems random in nature and is perhaps due to some timing problem.

To recreate the problem I use the following steps:

1)  Start GParted
2)  Create an MSDOS partition table on a new disk device
3)  Create an NTFS partition that spans the whole device

4)  Repeat the following random resizing steps up to 20 times.

4a)  Either shrink or grow the NTFS partition and click apply
       (don't click close on progress window)
4b)  Expand the Details view and expand the first entry
4c)  If the last entry says "libparted messages" then you have most
     likely encountered the problem.  You can stop at this point.
4d)  Close the progress window

5)  Delete the NTFS partition
6)  Close GParted
Comment 4 Curtis Gedak 2009-12-13 22:57:53 UTC
On December 12th, 2009 I did some testing with an up-to-date version of Ubuntu 9.10 and parted-1.9.0-14 (fedora 12 patches) and the resize problem still occurred.

Then also on Dec 12th, I either either rebooted to activate the changes, or I ran another system update (I can't remember now which it was).

Anyways, now on Dec 13th, the resize problem does not appear to occur now.  :-)


The commit log for the Ubuntu 9.10 virtual machine I used for these tests is as follows:

----------------------------------------------------------------------
Commit Log for Sat Dec 12 13:11:59 2009


Upgraded the following packages:
evolution-indicator (0.2.4-0ubuntu2) to 0.2.4-0ubuntu3.1
fuse-utils (2.7.4-1.1ubuntu4) to 2.7.4-1.1ubuntu4.1
libfuse2 (2.7.4-1.1ubuntu4) to 2.7.4-1.1ubuntu4.1
linux-headers-2.6.31-16 (2.6.31-16.52) to 2.6.31-16.53
linux-headers-2.6.31-16-generic (2.6.31-16.52) to 2.6.31-16.53
linux-image-2.6.31-16-generic (2.6.31-16.52) to 2.6.31-16.53
linux-libc-dev (2.6.31-16.52) to 2.6.31-16.53

----------------------------------------------------------------------
Commit Log for Thu Dec 10 15:38:12 2009


Upgraded the following packages:
bind9-host (1:9.6.1.dfsg.P1-3) to 1:9.6.1.dfsg.P1-3ubuntu0.2
devicekit-disks (007-2ubuntu3) to 007-2ubuntu4
dnsutils (1:9.6.1.dfsg.P1-3) to 1:9.6.1.dfsg.P1-3ubuntu0.2
gdm (2.28.1-0ubuntu2) to 2.28.1-0ubuntu2.1
gnome-screensaver (2.28.0-0ubuntu3) to 2.28.0-0ubuntu3.1
grub-common (1.97~beta4-1ubuntu4) to 1.97~beta4-1ubuntu4.1
grub-pc (1.97~beta4-1ubuntu4) to 1.97~beta4-1ubuntu4.1
libbind9-50 (1:9.6.1.dfsg.P1-3) to 1:9.6.1.dfsg.P1-3ubuntu0.2
libdns50 (1:9.6.1.dfsg.P1-3) to 1:9.6.1.dfsg.P1-3ubuntu0.2
libisc50 (1:9.6.1.dfsg.P1-3) to 1:9.6.1.dfsg.P1-3ubuntu0.2
libisccc50 (1:9.6.1.dfsg.P1-3) to 1:9.6.1.dfsg.P1-3ubuntu0.2
libisccfg50 (1:9.6.1.dfsg.P1-3) to 1:9.6.1.dfsg.P1-3ubuntu0.2
liblwres50 (1:9.6.1.dfsg.P1-3) to 1:9.6.1.dfsg.P1-3ubuntu0.2
linux-generic (2.6.31.15.28) to 2.6.31.16.29
linux-headers-generic (2.6.31.15.28) to 2.6.31.16.29
linux-image-generic (2.6.31.15.28) to 2.6.31.16.29
linux-libc-dev (2.6.31-15.50) to 2.6.31-16.52
ntpdate (1:4.2.4p6+dfsg-1ubuntu5) to 1:4.2.4p6+dfsg-1ubuntu5.1

Installed the following packages:
libdns53 (1:9.6.1.dfsg.P1-3ubuntu0.2)
linux-headers-2.6.31-16 (2.6.31-16.52)
linux-headers-2.6.31-16-generic (2.6.31-16.52)
linux-image-2.6.31-16-generic (2.6.31-16.52)

----------------------------------------------------------------------
Commit Log for Fri Dec  4 11:21:38 2009

Available if we need it.  :-)

----------------------------------------------------------------------


From my reasoning, the problem must have been fixed by one of the above updates and likely from the group of updates on Dec 12th, 2009.

I will try to determine which update fixes the problem.
Comment 5 Curtis Gedak 2009-12-13 22:59:21 UTC
We are also tracking instances of this resizing problem in the following GParted forum post:

WARNING! Problem Resizing File Systems with GParted
http://gparted-forum.surf4.info/viewtopic.php?id=13777
Comment 6 Curtis Gedak 2009-12-13 23:09:23 UTC
Following are some important dates for the parted and gparted versions I used when testing.  These help establish when the problem might have been solved on my Ubuntu 9.10 virtual machine.

user@karmic:~$ ls -l /usr/local/sbin/gparted
-rwxr-xr-x 1 root root 1760 2009-12-12 13:20 /usr/local/sbin/gparted
user@karmic:~$ ls -l /usr/local/sbin/parted
-rwxr-xr-x 1 root root 164388 2009-12-12 13:10 /usr/local/sbin/parted
user@karmic:~$ 

Unfortunately these timestamps span the time in which the updates were being applied.  I.e., "Commit Log for Sat Dec 12 13:11:59 2009".
Comment 7 Curtis Gedak 2009-12-13 23:29:43 UTC
My assumption is that the important change is related to the updated linux-image.

A snippet of the change log from the following link follows:
http://changelogs.ubuntu.com/changelogs/pool/main/l/linux/linux_2.6.31-16.53/changelog
------------------------------------------------------------
linux (2.6.31-16.52) karmic-security; urgency=low

  [ Leann Ogasawara ]

  * [SCSI] megaraid_sas: remove sysfs poll_mode_io world writeable
    permissions
    - CVE-2009-3939

  [ Upstream Kernel Changes ]

  * fs: pipe.c null pointer dereference
    - CVE-2009-3547
  * netlink: fix typo in initialization
    - CVE-2009-3612
  * drm/r128: Add test for initialisation to all ioctls that require it
    - CVE-2009-3620
  * AF_UNIX: Fix deadlock on connecting to shutdown socket
    - CVE-2009-3621
  * nfsd4: use common rpc_cred for all callbacks
    - CVE-2009-3623
  * KEYS: get_instantiation_keyring() should inc the keyring refcount in
    all cases
    - CVE-2009-3624
  * connector: Keep the skb in cn_callback_data
    - CVE-2009-3725
  * connector: Provide the sender's credentials to the callback
    - CVE-2009-3725
  * connector: Fix incompatible pointer type warning
    - CVE-2009-3725
  * uvesafb/connector: Disallow unpliviged users to send netlink packets
    - CVE-2009-3725
  * pohmelfs/connector: Disallow unpliviged users to configure pohmelfs
    - CVE-2009-3725
  * dst/connector: Disallow unpliviged users to configure dst
    - CVE-2009-3725
  * dm/connector: Only process connector packages from privileged processes
    - CVE-2009-3725
  * NOMMU: Don't pass NULL pointers to fput() in do_mmap_pgoff()
    - CVE-2009-3888
  * isdn: hfc_usb: Fix read buffer overflow
    - CVE-2009-4005
  * gdth: Prevent negative offsets in ioctl CVE-2009-3080
    - CVE-2009-3080
  * mac80211: fix spurious delBA handling
    - LP: #491301
  * mac80211: fix two remote exploits
    - LP: #491301
  * ipv4: additional update of dev_net(dev) to struct *net in ip_fragment.c
    - LP: #491301

 -- Leann Ogasawara <leann.ogasawara@canonical.com>  Mon, 23 Nov 2009 13:57:30 -0800

linux (2.6.31-15.50) karmic-proposed; urgency=low

  [ Kees Cook ]

  * SAUCE: Fix nx_enable reporting
    - LP: #454285

 -- Stefan Bader <stefan.bader@canonical.com>  Tue, 10 Nov 2009 14:31:52 +0100

------------------------------------------------------------

Perhaps it is the SCSI update the resolves the problem?

Patrick Verner suggested this as a possible solution in the following GParted forum post:
http://gparted-forum.surf4.info/viewtopic.php?pid=22228#p22228
Comment 8 Curtis Gedak 2009-12-14 22:07:23 UTC
Created attachment 149731 [details]
GParted Live 0.5.0-3 package list

The attached file contains the list of packages used in GParted Live 0.5.0-3.
Comment 9 Curtis Gedak 2009-12-21 18:44:24 UTC
Created attachment 150185 [details]
resize-using-libparted.c

Finally, I have been able to create a program (and script to follow) that will automatically keep trying resize operations.  With these I have been able to reproduce the situation in which the error "failure to inform kernel of partition changes" sometimes happens.

The nature of this problem leads me to believe that we are dealing with some kind of race situation.

To compile this code, you can use the following command:

   gcc -lparted -luuid -ldl -o resize-using-libparted resize-using-libparted.c

Please note the script which follows is used to call this compiled code to keep trying resize operations for as many times as you specify.
Comment 10 Curtis Gedak 2009-12-21 18:47:52 UTC
Created attachment 150186 [details]
test-partition-resize.sh

This attached script is used with a compiled version of the resize-using-libparted.c program to continually try partition resizing operations.

NOTE:  This script will wipe out the contents of the hard disk device that is passed as a parameter.

To run the script on drive /dev/sdd for 6 iterations, use the following command:

   ./test-partition-resize.sh /dev/sdd 6

The hope is that with an automated way to recreate the problem, that more headway can be made towards resolving this problem.
Comment 11 Curtis Gedak 2009-12-22 00:50:38 UTC
Created attachment 150210 [details]
Screen shot of the problem occurring on iteration 242

I have reproduced the problem using fedora 12.

STEPS TO REPRODUCE PROBLEM

1)  Start with a fedora 12 image.

    I built a virtual machine using the Fedora-12-i686-Live.iso image file.

2)  Install prerequisites to compile the code:

    $ yum groupinstall "Development Tools"
    $ yum install parted-devel
    $ yum install e2fsprogs-devel

3)  Compile the code

    $ gcc -lparted -ldl -o resize-using-libparted resize-using-libparted.c

4)  Test for the error using a hard disk device with no important data.

     WARNING:  The drive used for testing will be erased!

    $ ./test-partition-resize.sh /dev/sdb 99999


SCREEN SHOT

Attached is a screen shot of the problem occurring on iteration 242.  This problem is random in nature and can occur at any time.
Comment 12 Curtis Gedak 2009-12-22 17:22:24 UTC
Created attachment 150243 [details]
Screen shot of the problem occurring on iteration 9841 on fedora 12

TEST2
=====

To try another approach to solving the problem, I placed open and close device calls around the commit_to_dev and commit_to_os calls.


The change to the code is as follows:

gedakc@quad:~$ diff -c resize-using-libparted.c resize-using-libparted-test2.c
*** resize-using-libparted.c	2009-12-20 15:45:12.000000000 -0700
--- resize-using-libparted-test2.c	2009-12-21 17:59:28.000000000 -0700
***************
*** 22,31 ****
--- 22,36 ----
  
  int commit( PedDisk *lp_disk )
  {
+   /* Try commit to os patch from libparted */
+   ped_device_open( lp_disk -> dev );
+ 
    int return_val = ped_disk_commit_to_dev( lp_disk ) ;
  
    return_val = commit_to_os( lp_disk ) && return_val;
  
+   ped_device_close( lp_disk -> dev );
+ 
    return return_val;
  }
  
gedakc@quad:~$ 


This is similar to a patch to parted-1.9.0 which can be seen at the following link:
http://git.debian.org/?p=parted/parted.git;a=commit;h=ad25892bb995f61b0ddf801ed1f74e0b1e7390ce


Then I set the program to run over night and checked the results in the morning.

Unfortunately the problem was encountered at iteration 9841, so this change to the code did not solve the problem.
Comment 13 Curtis Gedak 2009-12-23 17:22:17 UTC
Created attachment 150309 [details]
Screen shot of the problem occurring on iteration 4615 on fedora 12

TEST2
=====

To try another approach to solving the problem, I collapsed the function call so that both the commit_to_dev and commit_to_os calls are in the same function.


The change to the original code is as follows:


gedakc@quad:~$ diff -c resize-using-libparted.c resize-using-libparted-test3.c
*** resize-using-libparted.c	2009-12-21 17:59:28.000000000 -0700
--- resize-using-libparted-test3.c	2009-12-22 10:24:07.000000000 -0700
***************
*** 13,25 ****
    /* return PED_EXCEPTION_UNHANDLED; */
  }
  
- int commit_to_os( PedDisk *lp_disk )
- {
-   int return_val = ped_disk_commit_to_os( lp_disk );
- 
-   return return_val;
- }
- 
  int commit( PedDisk *lp_disk )
  {
    /* Try commit to os patch from libparted */
--- 13,18 ----
***************
*** 27,33 ****
  
    int return_val = ped_disk_commit_to_dev( lp_disk ) ;
  
!   return_val = commit_to_os( lp_disk ) && return_val;
  
    ped_device_close( lp_disk -> dev );
  
--- 20,26 ----
  
    int return_val = ped_disk_commit_to_dev( lp_disk ) ;
  
!   return_val = ped_disk_commit_to_os( lp_disk ) && return_val;
  
    ped_device_close( lp_disk -> dev );
  
gedakc@quad:~$ 


Unfortunately the problem was encountered at iteration 4615, so this change to
the code did not solve the problem.


Following are some version numbers from this fedora 12 installation:


[fedora@fedora12 ~]$ uname -a
Linux fedora12 2.6.31.5-127.fc12.i686 #1 SMP Sat Nov 7 21:41:45 EST 2009 i686 i686 i386 GNU/Linux
[fedora@fedora12 ~]$ rpm -qa | egrep -e 'parted|udev'
pyparted-2.1.2-1.fc12.i686
libgudev1-145-12.fc12.i686
udev-145-12.fc12.i686
libudev-145-12.fc12.i686
gparted-0.4.6-1.fc12.i686
parted-1.9.0-17.fc12.i686
system-config-printer-udev-1.1.13-6.fc12.i686
parted-devel-1.9.0-17.fc12.i686
[fedora@fedora12 ~]$
Comment 14 Curtis Gedak 2010-01-01 18:01:46 UTC
Created attachment 150642 [details]
Screen shot of the problem occurring on iteration 8177 with parted-2.1 on fedora 12

Note:  The test in Comment #13 is TEST3.

TEST4
=====

Tests 1, 2, and 3 confirmed that the problem exists on Fedora 12 using parted-1.9.0-17.  The variable in the three tests was that I changed the code to mimic a "commit-to-os" patch found on the fedora site.  These code changes did not prevent the problem from occurring.


In Test 4, I used parted-2.1.  In this situation parted was configured as follows:

     ./configure --without-readline --disable-device-mapper

Unfortunately, the problem of "failure to inform kernel of partition changes" also occurs with parted-2.1.  This can be seen in the attached screen shot which shows the error was encountered on iteration 8177.
Comment 15 Curtis Gedak 2010-01-03 20:35:06 UTC
A request for help with this problem has been posted to the parted-devel mailing list:
http://lists.alioth.debian.org/pipermail/parted-devel/2010-January/003355.html
Comment 16 Curtis Gedak 2010-01-07 19:13:37 UTC
Created attachment 150991 [details]
Screen shot of problem never occurring even after 42 hours and 33046 iterations with SysRescCD-1.3.4

TEST5
=====

For this test I used the System Rescue CD v1.3.4.
http://www.sysresccd.org/Main_Page

SysRescCD is based on Gentoo.  Version 1.3.4 uses:

kernel-2.6.31.9 (with btrfs update from 2.6.32)
parted-1.9.0-17 (src from fedora.  Also patch for msftres bug).
gparted-0.5.0
udev-146-r1

The original test script and C code was used.  After over 42 hours and 33046 iterations I suspended the test because the problem never did occur.

Please note that the HAL daemon is not running on the SysRescCD.

Following is a query of some package information from SysRescCD:

root@sysresccd /root % uname -a
Linux sysresccd 2.6.31.09-std134 #1 SMP Mon Dec 21 18:42:55 UTC 2009 i686
Intel(R) Core(TM)2 Quad CPU @ 2.40GHz GenuineIntel GNU/Linux
root@sysresccd /root % equery list parted
[ Searching for package 'parted' in all categories among: ]
 * installed packages
 [I--] [M ] dev-python/pyparted-1.8.9 (0)
 [I--] [M~] sys-apps/parted-1.9.0 (0)
 [I--] [M ] sys-block/gparted-0.5.0 (0)
root@sysresccd /root % equery list udev       
[ Searching for package 'udev' in all categories among: ]
 * installed packages
 [I--] [M ] sys-fs/udev-146-r1 (0)
root@sysresccd /root % 


The question in my mind now is "What is the key difference between this Gentoo distribution and Fedora 12 such that the problem does not occur on SysRescCD?"

Petr Uzel has a theory that the problem might not occur when the HAL daemon is off.  I will explore this in the next test.
Comment 17 Curtis Gedak 2010-01-07 20:01:48 UTC
Created attachment 150994 [details]
Screen shot of the problem occurring on iteration 244 on fedora 12 (HAL not running)

TEST6
=====

For this test I shut down the HAL daemon and went back to parted 1.9.0 on fedora 12.


I re-installed the fedora parted-devel package with:

     yum install parted-devel

I noticed that a newer version of parted-devel was installed as can be seen with the following commands and output:

[fedora@fedora12 ~]$ uname -a
Linux fedora12 2.6.31.5-127.fc12.i686 #1 SMP Sat Nov 7 21:41:45 EST 2009 i686 i6
86 i386 GNU/Linux
[fedora@fedora12 ~]$ rpm -qa | egrep -e 'parted|udev'
pyparted-2.1.2-1.fc12.i686
libgudev1-145-12.fc12.i686
udev-145-12.fc12.i686
libudev-145-12.fc12.i686
parted-devel-1.9.0-17.2.fc12.i686
gparted-0.4.6-1.fc12.i686
parted-1.9.0-17.2.fc12.i686
system-config-printer-udev-1.1.13-6.fc12.i686
[fedora@fedora12 ~]$ 

parted-devel is now 1.9.0-17.2 (the .2 suffix is new).


The HAL daemon was shut down with the following:

     /etc/init.d/haldaemon stop
     pkill hald

After this the command "ps -ef | grep hal" showed no processes running.


Then I recompiled the original test C code and ran the test.  Unfortunately the problem occurred on iteration 244.

My conclusion from this test is that the problem is not caused by the HAL daemon.


One difference that piques my curiousity is that SysRescCD uses udev-146-r1, whereas fedora 12 uses udev-145-12.
Still, from comment #1, the GParted Live CD (based on Debian Sid) uses a newer udev-148 and the problem did occur with GParted Live.
Comment 18 Curtis Gedak 2010-01-09 16:59:32 UTC
Two users have reported in the GParted Forum that they have resized NTFS file systems and have experienced this problem with System Rescue CD v1.3.4.
http://gparted-forum.surf4.info/viewtopic.php?id=13932

Hence it would appear that the problem can even occur with sysresccd-1.3.4.
Comment 19 Curtis Gedak 2010-01-09 18:00:27 UTC
Created attachment 151097 [details]
Screen shot of the problem occurring on iteration 241 on ubuntu 9.10

TEST7
=====

Earlier, in comment #4, I had indicated that the problem did not occur with Ubuntu 9.10 as updated with patches on Dec. 12, 2009.

Today (Jan. 9, 2010), I updated the distribution with current patches and re-ran my tests.  The problem with "failure to inform kernel of partition change" occurred on iteration 241.

For this test the following was in use:
linux-2.6.31-17
parted-1.9.0-14
udev-147~-6.1


My conclusion from the testing to date is that the problem occurs with all new GNU/Linux distributions (at least those using linux-2.6.31+ and udev-145+).
Comment 20 Curtis Gedak 2010-01-15 23:21:54 UTC
This problem might be related to a change in behaviour in udev with version 138:
http://lists.alioth.debian.org/pipermail/parted-devel/2010-January/003369.html

I have had some success with modifying the gparted code for commit_to_os() in GParted_Core.cc.  By adding either a call to "blockdev --rereadpt", or adding a sleep(1) and another call to ped_disk_commit_to_os(), I have been successful with informing the kernel of partition changes.

As such I have committed the latter solution to the GNOME git repository.
For the relevant git commit, please refer to the following link:
http://git.gnome.org/browse/gparted/commit/?id=bf86fd3f9ceb0096dfe87a8c9a38403c13b13f00

It is interesting to note that if I added only another call to ped_disk_commit_to_os() and did not use the call to sleep(1), then I continued to experience "failure to inform kernel of partition changes" errors.

The above change to git should serve as a work around to the problem as experienced by GParted users.


Next I will also try implementing a similar change to the function call _kernel_reread_part_table in the file libparted/arch/linux.c.  Also interesting is that this function has a variable "retry_count" set to 5.  This suggests to me that perhaps informing the kernel of partition changes with an ioctl() call has been a problem in the past.
Comment 21 Curtis Gedak 2010-01-16 16:04:00 UTC
Created attachment 151540 [details]
Screen shot of the problem occurring on iteration 8180 on fedora 12

TEST8
=====

For this test I started used parted-1.9.0-14, which can be found at the following link:
http://koji.fedoraproject.org/koji/buildinfo?buildID=129982

This was to confirm that the problem exists with parted-1.9.0-14.  The problem occurred on iteration 8180.

My next test will involve a test patch for parted to address this problem.
Comment 22 Curtis Gedak 2010-01-23 23:45:24 UTC
Created attachment 152116 [details]
Screen shot of successful completion of 99,999 iterations on fedora 12 using libparted patch

TEST9
=====

By adding the patch listed below, my test was able to successfully complete all 99,999 iterations.  This patch might not be a perfect solution to this problem of "failure to inform kernel of partition changes", but it does significantly reduce the likelihood of encountering the problem.

Basically this patch increases the retry_count, and adds one sleep(1) function call prior to the the last few ioctl() calls.


The following diff output was generated with the command:
$ diff -c libparted/arch/linux.c libparted/arch/linux.c.new

*** libparted/arch/linux.c    2009-12-05 12:23:21.000000000 -0700
--- libparted/arch/linux.c.new    2010-01-16 08:24:55.000000000 -0700
***************
*** 2407,2413 ****
  _kernel_reread_part_table (PedDevice* dev)
  {
          LinuxSpecific*  arch_specific = LINUX_SPECIFIC (dev);
!         int             retry_count = 5;
 
          sync();
          while (ioctl (arch_specific->fd, BLKRRPART)) {
--- 2407,2413 ----
  _kernel_reread_part_table (PedDevice* dev)
  {
          LinuxSpecific*  arch_specific = LINUX_SPECIFIC (dev);
!         int             retry_count = 10;
 
          sync();
          while (ioctl (arch_specific->fd, BLKRRPART)) {
***************
*** 2425,2430 ****
--- 2425,2433 ----
                                  dev->path, strerror (errno), dev->path);
                          return 0;
                  }
+                 /* Pause occasionally to allow system to settle */
+                 if (retry_count % 5 == 0)
+                         sleep(1);
          }
 
          return 1;
Comment 23 Curtis Gedak 2010-01-23 23:46:45 UTC
For those interested, TEST9 took about 7.5 days to complete.
Comment 24 Curtis Gedak 2010-01-27 20:08:10 UTC
Created attachment 152446 [details]
Screen shot of the problem occurring on iteration 989 on fedora 12 with git head of parted

TEST10
------

For this test I used the latest source code from the parted git repository as of January 27, 2010.  This test confirms that the "failure to inform kernel of partition changes" problem exists in the latest development version of parted.

Next I will investigate creating a patch similar in nature to the one I created for parted-1.9.0.
Comment 25 Curtis Gedak 2010-02-02 17:02:12 UTC
Created attachment 152858 [details]
Screen shot of successful completion of 99,999 iterations on fedora 12 using libparted git patch

TEST11
======

By adding the git patch listed below, my test was able to successfully complete all 99,999 iterations.  This patch might not be a perfect solution to this problem of "failure to inform kernel of partition changes", but it does significantly reduce the likelihood of encountering the problem.

Basically this patch increases the retry_count, and adds one sleep(1) function
call prior to the the last few ioctl() calls.

This test took about 5.5 days to complete all 99,999 iterations.

The following diff output was generated with the command:
$ git diff

diff --git a/libparted/arch/linux.c b/libparted/arch/linux.c
index aefe788..1147b1e 100644
--- a/libparted/arch/linux.c
+++ b/libparted/arch/linux.c
@@ -2518,12 +2518,14 @@ static int
 _kernel_reread_part_table (PedDevice* dev)
 {
         LinuxSpecific*  arch_specific = LINUX_SPECIFIC (dev);
-        int             retry_count = 5;
+        int             retry_count = 9;
 
         sync();
         while (ioctl (arch_specific->fd, BLKRRPART)) {
                 retry_count--;
                 sync();
+                if (retry_count == 3)
+                        sleep(1); /* Pause to allow system to settle */
                 if (!retry_count) {
                         ped_exception_throw (
                                 PED_EXCEPTION_WARNING,
Comment 26 Curtis Gedak 2010-02-02 17:42:47 UTC
Created attachment 152863 [details] [review]
Patch for master branch of parted git repository as of Feb 2, 2010
Comment 27 Curtis Gedak 2010-02-02 18:08:03 UTC
As per comment #20, a work around was been committed to the GParted GNOME git repository and was included in the GParted 0.5.1 release.

Closing this bug.
Comment 28 Denis 2010-02-05 19:58:28 UTC
*** Bug 609097 has been marked as a duplicate of this bug. ***
Comment 29 Curtis Gedak 2010-02-23 21:56:56 UTC
*** Bug 596415 has been marked as a duplicate of this bug. ***
Comment 30 Curtis Gedak 2010-02-23 22:31:34 UTC
The patch to libparted listed in comment #25 has been committed to the parted project git repository.  It can be seen at the following link:
http://git.debian.org/?p=parted/parted.git;a=commit;h=0a21f0b7ed7ff0e536a5c30dfe1910c33d2ca243

This patch is to be included in the upcoming Parted 2.2 release.