When your root has a total of ZERO available space

This week a new issue has popped on my laptop:

Of course my first instinct was just to press ignore :grimacing:

But obviously I wanted to turn my laptop off and be able to turn it on again, so I need to come up with a solution.

An awful idea

An awful idea was just running sudo apt clean and sudo apt autoremove.

What does sudo apt clean do?

So, we constatly install software and applications on the fly, so, when the necessity or a dependency asks, you simply go and sudo apt instal <something here>. This seems ok, until when each installation leaves behind a huuuuuge trail of cached package files, quietly consuming precious disk space.

This is where “sudo apt-get clean” steps in, it basically frees our system from the random and useless cached package files (most of them came from software installations via the “apt-get” package manager). What happens is that sometimes these packages are useful on that moment, but later it becomes a pointless “clog of space”.

By executing the “clean” command, we are effectively hitting the reset button on the cache (Goobye Cache! :smirk:). This isn’t just about tidying up; it’s about reclaiming valuable disk space for our system to breathe easy once again.

What is cool about sudo apt clean is that it targets only cached package files, leaving your installed packages untouched and your system functionality intact (Yays, things will keep working :relieved:).

What does sudo apt autoremove do?

Again, we are constantly installing and uninstalling various software packages to suit our needs. Simultaniously, our system accumulates dependencies – those extra stuff that were necessary for a particular application but are no longer needed once this application is removed.

The problem is that these dependencies are pretty much like digital ghosts, taking up valuable disk space and cluttering your system with unnecessary files.

This is where sudo apt autoremove save the day (and most of the time it does :ok_hand:). This command scans the system for orphaned dependencies – those no longer required by any installed package – and just :wave: remove them.

What makes autoremove more complete than clean is that it is very precise on what it is removing. It prunes away only those dependencies that are truly superfluous, leaving the system lighter without sacrificing stability or performance.

Why awful?

They seem good, until you know they just remove something around 300MB of memory :disappointed:

A good idea

After googling a bit, this cool post on ask ubuntu brought some good insights on “superfluous” directories content that I could somehow get rid of.

So, I essentially switched to the root folder / and executed the sudo rm -r \path\to\dir\*.

What does sudo rm do?

I could be super quick and just explain that sudo rm is a simple instruction to delete files and directories and thats it. But there is a lot more…

With sudo rm, you can delete files that resist deletion under normal circumstances with just a snap. But with this power comes a significant risk. One misplaced character, one mistyped path, and you could can erase crucial system files or wipe out entire directories of irreplaceable data. (Yes, we are talking about reinstalling your linux from scratch :trollface:)

The lesson here is clear: ALWAYS be careful with sudo rm. Always double-check your command before hitting Enter. Maybe you can consider implementing safeguards like confirmation prompts or regular backups to mitigate the risk of irreversible mistakes. (Are you sure that you are sure? :loudspeaker::loudspeaker::loudspeaker:)

Don’t delete what you don’t know what it is!

So, It is extremely important to also know what are we actually deleting. This part I will only list the directories I actually cleaned.

  • /tmp : A temporary directory for storing short-lived files, often used by programs for cache and intermediate data. Files here are typically deleted automatically by the system or upon reboot, providing transient storage. Users and programs have write access for creating temporary files. (r like the post says: user temp data – these are commonly all deleted every reboot anyway)
  • /var/tmp : Similar to /tmp, but files here persist across reboots, offering longer-term temporary storage. Used for larger or longer-lasting temporary files that need to survive system restarts. Users and programs also have write access, and files are retained until manually deleted. (or like the post says : print spools, and other system temporary data)
  • /opt : Directory for optional or add-on software installations, separate from the core system files. Provides a standardized location for third-party software, maintaining system organization. Typically requires root privileges for installation, offering a dedicated space for non-native applications. (or like the post says: many third-party apps install here, and don’t clean up after themselves)
  • /var/log : Repository for system log files containing records of system events, errors, and activity. Organized by category or application, aiding in system troubleshooting and monitoring. Readable by users for system insight, with write access restricted to system processes or privileged users. (or like the post says: log files can eat up a lot of space if there are repetitive errors )

A perfect idea

Ok, the problem is that all the two previous solutions are temporary and don’t actually solve whatever is consuming the root, or even correct the root size itself.

Myself, I hold a dual boot (Windows + Ubuntu) and when I did my installation I messed up with the sizes of the partitions.

Having said that, the ideal (almost perfect) solution would be choosing a distro and boot from a LiveCD (or pendrive). After this, run the gparted to resize and correct the partitions.

That’s all for this post! :smiley: