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.
Stop (flatpak) service that uses a directory
Move /var/lib/flatpak to other filesystem (that has space, e.g. to /home/)
Symlink or bind-mount /home/flatpak to /var/lib/flatpak (I prefer bind mounts)
Restart the service
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.
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”).