Hello
I have a 75GB
/dev/rl/root
volume that is constantly full.
I also have 700GB of free space on /dev/rl/home
Is it possible to move 100GB of free space from /dev/rl/home to /dev/rl/root without erasing all the data ?
Any thoughts are most welcome.
Thank you
It depends on what your filesystem is. If it is xfs, then no, you cannot shrink it. If it is ext4 or ext3, then yes you can shrink it.
What of ZFS file system ? Can it be extended?
Please show us how to extend in ext4 or ext3 for learning purposes.
Both are xfs on my machine … that is rather disappointing. Thank you for your confirmation.
What is consuming space on / ? (You could run something like du -d 2 -hx / to spot the big subdirs.)
You could create a subdirectory under /home that is nobody’s home directory.
Then move content of some big one to that new dir.
Finally, bind mount the new dir to where the data was originally. (That way you don’t have to tell services tha their data is physically elsewhere.)
My machines are desktop Rocky stations and I install lots of apps etc. Snap & flatpak take up so much space
I really don’t want to rebuild my machine due to the time it (as I am sure many of you understand) and I did not really that all the apps etc install to root. The out of the box rocky root format size is 50GB, which is fine for a very specific use cases, but for a desktop usage like mine, the root should be at least 100GBs in my experience.
I’d rather keep the root small (I have usually 24GiB root) and have separate filesystem for flatpaks that is mounted to /var/lib/flatpak
If filesystems are not trivial to resize (e.g. they have XFS and are not on LVM volumes) and space allocation is uncertain, then I’d have the “data” filesystem (for snaps, flatpaks, VM images, etc) and bind mount subdirs from there.
Indeed.
/var/lib/flatpak to other filesystem (that has space, e.g. to /home/)/home/flatpak to /var/lib/flatpak (I prefer bind mounts)You don’t need to “rebuild” the machine, if you do the above and you don’t have to run flatpaks/snaps/etc while you have a “maintenance break” for the transfers.
Thank you for the symlink suggestion. I presume that future OS updates will not affect this suggestion?
This is not a beginner how to. It tells what I did but it’s not a step-by-step guide.
The /home filesystem is large, but at the beginning it does not contain much data.
So I booted in single user mode, which will let me unmount /home later.
Used an external usb disk (or a usb stick with enough capacity) for creating a filesystem (any type will do) large enough to store everything you have in /home, copied everything inside /home to that new filesystem (double check that everything was copied and that owner group and permissions were preserved).
Then unmount /home and remove it’s LV.
Now, create a smaller LV and build an ext4 filesystem inside, mount it as /home, copy back the contents you saved to the external disk.
Make sure that /etc/fstab is pointing to the new fs and that the type now is ext4.
And that should be enough.
You know have enough free space on the vg to enlarge / but even better you can now create a /var fs, which probably is what is causing your / to fill up.
This will require other boot trick because you can’t let systemd start on boot. If memory serves me you have to add init=/bin/sh to your kernel line. After that the idea is the same, as you now have space on the VG you can create and mount a new ext4 filesystem, name it /var2, copy everything from /var to /var2, remove /var and it’s contents. Create a directory named /var (it will be the mount point).
Now unmount /var2, go into /etc/inittab and set the new filesystem to be mounted on /var, you can do a mount /var before rebooting just to make sure it is working. If it is just reboot normally.
What I really want is a procedure to convert / from xfs to ext4 
There are not any conversions between xfs to ext4 that I am aware of. You can convert ext4 to btrfs, since btrfs provides these tools to do that. But this is irrevelant since Red Hat removed btrfs from their distro (but other distros do have it, so just worth mentioning anyway). I believe there was some github project claiming conversions between filesystems, but even that had huge disclaimers for potential data loss. Not worth the risk.
One can also boot with the install media; there (bootloader’s menu) are “troubleshoot” options in addition to the “install” and “test&install”. That way you can run without depending on any filesystem that is in the drive(s).
Essentially the same as with /home: dump data to backup, replace filesystem, and restore.
There you really need that “external OS” (like the install media); can’t run from the volume that you wipe.
There is also the “hindsight procedure”: never use XFS in the first place and always leave some of the drive unallocated (for “future volumes”).
Another space hog is NVIDIA. Gigabytes get used up with multiple installs of CUDA and drivers etc. And in my experience, once broken NVIDIA is a real pain to repair.