Kessel Buntes (blog.arlandt.com)

Vor einigen Wochen habe ich auf meinem (alten) Notebook Kubuntu komplett neu installiert. Das war meiner Meinung leider notwendig, da ich seit einigen Jahren die Upgrades nicht mit dem Kubuntu eigenen Update-Programmen durchgeführt hatte, sondern hierfür häufig das Programm aptitude genutzt habe. Im Laufe der Zeit sind immer wieder Fehler aufgetreten, die ich schließlich auf diese “unsauberen” Upgrades zurückführe.

Nur traten seit der Neuinstallation trotzdem immer wieder kleinere Probleme auf. Ich hatte zwischenzeitlich sogar den Verdacht, dass die Festplatte oder, der Arbeitsspeicher eine Macke hat. Doch alle Prüfungen waren (zum Glück) negativ. Jedes mal war die Ursache trivial (z. B. falsch gesetzte Rechte).

Und nun die nächste Geschichte, die arg an Kubuntu, meinem Notebook und meinem Brain zweifel lies

Heute morgen hatte ich den Rechner kurz an. Da war noch alles ok. Ich hatten ihn auch ordentlich runter gefahren, ehrlich

Gerade komme ich von der Arbeit, mache das Notebook an, Kubuntu startet auch bis zum Schirm zum Anmelden (x.org läuft also), Name und Passwort kann ich noch eingegeben, der Bildschirm flackert kurz, dann wieder der Anmeldeschirm. Das war es …

Logs angesehen und studiert … nichts Auffälliges. Ich zweifel an Kubuntu … hatte ich nicht letztens gelesen, dass die aktuelle Version Schrott ist. Kam vor einigen Tagen nicht von x.org ein Update?

Also flott den anderen Rechner gebootet und mal nach “Kubuntu OR KDE startet nicht” auf der Seite ubuntuusers.de gesucht. Zumindest finde ich dort keine aktuellen Hinweise auf  ähnlich Probleme. Das ist doch schon mal ein gutes Zeichen.

In einem Beitrag finde ich den freundlichen Frage, ob die Platte eventuell voll ist. Dürfte hier eigentlich nicht sein, den die 40 GB Platte dürfte eigentlich nur zur Hälfte gefüllt sein. Vorsorglich mal prüfen.

Ein Geschwindes “df -h” bringt es zu Tage, 100 % des Platte wird benutzt. 100 % WIESO DAS?

Mal den Plattenverbrauch je Verzeichnis des Rootverzeichnisses ansehen:
du -x --si -s /*
6,4M /bin
25M  /boot
0    /cdrom
2,9M /dev
14M  /etc
18G  /home
0    /initrd.img
0    /initrd.img.old
210M /lib
17k  /lost+found
29k  /media
4,1k /mnt
295M /opt
0    /proc
320k /root
9,0M /sbin
205k /srv
0    /sys
21k  /tmp
2,5G /usr
789M /var
0    /vmlinuz
0    /vmlinuz.old
Dem aufmerksamen Leser wird hier auffallen, das hier etwas nicht stimmt. Richtig, wenn man die Werte addiert (also den Plattenverbrauch je Verzeichnis) kommt man nicht auf 40 GB.

Kurze Ratlosigkeit macht sich breit. Sollte die Platte in meiner Abwesenheit kleiner geworden sein?

Und dann dämmert mir da was. Vor Jahren hatte ein Bekannter auf einem LUG Treffen ein ähnliches Problem.

Und tatsächlich …

Ich binde das Backupverzeichnis meines kleinen Servers via NFS bei jedem Linux-Rechner automatisch bei jedem Start ein. Und hier legt jeder Rechner sein mit rsnapshot erzeugtes Backup ab. Heute morgen hat das Einhängen (mounten) des Backup Verzeichnisses vermutlich nicht geklappt. Also hat rsnapshot das Backup im gleichnamigen lokalen Verzeichnis (dem Mount-Point) angelegt und hierbei den gesamte restlichen Plattenplatz vollgemüllt genutzt.

Und das Mounten nun geklappt hat, verdeckt das gemountete Verzeichnis die lokalen Dateien. Tatsächlich ist der Plattenverbrauch nach dem Unmounten von /media höher:
17G      /media

Tja, man muss nur drauf kommen …

Und jetzt muss ich mir mal etwas überlegen, wie ich das verhindere.