1

I work under Linux with a 500GB GPT internal storage device, partitioned, so /boot, / (root), /var and /home are in separate ext4 volumes. For historical reasons (it used to be a dual Linux-Linux mount system), the device has now a lot of interspersed space between mounted volumes currently in use. That space is allocated (from before) and still contains a /boot partition belonging to the second, now derelict Lx OS. The dual boot menu still shows a choice between two systems, but one of them is largely gone apart from its /boot partition. I consider that space wasted and want to reclaim it.

Using diskson Linux, the current partitioning looks like: here(What's mounted is shown with a black triangle.) In addition to the volumes already mentioned above, and to their left on the disks image, you can see the EFI FAT partition (leftmost, as you'd expect), the swap space and lots of allocated but never mounted space.

Everything boots and works fine and I have a backup of both my data and of the complete partition layout, the latter obtained with # sfdisk -d /dev/nveme0n1 > partition-layout.dump.

I'd like to move both the mounted /boot and / (root) to the left of the swap space and re-allocate the never mounted space to var and /home... I don't plan to touch either GPT headers of the device, or the EFI FAT volume for that matter.

I have used GParted before on MBR volumes with legacy BIOS boot, but never in EFI/GPT environments. Could moving /boot compromise the boot-loading routine and make my volume not bootable ? If so, what should I be prepared to do, rebuild the bootloader, re-index partitions, ... more, .. none of the above ?

In particular if I use GParted, will it keep track of new location and update the partition index so bootloader does not choke after repartitioning ?

I am ready for this, but I want to make sure I am not making something downright stupid before I move a muscle. A nudge, help or any advice would be appreciated. If I forgot to include important aspects of the context, I'll be happy to provide more details.

Cheers.

Improve this question
6
  • 1
    Moving partitions around is always a bit risky, so you better be careful and it's good to have backups of everything. Now, with that warning out of the way: the good thing about UEFI and GPT is that no disk data (like boot loaders and stuff) is hidden away outside of partitions in magical, fixed disk sectors. The firmware is able to understand FAT, everything is explicitly in files. You can move around partitions as long as the partition table is in sync with the actual locations of the disk partitions.
    – Johan Myréen
    Commented Aug 23, 2018 at 19:20
  • 1
    You're incorrectly conflating "unmounted space" and "unused space". Your partition map indicates that all of the disk space has been allocated; there is no "unused space". Even though an OS may not use a partition, that area of the disk is still considered allocated and not "unused space". You will have to delete unused partitions in order to create "unused space".
    – sawdust
    Commented Aug 23, 2018 at 19:41
  • @JohanMyréen: yes. Does that mean that moving them around with GParted will keep the partition table up to date, without me having to re-index partitions ? That was the direction of my query...
    – Cbhihe
    Commented Aug 23, 2018 at 19:48
  • GParted is incapable of "moving" one partition to the other side of another partition, as you want to do. In order to move the four partitions (5, 8, 9, 10), you would first have to delete partitions 2,3,4,6,7. Then you could recreate the swap partition, which may cause issues, as the new swap partition may have different partition and UUID numbers.
    – sawdust
    Commented Aug 23, 2018 at 19:52
  • @sawdust: Effectively GParted is not known for its ability to perform leapfrog... I was going to inactivate the swap, erase it, reallocated space to neighboring ext4 volumes, move /boot' and /` as far to the left as the EFI FAT volume will permit, recreate swap after them (with new UUID), extend /home and /var reboot without swap, and finally correct the /etc/fstab entry for the swap's new UUID. Am I missing something ?
    – Cbhihe
    Commented Aug 23, 2018 at 20:08

1 Answer 1

Reset to default
2

[TLDR] (the short version)
The particular configuration of partitions shown in OP makes it impossible not to have to rebuild / restore the bootloader after moving the head end of the /boot partitions about.

[The complete story]
What I did:

  • boot on live-Linux with a bootable USB drive in UEFI mode. (I chose to use Ubuntu 18.04).
    Do mind the fact that Ubuntu and modern NVIDIA discrete graphics do not get along at all. If you have a recent NVIDIA graphics card (recent.. say as of ca. 2017), you will save time if you actually UEFI-boot a live OS without GUI. That means performing the repartitioning on cli and possibly the subsequent restoration of the bootloader too.

  • with GPartEd reclaim partition 2 and MOVE partition 3 (swap) left, so it becomes contiguous with partition 1. Simply "moving" it does not change the partition's UUID. If you erase it and recreate it elsewhere (your call entirely) you will have to later vi into /etc/fstab to modify the corresponding swap's entry's new UUID.

  • move /boot (partition 5) as far left as needed. Moving the head end (i.e. the left limit on OP's graphical representation) of that partition requires that you later restore the bootloader (GRUB2's in my case). Otherwise you will fail to boot. If unlike in the present case /boot and / (root) were on the same partition, moving the head end of / (root) would also require restoring the GRUB bootloader (because it would mean re-indexing the start of the /boot/efi information located in the root partition).
  • move / (root), /var and /home at whim.

The above constitutes the full answer to my original question.

Restoring the booloader is out of scope here, but is well documented, now even for UEFI. Look up this and this for detailed help. Your mileage may vary according to the distro you have, but my advice is: use generic cli instructions as much as you can. They are best documented as in chroot's case for instance, whereas wrappers (again as in chroot's wrappers) may not be. Again, your call.

HTH anyone with doubts similar to those I had.

Improve this answer

You must log in to answer this question.

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