0

I just installed Ubuntu 24.04, and I made a mistake: I put the /var directory on its own partition, and its size is 10 GB. After a few days it is already full.

Is there a way to fix this problem without reinstalling the OS from scratch?

Is it possible to resize a partition, even loosing its contents?

What is a suggested size for the /var directory?

This is my partition table:

Model: WD_BLACK SN850X 2000GB (nvme) Disk /dev/nvme0n1: 2000GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 8 1049kB 1075MB 1074MB fat32 boot boot, esp 1 1075MB 323GB 322GB xfs / 2 323GB 426GB 103GB linux-swap(v1) swap swap 3 426GB 437GB 10.7GB ext4 var 4 437GB 439GB 2147MB ext4 temp 6 439GB 547GB 107GB xfs 3rdp 5 547GB 1406GB 859GB ext4 home 7 1406GB 1427GB 21.5GB ext4 crypt

This is the contents of my /var directory:

~> sudo bash -c 'shopt -s dotglob; du -hxs /var/*' 7.0M /var/backups 661M /var/cache 4.0K /var/crash 8.9G /var/lib 4.0K /var/local 0 /var/lock 49M /var/log 16K /var/lost+found 4.0K /var/mail 4.0K /var/metrics 4.0K /var/opt 0 /var/run 13M /var/snap 52K /var/spool 108K /var/tmp 4.0K /var/.updated

Here are more details about my partitions:

~> df -h Filesystem Size Used Avail Use% Mounted on tmpfs 5.9G 2.7M 5.9G 1% /run /dev/nvme0n1p1 300G 29G 272G 10% / tmpfs 30G 180M 30G 1% /dev/shm tmpfs 5.0M 12K 5.0M 1% /run/lock efivarfs 148K 62K 81K 44% /sys/firmware/efi/efivars /dev/nvme0n1p6 100G 2.5G 98G 3% /opt /dev/nvme0n1p7 20G 24K 19G 1% /crypt /dev/nvme0n1p4 2.0G 103M 1.7G 6% /tmp /dev/nvme0n1p3 9.8G 9.6G 0 100% /var /dev/nvme0n1p5 787G 13G 734G 2% /home /dev/nvme0n1p8 1022M 41M 982M 4% /boot/efi tmpfs 5.9G 196K 5.9G 1% /run/user/1000
Improve this question
11
  • 1
    You can only manipulate a disk's partitions when none of them is mounted or in use as swap. You'll have to boot from some other medium (your install disk in "Try ..." mode, or a Live USB), and probably use swapoff before you run gparted. My /var is 137G, 10G used. Commented Jun 14, 2024 at 22:12
  • 1
    I'd be asking what filled up /var so quickly Commented Jun 14, 2024 at 23:06
  • 2
    Most new users do not need separate partitions over / (root). Often with larger drive like yours a separate /home may make sense. Extra partition then require you to manage space on each where having all in / requires less work allocating space correctly. You also have huge swap. You probably can reduce swap a lot and move /var into unallocated space and then expand right. Never interrupt move or data is corrupted. Be sure to have good backups before any partition change. Commented Jun 15, 2024 at 14:29
  • @ChrisDavies - I added the contents of my /var directory, if it can help. Commented Jun 15, 2024 at 20:12
  • 1
    @ChrisDavies - I added the info you asked for. Commented Jun 15, 2024 at 21:26

2 Answers 2

Reset to default
3

There are insufficient data in your question from which to derive a meaningfully complete answer other than "maybe".

Is there unallocated space on the disk on which /var currently resides? If so you may be able to use a tool such as parted or gparted to expand the partition. If there is unused allocated space in another partition on the drive, the same tool might be able to be used to shrink that partition to make room for /var to expand.

Did you use a tool such as LVM to set up your disk allocation? If so it may be possible to create a new physical partition and use LVM to utilize it to expand /var.

Absent knowing about these or other possible considerations, the only correct answer to give is "maybe".

As an aside, before you use any means to expand your /var allocation, it would be a good idea to ensure you have a good backup, because these operations do have a nonzero - albeit small - chance of causing data loss.

Improve this answer
1
  • Thank you. Please, let me know if the information I added is enough. Commented Jun 15, 2024 at 21:31
1

The size of /var greatly depends on what the system is doing. For example, if the system is a mail server, /var/mail and /var/spool could grow arbitrarily large, depending on the size of the user base; those directories would then effectively be the main reason of the system's existence.

The size of /var/lib depends on what software you have installed, and /var/cache and /var/snap might also grow depending on what applications are installed and how they are used.

You're using GPT and UEFI boot, but otherwise a quite classic partitioning setup. (GPT is good; it means we don't have to deal with MBR's size restrictions and the primary/extended/logical partition nonsense; all partitions will be equally usable for any purpose.)

If I'm not mistaken, there is still roughly 500G of unused space towards the end of the disk. And right next to the too-small /var partition, there's a swap partition of 103G. It could be repurposed to expand /var fairly easily. Unfortunately the swap is located before the /var partition, which complicates things a bit.

I would start by creating a new swap partition into the unused space, and running mkswap on it. Then I'd comment out the old swap partition in /etc/fstab, and add in the information of the new swap partition. At this point, I would also check if the suspend/resume configuration needs to be updated to point to the new swap partition (/etc/initramfs-tools/conf.d/resume in Debian, probably similar in Ubuntu). Then sudo update-initramfs -u and reboot.

After confirming the system is using the new swap partition and no longer the old one, it would be time to remove the swap flag from the old swap partition and set its partition type to be the same as /var has. Then the old swap could be initialized as the future /var using sudo mkfs.ext4, and mounted temporarily to /mnt.

Then, it would be time to shut down any applications that might be actively writing to /var, and copy the data from the old partition to the new one, with a simple cp -a /var/.updated /var/* /mnt/. Then another edit to /etc/fstab to make the system mount /dev/nvme0n1p2 instead of /dev/nvme0n1p3 as /var (probably using filesystem UUIDs though, as is the current recommended practice), and a reboot.

If the system now boots successfully with the new, expanded /var, it would be a simple matter to use gparted to remove the old, now-unused small /var and use its space to expand (even on-line!) the new /varstill further.

This is what I would do in this situation; you should use your own judgement to decide if this is a good plan for you or not.

If you need more specific instructions than this outline, you should consider doing this together with someone that has more Linux experience.

Improve this answer
5
  • Thank you for your extensive explanation. Tomorrow I will try it. Commented Jun 16, 2024 at 0:27
  • I confirm I have 500 GB of free space. But I think I am stuck. I need to install gparted (sudo apt install gparted), and I get: E: You don't have enough free space in /var/cache/apt/archives/. I am thinking to reinstall the OS from scratch... with the knowledge that Ubuntu requires a larger /var partition than usual. Commented Jun 16, 2024 at 12:59
  • New SSD layout: delete existing /var; expand swap over the new available space (could not do it); create new 100GB wide /var in unused space. I think this should be fine for now. Commented Jun 17, 2024 at 10:53
  • What happened: the new /var I created in its own partition is not used, and the OS created a new /var directory in the / partition... Commented Jun 18, 2024 at 15:45
  • 1
    In order to mount any partition as /var, the root filesystem must have an (ideally empty) directory at /var to act as a mount point. So the /var directory in the / must always have been there. Your system just failed to mount the new /var, i.e. something is wrong with your /etc/fstab file, or you did not run a mkfs of appropriate type on the partition that was supposed to become the new /var. Commented Jun 18, 2024 at 16:03

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.