0
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 disks
on Linux, the current partitioning looks like: (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.
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 – 2018-08-23T19:20:30.540
1You'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 – 2018-08-23T19:41:50.547
@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 – 2018-08-23T19:48:59.287
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 – 2018-08-23T19:52:19.410
@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
/homeand
/varreboot without swap, and finally correct the
/etc/fstab` entry for the swap's new UUID. Am I missing something ? – Cbhihe – 2018-08-23T20:08:11.583Your comment about /etc/fstab inspires confidence that you do know what you're doing. Rather than "inactivate the swap" and "reboot without swap", I would simply boot a LiveCD. I'm inclined to agree with @JohanMyréen, but I've only used MBR partitions. Just be prepared for lengthy disk operations. – sawdust – 2018-08-23T20:43:54.623