Sorry for the Windows screenshot, I’m currently dual booted into Windows for work. But running out of space on Windows partition, so it’s kind of urgent!
I want to grow the Windows system partition (the 2nd one) to give it more room. I would shrink the “Fast drive” partition to do this. (Using Gparted in a live boot)
This would cause my 2 Linux boot and system partitions (the 3rd and 4th ones) to be shifted down.
I’ve killed my dual boot before with something like this, but I think I was moving / restoring partitions. But this time I would simply be sliding / shifting the Linux boot & system partitions down. Could this potentially ruin the dual boot that Endeavour OS has set up?
Any sort of disk manipulation, resizing and moving partitions is potentially prone to data loss or corruption. Not that it will happen always but it may happen.
Back up whatever personal data that is of value to you before attempting any such operations.
What you have in mind entails the following steps in practice:
Shrinking the (F) drive (NTFS, best to be done from within Windows). You will now have some unallocated space to the right of the (F) drive.
Move (F) drive to right.
Move EnOS’ system partition to the right.
Move EnOS’ ESP to the right.
Now you will have that unallocated space to the right of your Windows partition. Resize the partition to the right to fill up the unallocated space.
If offloading some personal data from (C) to (F) partition is an option, I would personally opt for such a course of action to free up some space in (C).
Also, you could use Windows own disk cleanup utility to free up some disk space. Depending on the particular case, it could sometimes free up quite some GBs of space.
More, make sure you have a live EnOS’ usb to be able to rescue/repair your system if worst comes to worst.
Feel free to ask any questions in case of doubt. If I am not able to answer, I am sure many more knowledgeable forum members will be.
Thanks man. What you described is exactly what I’d do - I was just wondering if the “sliding” of a partition would cause problems, like, does a boot menu refer to the exact byte position on the drive or is it higher level than that, and it just refers to the partition by its name and there should be no issue with this?
I was trying to clean up space on C: there’s no personal data or even programs installed there, it’s supposed to be just Windows, and whatever stuff programs put there without an option - like I got Spotify to store its cache elsewhere, but those damn Visual Studio type installations that dump gigabytes of stuff onto your system drive without asking are the real issue. I could junction the folders but I’m getting tired of managing that space and just wanted to give it more space and be done with it.
/dev/nvme0n1p1: LABEL_FATBOOT=“ESP” LABEL=“ESP” UUID=“A6A8-CF20” BLOCK_SIZE=“512” TYPE=“vfat” PARTLABEL=“EFI System Partition” PARTUUID=“95e34155-35a8-4887-93d8-d4a6d7474b75”
The PARTIUUID shouldn’t change even if you format a partition ( you’ll just lose the data on it ).
You could, if you want, edit your fstab and use PARTUUID= instead ofUUID=.
At any rate, assuming the worse case scenario, restoring the bootloader should be feasible by chrooting into the system from the live usb, given everything else is intact.
).