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 778700 - Unable to grow partition even though unallocated space is adjacent
Unable to grow partition even though unallocated space is adjacent
Status: RESOLVED FIXED
Product: gparted
Classification: Other
Component: application
0.28.0
Other Linux
: Normal normal
: ---
Assigned To: gparted maintainers alias
gparted maintainers alias
Depends on:
Blocks:
 
 
Reported: 2017-02-15 17:34 UTC by Curtis Gedak
Modified: 2017-02-17 23:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot - unable to grow with GParted Live 0.28.0-1-i686 (85.89 KB, image/png)
2017-02-15 17:34 UTC, Curtis Gedak
  Details
Screenshot - able to grow with GParted Live 0.27.0-1-i686 (82.78 KB, image/png)
2017-02-15 17:36 UTC, Curtis Gedak
  Details
Fix unable to grow primary patch (v1) (1.73 KB, patch)
2017-02-16 17:20 UTC, Curtis Gedak
none Details | Review
GParted 0.28.0 - Resize of primary when extended exists incorrectly shows unallocated space (105.66 KB, image/png)
2017-02-16 17:39 UTC, Curtis Gedak
  Details

Description Curtis Gedak 2017-02-15 17:34:04 UTC
Created attachment 345856 [details]
Screenshot - unable to grow with GParted Live 0.28.0-1-i686

There appears to be a regression with GParted version 0.28.0.  More specifically it is not possible to grow an ext4 primary partition that has unallocated space available immediately after the partition.  GParted 0.27.0 does not exhibit this issue.

The steps to recreate are as follows (note that a virtual machine is not required:

 1. Create VMware VM with 8.4 GB hard disk (/dev/sdb)

 2. Boot VM using gparted-live-0.28.0-1-i686.iso

 3. Open a terminal window

 4. Create partitions

    $ sudo parted /dev/sdb
    (parted) mklabel msdos
    (parted) mkpart primary ext4 1049kb 2327MB
      --- ignore warning about not properly aligned ---
    (parted) mkpart extended 7517MB 8589MB
    (parted) mkpart logical  7517MB 8589MB
      --- ignore warning about not properly aligned ---
    (parted) quit

 5. Format partitions

    $ sudo mkfs.ext4 /dev/sdb1
    $ sudo mkswap /dev/sdb5

 6. Print out partition layout

    $ sudo parted -s /dev/sdb print
    Model: VMware, VMware Virtual S (scsi)
    Disk /dev/sdb: 9019MB
    Sector size (logical/physical): 512B/512B
    Partition Table: msdos
    Disk Flags:

    Number  Start   End     Size    Type      File system     Flags
     1      1049kB  2327MB  2326MB  primary   ext4
     2      7517MB  8589MB  1072MB  extended                  lba
     5      7517MB  8589MB  1072MB  logical   linux-swap(v1)


 7. Run GParted and try to grow sdb1 primary partition.

    Problem Confirmed!

    Unable to grow sdb1 primary partition because no unallocated
    space shown after partition in Resize/Move dialog window.
    See attached screenshot.

Thanks go to Steven Shiau for discovering this problem.
Comment 1 Curtis Gedak 2017-02-15 17:36:15 UTC
Created attachment 345858 [details]
Screenshot - able to grow with GParted Live 0.27.0-1-i686

GParted version 0.27.0 works as expected when trying to grow the same ext4 primary partition.  See screenshot.

Curtis
Comment 2 Mike Fleetwood 2017-02-15 18:10:53 UTC
Hi Curtis,

I have *QUICKLY* git bisected it to this commit.
    Create and use general find_extended_partition() function
    aa98107706405fe0a80d4fd1a1ddb0838518ea7f
You should confirm by building the previous commit and this commit and
testing them.

So far the characteristics I have seen are:
* primary partition with space before extended partition
* any file system
* Resize/move dialog shows the primary partition incorrectly so can't
  move it

Mike
Comment 3 Curtis Gedak 2017-02-15 21:04:37 UTC
Hi Mike,

Thanks for isolating the commit that introduced the regression.  I have tried building the commit mentioned in comment #2 and the previous commit and I have confirmed that this is where the regression occurred.

From a quick glance, the code in the commit looks okay, but from testing there must be something that isn't quite the same as the code it replaced.

Curtis
Comment 4 Curtis Gedak 2017-02-16 17:20:54 UTC
Created attachment 345970 [details] [review]
Fix unable to grow primary patch (v1)

Hi Mike,

I was able to track the regression down to a loss of some logic that checked for a logical partition when activating resize.  Restoration of this logic appears to resolve the issue.

Curtis
Comment 5 Curtis Gedak 2017-02-16 17:39:44 UTC
Created attachment 345978 [details]
GParted 0.28.0 - Resize of primary when extended exists incorrectly shows unallocated space

In my testing I discovered that the regression appears to affect resizing all primary partitions if there was an extended partition in the partition table.  More specifically free space may be incorrectly shown to be left of the partition when in actuality it is on the right.  See attached screen shot.

Resizing of logical partitions does not appear to have been affected by the regression.
Comment 6 Mike Fleetwood 2017-02-17 12:45:10 UTC
Hi Curtis,


Without checking email I went ahead and produced the same fix as you.
Anyway as you produced your fix first you get to have your fix
committed.


For the record here is the detailed description of what the code is
doing and why the change broke it.

    Win_GParted::activate_resize() passes the Partition object and the
    containing PartitionVector object to the resize move dialog so that
    it can find the unallocated space Partition objects surrounding the
    partition and correctly present the resize move constraints for the
    partition.  For primary and extended partitions the containing
    PartitionVector object is just the that pointed to by the current
    display_partitions_ptr.  For logical partitions the containing
    PartitionVector object is the one attached to the extended partition
    and needs finding.

    The commit mentioned in comment #2 above the the logic so that even
    when resizing/moving primary or extended partitions the
    PartitionVector object containing the logical partitions was passed
    to the dialog.  Fix the logic so that only when resizing/moving
    logical partitions is the PartitionVector object containing the
    logical partitions passed to the dialog.


The following commit has been pushed to the GIT repo for inclusion in
the next release of GParted.

Restore ability to grow primary w/unallocated space before extended (#778700)
https://git.gnome.org/browse/gparted/commit/?id=4a0931c50dbeed08ed1430a72079ebc9ddb4dc45


Mike
Comment 7 Curtis Gedak 2017-02-17 23:11:38 UTC
This enhancement was included in the GParted 0.28.1 release on February 17, 2017.