So, the traditionally adopted means of resizing partitions with GParted is to:

  • Unmount all partitions (so, use a LiveCD)
  • Right-click -> Extend partition
  • Engulf selected partition in a flurry of additional (formerly unallocated) space
  • Move on.

But, what if the unallocated space is not adjacent to /dev/sda6?

How to move a partition to the end in gparted?

1) Extend the rightmost partition so that it engulfs the unallocated space

2) Move the other partition to the end.

3) Shrink the partition that you moved back to it's original size

4) Move on.

But, what if I have 5x as many partitions to QWOP across?

To Mordor I go.

I could:

  • Extend the rightmost partition to engulf ('x' MiB of unallocated space)
  • Shrink the rightmost partition by ('x' MiB)
  • Repeat 4 times
  • Essentially like QWOPping into Mordor

I'm assuming that:

  • If your shrink/expand operation is off by even 1 MiB, your MBR is borked.
  • If you delete any partitions, your MBR is borked.
  • If you have 5x as many partitions, you have ~5x the average bork surface.

Any suggestions? Is there any way to programmatically resize the dev/sda6 partition without drastically increasing the bork surface?

If not, what would you suggest?

Thank you.

Would migrating to LVM be feasible?

  • 2
    Skipping the slightly risky operation of resizing so many adjacent partitioins, have you considered backup up each partition, wiping the disk and then restoring them in the desired order where you could then resize them? – jdh Jan 6 '13 at 17:23
  • Considered? Yes. However, I'm in class tomorrow and require access to a complete development environment (Murphy's Law). Wouldn't the complicated restore operation be just as risky as the aforementioned partition traversal? I'd think so. – Tyler Jan 6 '13 at 17:25
  • 1
    (Your requirement is to be done before tomorrow's class or unable to reach computer with different tools?) The backup is safer, because if anything goes wrong, you'll at least get another chance. One mistake in the repartition (even if its not your fault, but gparted's), then you're hosed permanently. – jdh Jan 6 '13 at 17:31
  • This is true. I have access to Windows, and Mac computers on campus (but, how is this relevant?) My requirement is to be finished the partitioning operation tonight. – Tyler Jan 6 '13 at 17:33

You best bet is to:

  1. Enlarge the extended partition to include the unallocated space
  2. Move the sda7 etc partitions to the end of the disk, one by one, starting by the last one (sda11) and
  3. then extend the sda6 partition in the unallocated space.

I would do it gradually, doing one change at a time to reduce risk to corrupting data.

| improve this answer | |
  • So, expand sda11 by the desired MiB increase for sda6 ('x'), then can I click-and-drag to swap the unallocated segment with sda11? After the positional swap I'd shrink sda11 by 'x', and repeat 5 times? – Tyler Jan 6 '13 at 17:39
  • Not resize but move the sda11 partition first etc. Then resize sda6. – To Do Jan 6 '13 at 17:42
  • This was actually surprisingly easy to accomplish. Thank you for your insight! – Tyler Jan 7 '13 at 4:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.