GNOME Bugzilla – Bug 661744
libparted "Can't have overlapping partitions." after successful move+resize?!
Last modified: 2012-04-09 20:14:24 UTC
Created attachment 198996 [details] log partition layout before: /dev/sda1 (fat32, 13.84 GiB) /dev/sda2 (ntfs, 95.39 GiB) and some logical partion with another ntfs ==>> Delete /dev/sda1 (fat32, 13.84 GiB) from /dev/sda Move /dev/sda2 to the left and grow it from 95.39 GiB to 109.23 GiB ==>> real resize ( ERROR ) during "ntfsresize -P --force --force /dev/sda2" see log.
Would you be able to provide 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.
after the partially failed move+resize procedure from above i restarted the computer. windows, being on sda2, works fine. then i entered gparted again to remove the trailing extended partition and its contained logical partition. instead i created a new primary partition, also including the free space after sda2 which has not been added to sda2 in the initial move+resize run. reboot, windows works fine. now i entered gparted again to get the infos for you: user@debian:/media$ sudo parted /dev/sda unit s print Model: ATA M4-CT128M4SSD2 (scsi) Disk /dev/sda: 250069680s Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 2 16384s 200073828s 200057445s primary ntfs boot 1 200075264s 250068991s 49993728s primary ntfs user@debian:~$ sudo fdisk -l -u /dev/sda Disk /dev/sda: 128.0 GB, 128035676160 bytes 255 heads, 63 sectors/track, 15566 cylinders, total 250069680 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: 0xe9739dd2 Device Boot Start End Blocks Id System /dev/sda1 200075264 250068991 24996864 7 HPFS/NTFS/exFAT /dev/sda2 * 16384 200073828 100028722+ 7 HPFS/NTFS/exFAT Partition table entries are not in disk order
This is a puzzling situation. So far I have been unable to reproduce the problem you encountered. Is your computer functional now? If not what problems are you experiencing?
the only thing that has ever failed was apparently the resize operation - although the simulation has worked? the OS partition (sda2) has always worked. the only unusual situtation i havent really seen before is that the partition table then started with sda2 (instead of sda1, old sda1 being deleted before move+resize). i would have assumed sda2 being "renamed" to sda1 after sda1 deletion and sda2 move? thus also the curious situation that partitions are now not in order, after a new sda1 being created - but everything is working fine. months before i had a similar problem with a resize failing (different disk setup / computer / ..), no more data available though. so there seems to be some issue with the resize... sadly i have also no more possibility to try to reproduce this bug (PC+disk already in production).
(In reply to comment #4) > the only unusual situtation i havent really seen before is that the partition > table then started with sda2 (instead of sda1, old sda1 being deleted before > move+resize). i would have assumed sda2 being "renamed" to sda1 after sda1 > deletion and sda2 move? Primary partitions are given a dedicated slot in the partition table. Hence deleting or adding a partition does not change the partition number for primary partitions. Logical partitions are chained together. If you remove one partition from the chain, all of the later partitions experience a partition number decrease of one. > months before i had a similar problem with a resize failing (different disk > setup / computer / ..), no more data available though. so there seems to be > some issue with the resize... This situation is strange because the resize appears to have worked, but returned an error code. There has been recent development with ntfsprogs, now ntfs-3g that might have impacted error handling. However since I am unable to reproduce the situation it is very difficult to determine the root cause.
Curtis, it looks like the error happened when trying to expand the partition, so it wasn't expanded. Unfortunately, the details log only shows the old start/end/length and not the new values gparted was attempting to apply when the error happened. It is also unclear whether that is the operation that generated the libparted error. Perhaps the details logging can be expanded to show this information in the future? I wonder if this was caused by an alignment issue? Maybe the partition was not aligned on a 1MiB boundary before, and when trying to expand the partition, gparted tried to align to a 1MiB boundary, which moved the end point to the right on top of the other partition.
(In reply to comment #6) > Curtis, it looks like the error happened when trying to expand the partition, > so it wasn't expanded. Unfortunately, the details log only shows the old > start/end/length and not the new values gparted was attempting to apply when > the error happened. It is also unclear whether that is the operation that > generated the libparted error. Perhaps the details logging can be expanded to > show this information in the future? More logging would certainly be helpful in this area to try to pinpoint the problem. > I wonder if this was caused by an alignment issue? Maybe the partition was not > aligned on a 1MiB boundary before, and when trying to expand the partition, > gparted tried to align to a 1MiB boundary, which moved the end point to the > right on top of the other partition. I am fairly certain that this is an alignment issue problem that GParted is not handling properly. With MiB alignment, GParted instructs libparted to use the alignment values specified by GParted. In some situations, such as this report, the alignment values GParted uses must be overlapping another existing partition. The alignment values come from the GUI, so perhaps there is some rounding or floor/ceiling function that is incorrect.
> More logging would certainly be helpful in this area to try to > pinpoint the problem. In an effort to address this one issue, the following enhancement has been committed to the GNOME git repository: Add requested partition details to log when resize/move fails http://git.gnome.org/browse/gparted/commit/?id=57ee0a1638b940de7f06e42affd426efd2defeac I will try again to reproduce the problem. Note: I have moved this report to the component "application" because it should not be limited to the livecd.
Thinking more about this problem I have discovered something unusual. There are only two partitions on the drive at the start. One is deleted and the remaining partition is moved and grown. So with only one partition on the drive how can we get the error: "Can't have overlapping partitions."? Is this a bug in libparted???
Thanks to Phillip for reminding me that there is more information in this report I forgot about. Specifically in comment #2 about the previously existing extended partition and logical partitions. That could be where the overlap occurred. Things to check: a) GParted_Core::insert_unallocated() method for determining free space on disks with partitions out of order. b) GParted_Core::snap_to_mebibyte() consider adding possible end boundary overlap check.
Created attachment 210715 [details] GParted with partitions in reverse order Follow up to comment #10 "Things to check" item "b". Based on some testing, GParted appears to correctly determine the unallocated space between partitions (even those in reverse order). From the screen shot and starting from the beginning of the disk (/dev/sde), the unallocated space is: 3 MiB, 5 MiB, 3 MiB, 2 MiB, (and 2 MiB within the extended partition sde1) The output from parted is as follows: $ sudo parted /dev/sde unit s print Model: Linux scsi_debug (scsi) Disk /dev/sde: 49152s Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 4 6144s 10239s 4096s primary ext2 3 20480s 26623s 6144s primary ext3 2 32768s 40959s 8192s primary ext4 1 45056s 49151s 4096s extended $ This yields the same unallocated space from the front of disk as being: 3 MiB, 5 MiB, 3 MiB, 2 MiB, (and 2 MiB within the extended partition sde1) Hence GParted appears to be handling unallocated space correctly. This leads me to believe that it would be prudent to add an end boundary overlap check in GParted_Core::snap_to_mebibyte().
From the gparted_details.htm log file, the overlap occurred with primary partition sda2 so the overlap must have occurred with another primary or extended partition. After thinking on this problem for a while, my thoughts are that somehow the problem arose due to partitions aligned to boundaries other than MiB in combination with the size of a partition being rounded up in the GUI resizer. Start sectors and the size of the partition are tracked exactly in the GUI resizer. This leads me to believe that the only place the overlap could have occurred is with the end sector because this value is calculated. In an attempt to prevent this problem in the future, I have added a check for partition overlaps with the end sector. The following two enhancements have been committed to the git repository for inclusion in the next release of GParted: Rework align to MiB adjustments to end sector of partition http://git.gnome.org/browse/gparted/commit/?id=1c47c17a476ade49ea3b8c72c7c84700b0cd08bd Ensure Align to MiB does not overlap following partition (#661744) http://git.gnome.org/browse/gparted/commit/?id=c56d0df8aee1d7bdaf88e3cafa5ae0dc9433e582
The enhancements for this bug report have been included in GParted 0.12.1 released on April 9, 2012.