soffensive blog
Posts Tags Categories About
soffensive blog

Contents

Kali Linux Long Term Usage Part 1: Disk Usage

 included in Linux
   1086 words   6 minutes 

I am using Kali Linux on a regular basis inside a virtual machine (VirtualBox) and I have maintained my image for a couple of years.

Over the last months and years, the booting time got worse and worse, until it reached the following startup time:

1
2
3

└─$ systemd-analyze time                                                           
Startup finished in 34.355s (kernel) + 1min 42.261s (userspace) = 2min 16.617s 
graphical.target reached after 1min 42.261s in userspace.

Clearly, this is extraordinarily much, compared to other operating systems. The system has enough memory and computing resources, so clearly the culprit is inside the operating system.

In this series of blog posts, I would like to take you on my journey in discovering various optimizations and inefficiencies I discovered along the way.

Part 1 will cover optimizations with regard to hard disk usage:

Until recently, I thought it is enough to regularly update and clean the operating system with the following commands:

1

sudo apt update && sudo apt full-upgrade -y && sudo apt autoclean && sudo apt autoremove

However, the autoremove and autoclean commands will of course only clean up resources that are related to the package manager apt.

In general I can strongly recommend the tool ncdu for determining the disk usage. Although du does the job as well, ncdu can be used interactively and will allow you to quickly explore the entire file system for possible candidates.

Go Cache / Src Folders

I only regularly install Go binaries, e.g., with the following command:

1

go install github.com/ffuf/ffuf@latest

When analyzing the disk usage in my home folder (~), I realized the ~/go folder took over 26 gigabytes of space!:

1
2
3
4
5

└─$ du -h -d 1 ~/go/
26G     ./pkg
182M    ./bin
5.2M    ./src
26G     .

Why on earth does the pkg folder take so much space? According to https://scripter.co/cleaning-up-gopath-pkg/:

When you run go get to install any Go package,

  • ${GOPATH}/pkg/ gets populated with all the Go module dependencies,
  • .. and all package’s executables if any get installed to ${GOPATH}/bin/.

So clearly, if you install Go packages with the command mentioned above, it will inevitably fill up your pkg folder.

To keep your system clean, execute the following commands regularly:

1
2
3
4

go clean -cache 
go clean -modcache 
go clean -testcache 
go clean -fuzzcache
  1. go clean -cache
    • Clears the entire build cache ($GOCACHE, typically ~/.cache/go-build). This includes compiled object files, intermediate build artifacts, and anything stored there, encompassing test and fuzz cache data as a side effect since they reside in the same directory.
  2. go clean -modcache
    • Deletes the module download cache ($GOPATH/pkg/mod, usually ~/go/pkg/mod). This includes all downloaded module versions and their source code.
  3. go clean -testcache
    • Expires cached test results within the build cache. It doesn’t delete the cache directory but marks test outputs as stale, forcing tests to rerun.
  4. go clean -fuzzcache
    • Removes fuzzing-related files from the build cache, specifically seed corpora and inputs that improved coverage during fuzz testing.

After executing these commands, I considerably lowered the footprint of go:

1
2
3
4
5

└─$ du -h -d1 ~/go/
16K     ./pkg
182M    ./bin
5.2M    ./src
187M    .

The folder ~/go/src will not be cleaned with the go clean command.

What is ~/go/src?

  • It’s the directory where Go expects source code for packages and projects when using the pre-module GOPATH workflow (before Go 1.11 introduced modules).
  • It may contain:
    • Your own projects (e.g., ~/go/src/github.com/yourusername/myproject).
    • Cloned repositories or manually downloaded source code for dependencies (in older workflows).
  • With Go modules (post-1.11), ~/go/src is less critical, as dependencies are stored in $GOPATH/pkg/mod, and projects can live anywhere. However, it might still hold legacy code or manually managed repos.

So in my case, there were only two cloned repositories from 2021 and 2022, so I deleted them after careful consideration with:

1

