So… after my system has been broken a few times due to insufficient space in root partition, I’m thinking about increasing the size to 50 gigs. Would this be safe to do?
According to this topic, yes. But I’m using Dracut instead of GRUB. Does this change anything in terms of the process involved?
Already backed up my files before even thinking about booting gparted live. 
I’ve used gparted too many times to count, so I’d be confident that it will work. It really comes down to how many other neighboring partitions will be affected; the less the better (obviously). You’re already completed the #1 most important pre-step (backup).
Now, you’re not using dracut instead of GRUB. dracut creates initrd images so that bootloaders like GRUB can actually work; dracut is the default image creator, Arch still uses mkinitcpio. GRUB should not be affected by a resizing of root.
You don’t really need that. You can use partitionmanager already included in the live EOS’ usb.
If you are more comfortable with gparted, you could install it on the live usb or use an ISO from another distro which includes it, like Linux Mint, if you have one.
Can you post a screenshot from your disk layout and tell us about your plan?
Just for the record this comes from the install wiki
In 2024, we added GParted in addition, to the ISO for your convenience.
Booted EOS live, used gparted to shrink current home partition about 10 gigs, moved the home partition to the right (moving free space next to root partition), resized root partition to 50 gigs.
Seems to be working great. 
Thanks all for the tips. And thanks devs for including gparted on the EOS installer.
this is solved, but anyone reading I too have done this Live, with Gparted to increase the size of the /root (filesystem).
I also had to shrink a partition first.
Everything I read led me to believe this was about 98% safe and that was good enough for me, I needed the room.
Yeah. Be smart and assign more than 40 gigs to the root partition when first installing, so you’ll probably not have this problem. 
For for me, flatpak and plexmediaerver metadata were filling up the partition. Even after moving the metadata to another partition root kept filling up and eventually I had to do this resize.
Just for the record, one can have the flatpaks installed on a different partition or subvolume if Btrfs, mounted at /var/lib/flatpak.
Same thing for its user data at ~/.var.
I have these subvolumes in a multiboot system. My flatpak apps and their user data are available in all of them. Updates and installing any new flatpak apps can be done from any of the systems.
Also, If a single user system, flatpaks doesn’t need to be installed under /. They can be installed under user’s home directory.
I hope that unsafe %2 made you to backup your data before attempting the resize.
No matter how small the percent, the risk for data loss and data corruption is very real when manipulating partitions, moving them around and resizing them.
So BACKUP your data anyone before attempting such operations.
You know already what they say but I repeat it:
Better Safe Than Sorry
This is interesting. Are the other subvolumes set in size? How much space have you reserved for each?
Seems like a good system. I don’t need to multi boot, so this probably would be overkill for my use.
You just create subvolumes at the root of the Btrfs filesystem with no specified size. They will increase or decrease “dynamically” according to your usage. As long as there is space left at the root of the Btrfs partition/disk you will have that space available to be used in any and all subvolumes you may have.
Yo could also create nested subvolumes, that is, subvolumes within subvolumes (within subvolumes…).
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.