Through a series of oversights I installed a fresh Ubuntu 18.04 installation on a machine that had previously had a Ubuntu 16.04 and Windows 7 dual boot. After using the machine, I have now found this out. I managed to de-allocate the windows partitions which resulted in two non-contiguous unallocated spaces on my 250GB drive with the Ubuntu installation and its swap in the middle.

Using a Ubuntu live system, from a bootable USB, I can now interact with the partitions using gparted. I am attempting to resize the Ubuntu partition.

enter image description here

Starting from the left I am attempting to resize the Ubuntu partition with all of the unallocated space. The center shows the alterations, and the right shows an error from gparted.

From how I understand this error, the actions above would result in the start of the boot sector moving on the drive in such a way that the boot loader would not know where the boot sector starts (thus bricking the installation).

What is the proper way to resize the Ubuntu partition so that the ~190GB of unallocated space is now usable?

EDIT: This SO-QA reads to me that this is just a blanket statement and I should be fine, especially that I only have the single installation.

1 Answer 1


Backup important data.

  1. Move/Resize

    • Boot into Live USB or DVD drive. Open Gparted.

    • Move the swap partition to the end.

    • Now resize the ext4 partition to cover all the space.

You may get a warning "Moving a partition might cause your operating system to fail to boot"

This is just a blanket statement. This process might take quite some time don't interrupt also make sure that there is no power failure during this time.** If in doubt don't go for it.**

  1. The following steps can be done now or if there is a problem in booting after resize process. (I had to do this once.)

    • Mount the ext4 partition on /mnt

      sudo mount /dev/nvme0n1p7 /mnt
    • Check the UUID of partitions. Run

      sudo blkid
    • Check the UUID in /etc/fstab

      sudo -H gedit /mnt/etc/fstab
    • The UUIDs should correspond. If not, change in fstab and save.

    • To install and update grub. Mount bind some folders

      for i in /dev /dev/pts /proc /sys; do sudo mount --bind $i /mnt$i; done
    • Chroot /mnt

      sudo chroot /mnt
    • Install grub

      sudo grub-install /dev/nvme0n1
    • Update grub

      sudo update-grub2
    • Un mount all

      exit && for i in /sys /proc /dev/pts /dev; do sudo umount /mnt$i; done && sudo umount -l /mnt
    • Reboot.

  • Thank you for the answer, but you could you provide just a bit of background on what these steps are doing? For my peace of mind and it'll make a marginally nicer answer.
    – KDecker
    Apr 9, 2019 at 18:46
  • I meant more information with respect to the steps. Why turn the swap off, why check the UUIDs, etc.
    – KDecker
    Apr 9, 2019 at 18:53
  • Swapoff reminded me that live boot is needed to resize "/" partition.
    – Vijay
    Apr 9, 2019 at 20:10
  • So my two questions are still. If the UUIDs did not match (they did), you say "change in fstab", does that mean literally edit the fstab file in gedit so they match? Next, is the second set of operations to be ran only if UUIDs did not match, or are they to be ran regardless? What are they doing?
    – KDecker
    Apr 10, 2019 at 12:02
  • 1. Normally the UUIDs don't change but in case there is some fault in the process and the UUIDs change you have to edit the fstab. Happened to me once. If they don't mach the machine will not boot. 2. If you extend the root partition the bootloader may be overwritten in the process (not common) so no harm in installing and updating grub. However you can try without these steps and if it boots normally it's OK if not you can do these step by booting in Live USB/DVD. (edited accordingly)
    – Vijay
    Apr 10, 2019 at 12:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .