How to expand /[root] with adjacent (preceding) free space

About 4 months ago, I setup a Win 10/Mint 19 dual-boot and haven't booted into Windows since! Unfortunately, my 30GB root partition is filling up (65% used), so I'd like to expand it.

As you can see below, I carved out another 19GB of free space between /dev/sdc1 and /dev/sdc2 that is in front of the root partition. Here's a visual, in case it helps (also attached):

https://i.ibb.co/ScBMGT4/root-expand...located-01.png

Here's my full system partitioning:

/dev/sda [WDC SATA II, 1TB, GPT Partitioning]

• /dev/sda1 (Microsoft reserved partition, 134MB)

• /dev/sda2 (V: Misc, 950GB)

• /dev/sda3 (/media/cjspizz/Mint Snapshots, 50GB)

/dev/sdb [Kingston SSD, 120GB, MBR Partitioning]

• /dev/sdb1 (System Reserved, 367MB) [boot]

• /dev/sdb2 (C: Windows 10, 119GB)

• /dev/sdb3 (Win Recovery, 472MB)

• free space (1.5MB)

/dev/sdc [Seagate SATA III 2TB, MBR Partitioning]

• /dev/sdc1 (S: Data, 1.8TB)

• free space (19GB)

• /dev/sdc2 (/[root], 31GB)

• /dev/sdc3 (swap, 8.2GB)

• /dev/sdc4 (/home, 176GB)

I booted into a Linux Mint Live USB stick to use GParted to slide the left edge of /dev/sdc2 leftward over the new adjacent free space. When I clicked to apply the changes, I got the following warning:

Moving a partition might cause your operating system to fail to boot. You have queued an operation to move the start sector of partition /dev/sdc2. Failure to boot is most likely to occur if you move the GNU/Linux partition containing /boot, or if you move the Windows system partition C:.

I cancelled the operation.

Then I slid the whole /dev/sdc2 partition left, so it would be in front of the adjacent free space. Then slid the right edge of /dev/sdc2 rightward over the adjacent free space but got the same warning.

I'm thinking I can ignore the warning, because the boot sector (and grub2) are in /dev/sdb1. But I didn't want to risk it.

