Wenn Du (zumindest auf dieser Ebene) relativ unerfahren mit GNU/Linux bist, wird die sicherste Variante über ein Live Linux System führen, welches GPartEd mitbringt (z.B.
https://gparted.org/livecd.php). Du lädst das passende Image auf Deinen Desktop herunter und schreibst es je nach Distribution laut Anweisungen z.B. auf einen USB-Stick, von dem der Rechner dann gebootet wird.
Anschließend kannst Du aus dem laufenden Live System heraus GPartEd starten und die Partitionen der Festplatte ändern. Dabei musst Du vermutlich zunächst die /home Partition verkleinern, um anschließend die root Partition vergrößern zu können.
Eventuell musst Du auch Partitionen verschieben, weil /home auf sda4 liegt, aber / auf sda2. Es kann also gut sein, dass es noch eine Partition sda3 gibt (es könnte sich dabei z.B. um eine swap Partition handeln).
Die Partitionstabelle zu bearbeiten ist immer mit gewissen Risiken verbunden
, es ist also gut, wenn Du von allen Daten vorher eine Sicherungskopie erstellst, um im Fall der Fälle die Daten zurückspielen zu können.
Und weil ich ja die swap Partition erwähnt habe...
Falls sda3 tatsächlich die Swap Partition ist, wäre eine (eher ungefährliche) Variante, /home zu verkleinern (so dass anschließend dahinter genug Platz für swap ist), eine 2. Swap Partition zu erzeugen, die erste swap Partition abzuschalten, die 2. Swap Partition zu aktivieren, die alte swap Partition zu löschen und abschließend / zu erweitern. Das sollte relativ risikoarm sein, bringt aber nur dann etwas, wenn swap groß genug ist.
Allerdings... 27 GByte erscheinen mir
reichlich viel Platz für ein GNU/Linux System (insbesondere, wenn es lediglich die root Partition ist).
Der erste Schritt sollte also sein, alte (überflüssige) Daten aufzufinden und zu entfernen.
Insbesondere /tmp wäre hier zu nennen, aber grundsätzlich auch alles unterhalb /var/log/. Ansonsten hilft
zum Identifizieren von Verzeichnissen, die ungewöhnlich viel Platz belegen. du (disk usage) listet alle Dateien des angegebenen Pfads incl. Unterverzeichnissen, die Option h gibt die Werte human-readable aus, also in Byte, kByte, MByte, GByte usw.. s gibt nur die Summe aus, /* ist der zu untersuchende Pfad. Da sich auf der obersten Ebene auch diverse "Maschinen"-Verzeichnisse befinden, wird es ein paar Zugriffsfehler geben, /dev/ proc und /run sind tabu, aber Du willst Dir ja einen Überblick verschaffen. Du kannst so also das Verzeichnis mit dem größten Platzbedarf identifizieren und anschließend eine neue Abfrage starten, in der Du dann nur noch dieses eine Verzeichnis anschaust, also z.B. so:
Code: Alles auswählen
udo1toni@odroid:~$ sudo du -hs /*
5,3M /bin
17M /boot
0 /dev
3,4M /etc
11M /home
56M /lib
4,0K /lost+found
4,0K /media
4,0K /mnt
4,0K /opt
du: Zugriff auf „/proc/17798/task/17798/fd/4“ nicht möglich: Datei oder Verzeichnis nicht gefunden
du: Zugriff auf „/proc/17798/task/17798/fdinfo/4“ nicht möglich: Datei oder Verzeichnis nicht gefunden
du: Zugriff auf „/proc/17798/fd/4“ nicht möglich: Datei oder Verzeichnis nicht gefunden
du: Zugriff auf „/proc/17798/fdinfo/4“ nicht möglich: Datei oder Verzeichnis nicht gefunden
0 /proc
100K /root
42M /run
3,3M /sbin
4,0K /srv
0 /sys
32K /tmp
331M /usr
463M /var
udo1toni@odroid:~$ sudo du -hs /var/*
1000K /var/backups
211M /var/cache
127M /var/lib
4,0K /var/local
0 /var/lock
125M /var/log
4,0K /var/mail
4,0K /var/opt
0 /var/run
16K /var/spool
36K /var/tmp
udo1toni@odroid:~$
Der erste Aufruf hat zutage gefördert, dass /var den meisten Platz benötigt.
Der zweite Aufruf zeigt, dass /var/cache, /var/lib und /val/log die großen Brocken sind. Bei dem gezeigten System gibt es allerdings keinerlei Handlungsbedarf
das läuft ohne große Änderungen schon seit 15 Jahren vor sich hin...
Ich betreibe openHAB in einer virtualisierten Umgebung, was allerdings für die Größenbetrachtung eine untergeordnete Rolle spielen sollte. So sieht das bei mir aus:
Code: Alles auswählen
udo1toni@openhab:~$ df -h
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
tank/subvol-102-disk-0 8,0G 808M 7,3G 10% /
tank/subvol-100-disk-3 10G 3,4G 6,7G 34% /etc/openhab
none 492K 4,0K 488K 1% /dev
udev 32G 0 32G 0% /dev/tty
tmpfs 32G 0 32G 0% /dev/shm
tmpfs 13G 116K 13G 1% /run
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 32G 0 32G 0% /tmp
tmpfs 6,3G 8,0K 6,3G 1% /run/user/1000
Ich nutze zwei Datasets für openHAB, das OS ist auf 102-disk-0, die Nutzdaten auf 100-disk-3 untergebracht, also selbst wenn wir beides zusammenzählen, komme ich auf gerade mal viereinhalb GByte (davon gehören 1,4 GByte zur openHAB Test-Instanz, die ihre Daten auf dem selben Dataset abspeichert). Zigbee2mqtt läuft bei mir allerdings unter Docker in einem anderen Container - strickte Trennung der Systeme ist einer der Vorteile von Virtualisierung...