rm -rf ~/go/src/*

AWS CLI

Furthermore, I regularly install the latest AWS CLI version (https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) manually because the version included with apt is usually not the latest.

With the help of ncdu realized that over 15 gigabytes of space was occupied with these installations:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

└─$ du -h -d1 /usr/local/aws-cli                                                   
15G     /usr/local/aws-cli/v2
15G     /usr/local/aws-cli

└─$ ls  /usr/local/aws-cli/v2 | wc -l
74


└─$ du -h -d2 /usr/local/aws-cli 
173M    /usr/local/aws-cli/v2/2.7.20
225M    /usr/local/aws-cli/v2/2.16.11
174M    /usr/local/aws-cli/v2/2.7.29
208M    /usr/local/aws-cli/v2/2.11.7
208M    /usr/local/aws-cli/v2/2.11.4
172M    /usr/local/aws-cli/v2/2.6.4
225M    /usr/local/aws-cli/v2/2.17.0
216M    /usr/local/aws-cli/v2/2.13.30
224M    /usr/local/aws-cli/v2/2.15.27
224M    /usr/local/aws-cli/v2/2.15.33
183M    /usr/local/aws-cli/v2/2.9.1
174M    /usr/local/aws-cli/v2/2.7.10
174M    /usr/local/aws-cli/v2/2.7.9
186M    /usr/local/aws-cli/v2/2.9.5
210M    /usr/local/aws-cli/v2/2.11.21
214M    /usr/local/aws-cli/v2/2.13.19
207M    /usr/local/aws-cli/v2/2.11.0
223M    /usr/local/aws-cli/v2/2.15.16
....

The AWS install command with the --update parameter will not remove any existing AWS CLI versions, but only update the symbolic links to the current version.

Therefore, it is vital to manually or automatically clean up the previous aws-cli versions once you install a new one.

Unused Package Configuration Files

When a package is removed with apt remove, its config files will remain on disk.

You can check if there are any packages that have still config files on disk, but are not installed, with the following command:

1

dpkg -l | grep ^rc | awk '{print($2)}

These configuration files can be deleted with:

1

dpkg -l | grep ^rc | awk '{print($2)}' | xargs sudo apt -y purge

Configuration files can be removed automatically when uninstalling packages with the following commands:

apt purge packagename, or
apt remove --purge packagename

It should be noted that ap remove packagename will remove the package binaries, but not the configuration or data files of the package packagename.

Unused packages can be deleted along with their configuration files the following command

sudo apt autoremove --purge

Java installations

In addition, there may be several Java/OpenJDK versions that are no longer supported or you no longer need. You can quickly check for the installed versions with the following command, which yielded in my case various versions:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

└─$ dpkg-query -W -f='${binary:Package}\n' | grep -E -e '^(ia32-)?(sun|oracle)-java' -e '^openjdk-' -e '^icedtea' -e '^(default|gcj)-j(re|dk)' -e '^gcj-(.*)-j(re|dk)' -e '^java-common'

default-jdk
default-jdk-headless
default-jre
default-jre-headless
icedtea-netx
icedtea-netx-common
java-common
openjdk-10-jdk:amd64
openjdk-10-jdk-headless:amd64
openjdk-10-jre:amd64
openjdk-10-jre-headless:amd64
openjdk-11-jdk:amd64
openjdk-11-jdk-headless:amd64
openjdk-11-jre:amd64
openjdk-11-jre-headless:amd64
openjdk-17-jdk:amd64
openjdk-17-jdk-headless:amd64
openjdk-17-jre:amd64
openjdk-17-jre-headless:amd64
openjdk-21-jdk:amd64
openjdk-21-jdk-headless:amd64
openjdk-21-jre:amd64
openjdk-21-jre-headless:amd64
openjdk-23-jre-headless:amd64
openjdk-7-jre-headless:amd64
openjdk-8-jre-headless:amd64
openjdk-9-jdk:amd64
openjdk-9-jdk-headless:amd64
openjdk-9-jre:amd64
openjdk-9-jre-headless:amd64
oracle-java8-jre

Any unnecessary packages can be fully removed with any of the following commands:

1
2

sudo dpkg --purge package_name
sudo apt purge package_name
Updated on 2025-04-06
 Linux, Kali
Back | Home