Announcement

**Schwarzer Kater** · Jul 06, 2023, 04:39 PM

Three thoughts to quickly make 1-2 GiB availabe:

erase old log files in /var/log
sudo snap remove firefox if you don't insist on using the Snap and install Firefox to the other partition in /home/$USER/Applications (or another place in /home/$USER if you prefer) instead, following Debian' s installation suggestion (https://wiki.debian.org/Firefox#From_Mozilla_binaries).
Be sure to replace /opt with your users's Applications directory (or your chosen place in /home/$USER) for extraction and in the .desktop file.
clean APT cache with sudo apt clean

**GreyGeek** · Jul 06, 2023, 04:41 PM

https://www.makeuseof.com/tag/resize...tition-safely/

**jlittle** · Jul 06, 2023, 07:35 PM

/var/lib looks a bit much. Do you have any docker containers or images? IME they can proliferate there unnoticed. Otherwise running sudo du -hd1 in /var/lib might reveal the problem.
/var/log - if files in the journal directory are taking the space, sudo journalctl --vacuum-size=50M prunes archived journals to 50 MB.
sudo du -hxd1 / on my work laptop says 19 GB. Your 24.4 GB looks a bit tight... you might be in for some partition juggling. I use btrfs where the linux root is a subvolume and free space is pooled, so I don't have to worry about shuffling space.

**Snowhog** · Jul 06, 2023, 07:51 PM

In a konsole type: df -hT --exclude-type=tmpfs --exclude-type=devtmpfs

Copy/paste the results.

**Robert24** · Jul 07, 2023, 12:47 AM

Thank you all for your answers. I'm amazed how kind people are on this forum. I reply a bit late because I was sleeping (I live in Europe). I have to head to my job now so I will try the various solutions you suggested tonight, but I'll still post the information some of you required:

jlittle The output of

Code:

sudo du -hd1

in /var/lib is

Code:

4.0K    ./private 
4.0K    ./usb_modeswitch
4.0K    ./ieee-data
8.0K    ./ispell
4.0K    ./dhcp
4.0K    ./avahi-autoipd
4.0K    ./misc
16K     ./libreoffice
64K     ./bluetooth
4.0K    ./mysql-files
8.0K    ./whoopsie
1.8M    ./fwupd
16K     ./grub
8.0K    ./plymouth
4.0K    ./aptitude
60K     ./ghostscript
8.0K    ./gems
4.0K    ./hp
104K    ./tex-common
32K     ./dictionaries-common
4.0K    ./python
704K    ./usbutils
109M    ./dpkg
456K    ./smartmontools
4.0K    ./dbus
29M     ./sddm
12K     ./sgml-base
60K     ./upower
3.4M    ./apt-xapian-index
736K    ./systemd
22M     ./plocate
8.0K    ./sudo
4.0K    ./acpi-support
4.0K    ./power-profiles-daemon
4.0K    ./boltd
8.0K    ./logrotate
3.5M    ./command-not-found
32K     ./xml-core
12K     ./locales
8.0K    ./ubiquity
219M    ./apt
8.0K    ./vim
4.0K    ./snmp
3.8M    ./ubuntu-advantage
8.0K    ./os-prober
8.0K    ./apport
6.1G    ./snapd
52K     ./polkit-1
60M     ./texmf
4.0K    ./ubuntu-release-upgrader
8.0K    ./ubuntu-drivers-common
4.0K    ./geoclue
12K     ./AccountsService
8.0K    ./samba
4.1M    ./aspell
60K     ./NetworkManager
4.0K    ./man-db
20K     ./update-notifier
8.0K    ./udisks2
20K     ./alsa
4.0K    ./unattended-upgrades
2.8G    ./docker
4.0K    ./tpm
8.0K    ./shim-signed
38M     ./swcatalog
4.0K    ./git
8.0K    ./xkb
8.0K    ./xfonts
28K     ./pam
12K     ./update-manager
120K    ./PackageKit
3.5M    ./ucf
24K     ./emacsen-common
244K    ./containerd
8.0K    ./colord
9.3G    .

Snowhog The output of

Code:

df -hT --exclude-type=tmpfs --exclude-type=devtmpfs

is

Code:

Filesystem     Type     Size  Used Avail Use% Mounted on 
/dev/sda5      ext4      24G   23G  481M  98% /
/dev/sda6      ext4     158G   69G   81G  47% /home
/dev/sda1      vfat     256M   36M  221M  14% /boot/efi
/dev/sda3      fuseblk  267G  258G  9.5G  97% /media/me/Windows
/dev/sda8      ext4      20G   24K   19G   1% /media/me/backup

**Schwarzer Kater** · Jul 07, 2023, 02:26 AM

You could post the output of sudo du -hd1 -x / again as jlittle suggested.
You should also add the -x flag to not count the mounted volumes in e.g. /boot, /mnt or /media .
Edit: But I saw now that you used ncdu in your first post.

Above we can see a big /snap and /var/lib/snapd amongst others (you seem to use docker, too) as expected…

Edit 2: For aesthetic reason, please remove the FONT and COLOR tags from your CODE (I was fooled a bit - it would have been easier to read for me if you posted the command and the working directory or used the full path in the command, too - my bad…).

PS: You could also post sudo fdisk -l, lsblk -e7 and lsblk -f -e7 so we can help you resizing partitions for the future with this information (to resize partitions start from a GParted usb live stick, make a working backup to another storage medium first!, … - but I suggest that you post here first to be sure).

**oshunluvr** · Jul 07, 2023, 01:08 PM

snaps. That's all I need to say. Anyway...

Check /tmp and consider mounting tmpfs in RAM instead of on the drive. I see no swap partition so I assume you have a swap file as is the default these days. It's probably larger than 1GB. I suggest moving it off the root partition to your /home partition instead. These are both easily accomplished.

As far as your early comments re. /backup, most people agree that a backup needs to be on another drive at a minimum to truly function as a backup. The best backups in order of best to least are;

On-line via a service
On another PC preferably in a different physical location
On another drive or external device

If someone suggested the /backup partition as a way to store backups of "important" files, it's the lowest form of a backup. You'd be better off with an external USB device or a backup service. I'm pretty sure you can still get 50GB storage on Box for free.

So assuming my above opinion counts for something and you agree that partition is rather useless, there are a couple ways you can remedy this situation by using the space taken by /backup.

You can boot to a live gparted USB stick and delete the /backup partition, move your /home to the end of the drive, then expand the root partition. This can be somewhat dangerous. I have done it many, many times but not 100% successfully. Don't even consider it unless you have a true backup first.
As much safer and less time consuming option is to move the contents of /var to the /backup partition and mount /backup as /var instead.

Number 1 is more organized or neater in a way, since you'll have a "normal" installation. Number 2 is safer, faster, and will work fine. In the "olden" days it was common to distribute various parts of a Linux OS across multiple drives both for space (drives were much smaller) and for performance reasons. These benefits really no longer exist, but Linux is well suited to being split up in this manner.

Finally, I wouldn't be me if I didn't point out how using BTRFS instead of EXT4 would have avoided this problem. Instead of having a less than half empty /home and a full /, you would have one 180GB (sda5+sda6) partition at about 50% full and both the root OS and Home subvolumes sharing the free space. Kind of a difficult transition at this point, but maybe for a later install...

**Schwarzer Kater** · Jul 07, 2023, 01:31 PM

Originally posted by oshunluvr View Post

[…] I see no swap partition so I assume you have a swap file as is the default these days. It's probably larger than 1GB. I suggest moving it off the root partition to your /home partition instead. These are both easily accomplished.
[…]

Good detection! And a good tip for a temporary solution.

**Snowhog** · Jul 07, 2023, 01:47 PM

What everyone is missing, IMO, and haven't (yet) asked about, is how many kernels are installed. Generally, in my experience, the number one cause of a / partition reaching near capacity and presenting the problem the OP is experiencing, is a BUTT LOAD of installed kernels.

**Schwarzer Kater** · Jul 07, 2023, 04:35 PM

Don't the standard update settings in *ubuntu clean out old kernels automatically?
At least "too many old kernels" doesn't seem to be shown by the ncdu output of post # 1 AFAIKT.

**claydoh** · Jul 07, 2023, 04:47 PM

Originally posted by Schwarzer Kater View Post

Don't the standard update settings in *ubuntu clean out old kernels automatically?
At least "too many old kernels" doesn't seem to be shown by the ncdu output of post # 1 AFAIKT.

It is supposed to, but can be broken, especially in older releases, before Debian built it into Apt instead of being separately scripted. Also, upgrades to new releases, or adding different 'tracks (Adding HWE to an .0 or .1 LTS install) or manually installing individual kernels (say, from Mainline) can make it grow.
I don't think autoremove cleans these out.

**Snowhog** · Jul 07, 2023, 06:15 PM

Easy 'nough to check. In a konsole, type: ls -la /usr/src

**kubicle** · Jul 07, 2023, 11:10 PM

Originally posted by Snowhog View Post

Easy 'nough to check. In a konsole, type: ls -la /usr/src

This is not a surefire way check installed kernels (as normally only the kernel headers are shown...and these can be installed separately from the kernel images)

It would probably be better to use something like

Code:

dpkg --list | grep linux-image

Which should show installed kernel image packages, including ones that have not been completely removed (the ones that start with 'rc').

That said, I don't think excessive kernel installations are the main problem here (according to the outputs). ~~I'd clean the apt cache first, like SK mentioned~~ [EDIT on second look, /var/cache looks rather clean], and then look into the snaps (do you need gnome snaps installed?)

**Schwarzer Kater** · Jul 08, 2023, 04:22 AM

Originally posted by kubicle View Post

[…]
(do you need gnome snaps installed?)

I think the Firefox Snap and the Wine Snap depend on them. On all of them? I don't know…
Unfortunately I have not come across something like flatpak uninstall --unused for Snaps yet.

Announcement

root partition full

root partition full

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment