Root Partition vergössern?

[HABuserJM]

Hallo,
ich habe ein Problem mit der Grösse meiner Root Partition. Ich benutze openHABian auf einem x86-Thinclient und habe dort eine 256GB SSD eingebaut. Beim Versuch meine Zigbee2MQTT Version von 1.38 auf 2.xx upzugraden bekomme ich e Fehlermeldung, dass kein Platz mehr auf der Partition ist. Nun habe ich gesehen, dass der Hauptteil der SSD mit einer riesigen Home Partition belegt ist, welche ich nicht in dieser Grösse brauche.

df.png

Wie kann ich die Partitionen in der Grösse ändern oder verschieben, um eine grössere Root Partition zu bekommen? Könnte ich GParted von einem USB Stick booten und darüber die Partitionsgrössen ändern oder geht das auch am Livesystem?

[udo1toni]

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

Code: Alles auswählen

sudo du -hs /*

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...