Unable to decrease size of root partition

Hi, I need to reduce the main root partition size, so that I can get some free space for windows install(work related).
I’ve followed the usual steps via the live usb and gparted (and I’ve done this before on ubuntu-based distros), but I’m unable to reduce the root partition size here. I can increase the partition size, if I delete the swap, but can’t reduce it.
I did the automatic partitioning available via manjaro install, so the partition scheme is the default done by manjaro. Here’s the partition details, they’re in the order boot>root>swap.
O/P of fdisk -l

Disk model: KINGSTON OM8PCP3512F-AI1                
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 9E61EA20-DFC7-A048-AD4A-DFE3FB91FEC4

Device             Start        End   Sectors   Size Type
/dev/nvme0n1p1      4096     618495    614400   300M EFI System
/dev/nvme0n1p2    618496  981751960 981133465 467.8G Linux filesystem
/dev/nvme0n1p3 981751961 1000206899  18454939   8.8G Linux swap

Lemme know what else do I need to provide. I cannot attach screenshots for some reason.

If gparted won’t let you resize the partition ensure it is not mounted.

I checked, none of my ssd partitions were mounted. which is why I could mess with the swap partition.

Hmm - strange - the only thing I can think of then, is filesystem error, but that doesn’t make sense.

Have you tried running a fsck on your root partition - while on the live medium?

fsck /dev/nvme0n1p2

Have you tried KDE partitionmanager?

What filesystem are you using on your root partition?
Please post output of

$ lsblk -f

Well, I didn’t think it’d make much of a difference, anyways, downloading kubuntu iso now. thanks for the suggestion.

Not yet, but I’ll try it if the kde partition manager thing doesn’t work. Just out of curiosity, if my partition was corrupt, wouldn’t my system be crashing?

Surprisingly, its f2fs. I usually use ext4/btrfs.
Here’s the output for lsblk -f:

NAME FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
│                                                                           
├─nvme0n1p1
│    vfat   FAT32 NO_LABEL
│                       AA29-31FC                             299.1M     0% /boot/efi
├─nvme0n1p2
│    f2fs   1.14        4908fa4f-03ee-4582-b1a0-8fe3a400b865  270.9G    42% /
└─nvme0n1p3
     swap   1     swap  42fdb2de-fe92-4111-b678-9ca2805aadca                [SWAP]

According to F2FS - ArchWiki :
Shrinking is not currently supported.

1 Like

Well, that kinda sucks, I guess. Nevertheless, Is there a better/convenient way to convert my filesystem to btrfs, than to wipe everything, and then reinstall my OS, apps, and data from scratch.
Thanks for the ans btw, I’ll mark it as the solution after your reply to this message, coz I’m afraid it might end this discussion otherwise.

I can’t find any online conversion method, so it seems you would have to resort to the tried-and-proven-to-work-with-any-filesystem way using external storage:

  • boot up a live iso
  • create a (backup) filesystem capable of storing permissions with at least the size of data you’re wanting to convert on external storage (ext4 for example via mkfs.ext4)
  • mount the new created backup filesystem (/mnt/backup) and the filesystem-to-be-converted (/mnt/source)
  • do a full system backup via rsync:
# rsync -aAXHv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /mnt/source /mnt/backup
  • unmount /mnt/source
  • re-create another filesystem (of your choice) on your filesystem-to-be-converted (mkfs and friends)
  • mount it as /mnt/target
  • restore the full backup
# rsync -aAXHv --exclude="/lost+found" /mnt/backup /mnt/target
  • edit /mnt/target/etc/fstab (edit: and possibly /etc/defaults/grub) and adjust the UUID for the now “converted” filesystem (get it via blkid or lsblk -f)
  • manjaro-chroot into the newly created installation and update-grub
  • umount /mnt/backup and /mnt/target

Alright, just to confirm that I got it right, I:

  1. Boot into live ISO
  2. create the backup on an external ext4 filesystem
  3. Just format my entire f2fs partition, and create a ext4 partition of reqd. size
  4. copy all the data back.
  5. adjust the uuids in the fstab, update grub, reboot.

So, there’s not an actual re-installation involved, right? Just messing around with the partitions and their data?

Alright, so, for future reference of anyone reading this, the above method didn’t work for me.
The backup was done successfully, and partitions wiped, and restored, all done properly.
But grub seemed to have issues even after updating it via chroot. Reinstalling grub didn’t help either.
I even reinstalled the OS with manual partitions, hoping to restore the root from my backup, doesnt seem to work.
I did check the /etc/fstab and /etc/defaults/grub files each time, to ensure the uuids were correct.

I’m gonna try and restore my timeshift backup now, after another clean install.

TLDR;
Always take timeshift backups.

1 Like

If you want to take another stab at this, please post exact error messages from grub so we can analyze and try to fix.

Thanks for reminding me about /etc/defaults/grub - I’ve amended my post accordingly.

Well, I just finished restoring my timeshift backup, and everything’s just perfect. I’d recommend using this method, since its faster, better, and also reinstalls grub correctly. <just remember to correct the partition UUIDs in the /etc/fstab and /etc/defaults/grub partitions>.
P.S. Thanks for your help, I did get to learn quite alot about rsync and grub.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.