Wir schießen uns in die Füße, erneut
Das Schöne an Linux ist ja, daß man als root über sämtliche Waffen vefügt, um sich gepflegt in die Füße zu schießen, und nutzerfreundlich wie Linux nun mal ist, sind diese Waffen auch schon geladen, ausgerichtet und entsichert – man muß nur noch abdrücken.
Vor ein paar Wochen: Ich wollte ein Video mit nach AV1/Opus umcodieren und hatte irgendwie nicht begriffen, daß die Encoder bei Debian im ganz normalen Repository liegen und war also der Meinung, ich müsse das selbst übersetzen. Das ist ein ziemlich dickes Brett, was man da bohren muß, zum Beispiel sind manche Bibliotheken in golang geschrieben, so daß man noch ein go nachinstallieren muß. Ich fing also an, und natürlich wurden erstmal tonnenweise Abhängigkeiten nachinstalliert, bevor es überhaupt ans Bauen ging. Am Ende hatte es funktioniert – und ich stellte fest, daß das völlig umsonst war: Debians ffmpeg liefert alles mit, was ich brauche. Lehrgeld.
Der Rechner hat eine relativ kleine Root-Partition, und der große Rest wird für ZFS verwendet. Alle Dienste, die ins Internet exponiert sind, laufen dort. Also jedenfalls / war arg voll, aber ich wußte nicht mehr, was ich alles sinnloserweise nachinstalliert hatte. Da kam mir eine Idee: Einfach alle dev-Pakete löschen und hinterher noch ein autoremove, damit auch die Abhängigkeiten gelöscht werden. Hat gut funktioniert, danach war wieder einiger Platz frei. Das war vor ein paar Tagen.
Heute sehe ich mal wieder ins Zabbix. Da steht auf einmal, daß zfs-zed.service nicht laufen würde. Also versuche ich ihn zu starten, doch systemctl meint, es gäbe ihn nicht, und in der Tat: es gibt ihn nicht. Ich ahne etwas:
Start-Date: 2024-05-05 20:58:18
Commandline: apt -y purge dpkg-dev
Purge: build-essential:amd64 (12.9), zfs-zed:amd64 (2.2.3-1~bpo12+1), zfs-dkms:amd64 (2.2.3-1~bpo12+1), dpkg-dev:amd64 (1.21.22), xtables-addons-dkms:amd64 (3.23-1), dkms:amd64 (3.0.10-8+deb12u1)
End-Date: 2024-05-05 20:58:53
ZFS-on-Linux ist aus Lizenzgründen als dynamisches Kernelmodul realisiert. Und muß mit dkms(8) gebaut werden, was diverse Header erwartet, die eben in dev-Paketen liegen. Die hatte ich aber gelöscht, und mein tapferes autoremove hatte dann das komplette ZFS wegrasiert (aber nicht die Daten). Und solange die Büchse läuft, macht das auch nichts.
Heute dachte ich dann, ich sollte nicht länger warten mit einem Reboot. Code, der nur noch im RAM liegt, nee, muß nicht sein. Also reboot und tja, kein ZFS, keine Dienste.
Die Lösung: Nachsehen, ob der Pool noch da ist (zpool import) und dann importieren (zpool import <poolname>) Reboot, alles wieder schön.
Und die Flinten nachladen nicht vergessen fürs nächste mal!
There are no comments yet.