(I assume you meant “I created a separated /var partition”)

You can move/resize partitions from basically any live usb (via cli or gparted for gnome and kde partition manager for kde).

Shall you want to, you can also merge the var partition with (say) your root partition:

1. mount both partitions in two directories (just create empty ones and mount on them, say ~/root and ~/var)
2. inside ~/root create the new var/ directory
3. copy the data over
4. edit ~/root/etc/fstab (remove the line for the old var partition)
5. use whatever partitioning tool to get rid of the actual partition and expand the previous/next one

Be aware that you can very easily lose your data ;)

PS: just in case, try running flatpak uninstall --unused

Is there a reason you gave /var it’s own partition? Or is the problem that your entire file root system is full?

As others have said if you have a /var partition, resizing should fix the problem but the other solution would be to migrate the contents back to your main file system partition. Presumably at present there is a symbolic link folder pointing to your /var partition? Copy the /var partition contents into a new folder then boot in to recovery mode and delete the symbolic link and rename the new folder to /var. However presumably you have a good reason for splitting /var out.

If you don’t have a separate partition then the issue may be your root system itself is full and that partition needs resizing if possible or cleaning our to make space.

Finally, Flatpak does also use the /var directories in the home users folders (it uses this for single user installs of software vs system wide installs). It’s possible it’s axtually the home folder/partition that is full and that needs resizing or cleaning out to make space .

If you end up with resizing /var as the only solution, please post your partition layout first and ask, don’t rush into it. A screenshot from an app like Disk Manager or Gparted should do it, and we’ll explain the steps and the risks.

When you’re ready to resize, you MUST use a bootable stick, not resize from inside the running system. You have to make a stick using something like Ventoy, and drop the ISO for the live version of GParted on the stick, then boot with it and pick the Gparted live. You’ll have to write down the instructions and be careful what you do, and also hope that there’s no power outage during.

The safest method, if your /home has enough space, is to use it instead of /var for (some) Flatpak installs. You can force any Flatpak install to go to /home by adding --user to the command.

If you look at the output of flatpak list it will tell you which package is installed in user home dir and which in system (/var). You can also show the size of each package with flatpak list --columns=name,application,version,size,installation.

I don’t think you can move installed apps directly between system/user like Steam can (Flatpak is REALLY overdue for a good package manager) but you can uninstall apps from system, then run flatpak remove --unused, then install them again with --user.

Please note that apps installed with --user are only seen by the user that installed them. Also you’ll have to cleanup separately for system and user(s) in the future (flatpak remove --unused for system, then flatpak remove --unused --user for each user).

Is there a reason to install one(1) singular OS across multiple partitions? Is it just because that’s how our ancestors did things?

Partitions are crude buckets that tell Operating Systems that “this lump is a filesystem that you know how to read” or “you don’t know how to read this, leave it alone”. Partitions tell UEFI that it should only use this special FAT32 chunk. A partition is not a good mechanism to set quotas, as you can see from how difficult it is to expand. A bunch of partitions that are all mounted together does little to isolate against failures.

If you want to run an OS across two filesystems that provide different characteristics (one provides atomic snapshots, the other provides ??), that would have to live on different partitions. Would you be better served by putting it all on the more modern FS? Is the older filesystem only kept around because it straddles “what my OS knows” and “what my bootloader knows”? If it’s just for the bootloader’s sake, that’s why we have /boot.

Assuming your /var is in a separate partition, you could resize it using a tool like gparted. But make a backup beforehand.

I ran into this same problem a few months ago. Instead of taking the time to learn how to manage partitions and lvms, i just re-installed debian and put everything on the same partition because i had no reason to keep em separated.

If /var is on an LVM backed partition you can add more space to the logical volume then grow the filesystem online if /var is on a filesystem that supports it. Ext4 and xfs both support it.

Btrfs and zfs should also support online resizing if you are using these. You can figure out what you have using the lsblk command.

Edit: you will need to add an additional disk to the system or have unallocated free space. If it’s a vm in something like proxmox or VMware you can add an additional disk to the VM then use LVM/btrfs/zfs to add a physical volume/add more space to a pool. If it’s a bare metal physical machine you’ll have to plug in a new disk through a mechanism that supports hot swapping.

Sounds like you created a seperate partition for /var. Only way to change that is to redo your partitions or bind mount an external disk as /var.

In the future, you should look into using LVMs for your partitions. I ran into a similar problem recently where my /var needed to be increased - I was able to run a simple lvextend -L+4G /dev/myvg/var --resizefs to grow my /var by 4 gigabytes.

Before I was using LVMs though I used a gparted live disk a lot

you could move the flatpak stuff onto another partition with same permissions and bind mount it to the original location, then persist it with a line in fstab