I need help figuring out how to get this done (or whether it's even possible). Any and all advice is appreciated. Thanks!

well for one you put or that install did that stupid put the swap in the middle of the root and /home/

first I'd delete whatever is in /tmp if more room is still needed, then, I'd log in root user, gets you off the home partition, delete swap, move home over almost all of the way up against the root, leaving some for root partition, then move the back end of home to make that left over for swap, (id not even have a swap), but....

then open fstab and update it to reflect the new UUIDs mount -a and watch a movie while its moving things around. when the movie is done or gparted is done then I'd reboot into a usb Linux live OS with gparted, then move that bit I left for root into root then reboot again into my system.

or just do all of it using a Live USB Linux OS with gparted.

Ignore the warnings because it does not know what you are doing, I just did this same thing, basically, well I deleted a bunch of partitions in usb OS and reinstalled 1 distro so far, I was hitting ignore all the way through the process, and now I am up and running again with a fresh install...

because the boot sector (and grub2) are in /dev/sdb1.

If the information you posted is correct, sdb1 would be a windows filesystem and I doubt that Grub files would be there. Your post indicates that drive (sdb) is an msdos/MBR drive. If you had an EFI install, you would have some Mint EFI files and grub files on a vfat partition but you don't seem to have that. Windows requires EFI on a GPT drive. Post the output of the command: sudo parted -l for more detailed information.

The warning message you see is almost always shown when moving a partition to the left as you will be moving boot files. Probably the safest thing to do is after you move to the left with GParted is to use chroot to get into the Mint partition and run: sudo update-grub.

When you boot, are you booting Mint from the windows bootloader or windows from the Mint/Grub bootloader? Is your 1TB drive (sda) just a data partition? Do you know which drive has Grub in the MBR?

if you are pushing the root to the left to take up that space and mbr boot, I've done this before as well, I was surprised how easy it was, I shrank my windows partition on the right some, and moved root over to the left. rebooted, as the partitions where not destroyed and recreated, the UUID stays the same. I had no issues with it.

Originally Posted by yancek When you boot, are you booting Mint from the windows bootloader or windows from the Mint/Grub bootloader?

The Mint/Grub bootloader.

Originally Posted by yancek Is your 1TB drive (sda) just a data partition?

Yes.

Originally Posted by yancek Do you know which drive has Grub in the MBR?

No.

Originally Posted by yancek Post the output of the command: sudo parted -l for more detailed information.

Model: ATA WDC WD1001FALS-0 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 17.4kB 134MB 134MB Microsoft reserved partition msftres
2 135MB 950GB 950GB ntfs Basic data partition msftdata
3 950GB 1000GB 50.0GB ext4 Mint Snapshots


Model: ATA KINGSTON SV300S3 (scsi)
Disk /dev/sdb: 120GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 1049kB 368MB 367MB primary ntfs boot
2 368MB 120GB 119GB primary ntfs
3 120GB 120GB 472MB primary ntfs diag


Model: ATA ST2000DM001-1ER1 (scsi)
Disk /dev/sdc: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 1049kB 1767GB 1767GB primary ntfs
2 1786GB 1816GB 30.7GB primary ext4
3 1816GB 1825GB 8193MB primary linux-swap(v1)
4 1825GB 2000GB 176GB primary ext4

Ignore the warning. It was particularly relevant with classic grub if you were moving /boot. Not really an issue these days for Linux - Windows on the other hand ... :shrug: (I know, not an issue here).

gparted liveCD is excellent for these things - moving left is always a concern (and slow) because all the filesystem metadata has to move. I prefer to slide the entire partition first (as you mentioned later) then apply that. Let it finish, then expand it to the right - apply that, it will be quick.
At that point you can destroy the backup you took before you started.

As an aside, 30G should be plenty for the root - find out what the underlying problem is with space consumption rather than attacking the symptom.

Originally Posted by syg00 As an aside, 30G should be plenty for the root - find out what the underlying problem is with space consumption rather than attacking the symptom.

That's what I thought! All the research I did before the install said 20GB was plenty, and anything extra was icing on the cake. I figured 30GBs might even be excessive but went for it any way.

Any suggestions for figuring out what's going on in root? Any well-known culprits for clogging root?

First suspect with current Mint would be snapshots, but you seem to have that covered. Try this and see if it give any hints - will take a while, just let it run.

sudo du / -xh | sort -hr | head -n 20

Originally Posted by cjspizz Then I slid the whole /dev/sdc2 partition left, so it would be in front of the adjacent free space. Then slid the right edge of /dev/sdc2 rightward over the adjacent free space but got the same warning. I'm thinking I can ignore the warning, because the boot sector (and grub2) are in /dev/sdb1. But I didn't want to risk it.

And well you did.
The only way moving the START of a partition is by using a full backup and restore:

1. Backup your complete root (/) partition 2. From the live fs remove /dev/sdc2 partition 3. Create a new sdc2 partition, incorporating the free space 4. Make a fs ON that partition 5. Restore the backup'ed data into that partition 6. Optionally, dependant on the boot manager, restore the bootable data 7. Try to reboot TO this new root partition

The problem is that all the "offset" block numbers IN the file system are relative to the first block in that partition (the "super block") and you're moving the start would put that block somewhere in the middle. So a new super block has to be created (with mkfs) and that will empty out the whole partition.

Try it. It works.

Originally Posted by ehartman 4. Make a fs ON that partition

Sorry for the dumb question, but what's "fs"?

Originally Posted by cjspizz Sorry for the dumb question, but what's "fs"?

File System, the organisation of (meta)data on the partition, disk or volume (like the directory structure, some form of "superblock" and allocation info. etc).
Well known fs'es are ext? (ext3 or ext4), btrfs (B-tree fs) or for Windows: fat (file allocation table, comes in several variations) or ntfs (original: Windows/NT fs).
See "man mkfs" for some more information).

I think I'm following what you're saying. Based on my understanding, here's my plan:

1. Boot into Clonezilla live
2. Backup my complete root (/) partition
3. Boot into GParted live
4. Remove /dev/sdc2 partition
5. Create a new sdc2 root partition, incorporating the free space
6. Make a fs on the new sdc2 root partition
7. Boot into Clonezilla live
8. Restore the backed up data into the new sdc2 root partition
9. Try booting into Mint
10. If Mint won't boot, boot into Super Grub2 to fix boot problems
11. Boot into Mint

Does that make sense and follow what you're suggesting? Is there anything else I'm missing?

Originally Posted by cjspizz About 4 months ago, I setup a Win 10/Mint 19 dual-boot and haven't booted into Windows since! Unfortunately, my 30GB root partition is filling up (65% used), so I'd like to expand it.

You could mount that partition somewhere on the root tree where it could be useful, but that doesn't expand root in general, it just adds that space into the root tree.

If you have a good overview of the uses space on root, you could add that 19gb of free space into somewhere in the root tree where it can be well used and move the data from the root partition to the same area of the tree after mounting that partition to the same place under the root tree where it can be useful.

Just remember to edit the fstab also.

Let's say somewhere on /usr could be useful.