... Obwohl auf der SSD noch genug Platz ist.
Hallo zusammen,
seit ein paar Tagen ärgert mich das System, auf dem mein FHEM läuft damit,
dass es sich nicht mehr updaten lässt.
Auch Ratschläge mit "-f" u.ä. laufen ins Leere.
Kann es sein, dass Ubuntu so konfiguriert ist, dass es bei Updates solange alte Kernel-Images ablegt,
bis es keine freien Inodes mehr gibt und man diese auch mit Bordmitteln nicht mehr gelöscht bekommt,
weil auch fürs Löschen solche Inodes benötigt werden?
Wenn dem so wäre, dann wäre das mal wieder Wasser auf die Mühlen eine zufriedenen Windowsanwenders,
dem Vergleichbares seit über 30 Jahren mit Windows nicht passiert ist.
Vielleicht hat jemand, der sich mit Linux besser auskennt, einen Tipp für mich,
wie ich das System wieder flott bekomme, ohne mir dabei ins Bein zu schießen?
Viele Grüße
Markus
Als erstes müsstest Du uns mal mitteilen, was überhaupt los ist. Es wird doch sicher irgendeine Fehlermeldung geben.
Alte, nicht mehr benötigte Pakete wie z.B. alte Kernel entfernt man mittels sudo apt-get autoremove
Wenn genügend Platz auf der Platte ist, sollte das eigentlich nicht das Problem sein. Wenn Du beim Formatieren nicht an den Inode-Größen rumgefummelt hast, sollte das passen. Mir sind zumindest noch nie die Inodes ausgegangen (in über 20 Jahren Linux).
Hallo mahowi,
vielen Dank für deine schnelle Antwort!
autoremove habe ich schon versucht und ein zwei weitere Kommandos, die das System vorgeschlagen hat.
Die genauen Fehlermeldungen, reiche ich nach, wenn ich wieder zuhause bin.
Gruß
Markus
So, jetzt bin ich dazugekommen, die Fehlermeldungen zu notieren:
Nach dem Anmelden:
Last login: Sun Jun 11 17:13:43 2017 from 192.168.178.65
markus@Jarvis3:~$
login as: markus
markus@192.168.178.74's password:
Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-75-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
29 Software-Pakete können aktualisiert werden.
13 Aktualisierungen sind Sicherheitsaktualisierungen.
Es gibt also einiges upzudaten.
markus@Jarvis3:~$ sudo apt-get update
[sudo] Passwort für markus:
OK:1 http://de.archive.ubuntu.com/ubuntu xenial InRelease
Holen:2 http://de.archive.ubuntu.com/ubuntu xenial-updates InRelease [102 kB]
Holen:3 http://de.archive.ubuntu.com/ubuntu xenial-backports InRelease [102 kB]
Holen:4 http://security.ubuntu.com/ubuntu xenial-security InRelease [102 kB]
Holen:5 http://de.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages [553 kB]
Holen:6 http://de.archive.ubuntu.com/ubuntu xenial-updates/main i386 Packages [536 kB]
Holen:7 http://de.archive.ubuntu.com/ubuntu xenial-updates/main Translation-en [224 kB]
Holen:8 http://de.archive.ubuntu.com/ubuntu xenial-updates/universe amd64 Packages [483 kB]
Holen:9 http://de.archive.ubuntu.com/ubuntu xenial-updates/universe i386 Packages [468 kB]
Holen:10 http://de.archive.ubuntu.com/ubuntu xenial-updates/universe Translation-en [191 kB]
Holen:11 http://de.archive.ubuntu.com/ubuntu xenial-updates/multiverse amd64 Packages [8.928 B]
Holen:12 http://de.archive.ubuntu.com/ubuntu xenial-updates/multiverse i386 Packages [7.992 B]
Holen:13 http://de.archive.ubuntu.com/ubuntu xenial-backports/main amd64 Packages [4.688 B]
Holen:14 http://de.archive.ubuntu.com/ubuntu xenial-backports/main i386 Packages [4.692 B]
Holen:15 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages [284 kB]
Holen:16 http://security.ubuntu.com/ubuntu xenial-security/main i386 Packages [270 kB]
Holen:17 http://security.ubuntu.com/ubuntu xenial-security/main Translation-en [121 kB]
Holen:18 http://security.ubuntu.com/ubuntu xenial-security/universe amd64 Packages [138 kB]
Holen:19 http://security.ubuntu.com/ubuntu xenial-security/universe i386 Packages [124 kB]
Holen:20 http://security.ubuntu.com/ubuntu xenial-security/universe Translation-en [71,5 kB]
Holen:21 http://security.ubuntu.com/ubuntu xenial-security/multiverse amd64 Packages [2.748 B]
Holen:22 http://security.ubuntu.com/ubuntu xenial-security/multiverse i386 Packages [2.908 B]
Es wurden 3.802 kB in 1 s geholt (2.157 kB/s).
Paketlisten werden gelesen... Fertig
markus@Jarvis3:~$
upgrade:
markus@Jarvis3:~$ sudo apt-get upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Probieren Sie »apt-get -f install«, um dies zu korrigieren.
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
linux-image-extra-4.4.0-78-generic : Hängt ab von: linux-image-4.4.0-78-generic ist aber nicht installiert
linux-signed-image-4.4.0-78-generic : Hängt ab von: linux-image-4.4.0-78-generic (= 4.4.0-78.99) ist aber nicht installiert
E: Unerfüllte Abhängigkeiten. Versuchen Sie, -f zu benutzen.
markus@Jarvis3:~$
-f install
markus@Jarvis3:~$ sudo apt-get -f install
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Abhängigkeiten werden korrigiert ... Fertig
Die folgenden zusätzlichen Pakete werden Installiert
linux-image-4.4.0-78-generic
Vorgeschlagene Pakete:
fdutils linux-doc-4.4.0 | linux-source-4.4.0 linux-tools
Die folgenden NEUEN Pakete werden installiert:
linux-image-4.4.0-78-generic
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 99 nicht aktualisiert.
16 nicht vollständig installiert oder entfernt.
Es müssen 21,9 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 66,8 MB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] J
Holen:1 http://de.archive.ubuntu.com/ubuntu xenial-updates/main amd64 linux-image-4.4.0-78-generic amd64 4.4.0-78.99 [21,9 MB]
Es wurden 21,9 MB in 2 s geholt (10,6 MB/s).
(Lese Datenbank ... 427378 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../linux-image-4.4.0-78-generic_4.4.0-78.99_amd64.deb ...
Done.
Entpacken von linux-image-4.4.0-78-generic (4.4.0-78.99) ...
dpkg: Fehler beim Bearbeiten des Archivs /var/cache/apt/archives/linux-image-4.4.0-78-generic_4.4.0-78.99_amd64.deb (--unpack):
Extrahierte Daten für »./boot/abi-4.4.0-78-generic« können nicht nach »/boot/abi-4.4.0-78-generic.dpkg-new« kopiert werden: Es konnte nicht geschrieben werden (Auf dem Gerät ist kein Speicherplatz mehr verfügbar)
Es wurde kein Apport-Bericht verfasst, da die Fehlermeldung auf einen Fehler wegen voller Festplatte hindeutet.
dpkg-deb: Fehler: Unterprozess einfügen wurde durch Signal (Datenübergabe unterbrochen (broken pipe)) getötet
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 4.4.0-78-generic /boot/vmlinuz-4.4.0-78-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 4.4.0-78-generic /boot/vmlinuz-4.4.0-78-generic
Fehler traten auf beim Bearbeiten von:
/var/cache/apt/archives/linux-image-4.4.0-78-generic_4.4.0-78.99_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
markus@Jarvis3:~$
autoremove:
markus@Jarvis3:~$ sudo apt-get autoremove
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Probieren Sie »apt-get -f install«, um dies zu korrigieren.
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
linux-image-extra-4.4.0-78-generic : Hängt ab von: linux-image-4.4.0-78-generic ist aber nicht installiert
linux-signed-image-4.4.0-78-generic : Hängt ab von: linux-image-4.4.0-78-generic (= 4.4.0-78.99) ist aber nicht installiert
E: Unerfüllte Abhängigkeiten. Versuchen Sie, -f zu benutzen.
markus@Jarvis3:~$
Ich habe das Gefühl, dass die Katze sich hier in den Schwanz beißt:
Kein Platz -> Platz schaffen -> geht nicht, wegen Abhängigkeit -> Abhängigkeit lösen -> geht nicht wegen kein Platz :(
Hat jemand einen Tipp, um das System noch zu retten?
Gruß
Markus
Ist /boot eine eigene Partition? Wie viel Platz ist auf der noch frei und was liegt da alles? Ich glaube übrigens, daß apt-get autoremove alle Kernel-images nicht löscht, das müsstest Du händisch machen.
Zitat von: MarkusAutomaticus am 12 Juni 2017, 10:56:28
Wenn dem so wäre, dann wäre das mal wieder Wasser auf die Mühlen eine zufriedenen Windowsanwenders,
dem Vergleichbares seit über 30 Jahren mit Windows nicht passiert ist.
... dann installier Dir Fhem doch auf Windows ;)
(Sorry, das war ne Steilvorlage. could'nt resist.
Zu Deinem Problem: erstmal wäre es natürlich sinnvoll zu wissen, was für ein System du nutzt. ist die SSD / ? Oder ist sie unter /media eingebunden? Wenn der Speicherplatz von root (also / ) ausgeschöpft ist, ist es kein Wunder, dass nichts mehr funktioniert. Dann heißt es erst mal, wieder etwas Platz zu schaffen (Windows stirbt übrigens erfahrungsgemäß sehr viel schneller, wenn es auf der Platte keinen Platz für seine Auslagerungsdatei mehr hat.
Schau mal nach, ob sich unter /home/<deinusername>/ Dateien befinden, die du nicht mehr benötigst.
cd ~
ls -al
Dann kannst du via
rm <dateiname>
oder
rm -R <ordnername>
unbenötigte Dateien schon mal runterschmeißen.
Hast Du schon mal neugestartet, um temporäre Dateien zu eliminieren? Unter Umständen kann auch ein
rm -R /temp/*
helfen - schau aber vorher mal rein, nicht dass da noch was liegt was du da abgelegt hast. Selbiger Tipp gilt natürlich auch für Dateien und Ordner in deinem Homeverzeichnis.
Ist die SSD unter /media gemountet:
Schiebe (Medien-, etc.) Dateien auf diese. Befindet sich / auf deiner SSD, sollte man mal schauen, warum die SSD dann voll ist - womit wir wieder bei den Infos wären, wie groß die SSD ist, wie sie eingebunden ist und wie viel Platz / noch hat.
Mehr Infos wären hier in der Tat hilfreich.
Was sagt denn df -h
Damit siehst Du, auf welchem Mountpoint noch wie viel frei ist.
Moin moin
eigentlich wollte ich mich noch nicht registrieren, aber da mir dein Problem bekannt vorkam, hab ich das mal vorgezogen und wollte meine Hilfe anbieten.
Ich benutze zu Hause (unter anderem) einen Laptop mit Xubuntu. Alle Nase lang meckert das Gerät, bei Updates, dass kein Plattenspeicher mehr vorhanden ist.
Ich such mir dann folgenden Link raus und lösche alte Kernels
https://askubuntu.com/questions/171209/my-boot-partition-hit-100-and-now-i-cant-upgrade-cant-remove-old-kernels-to
Dort werden verschiedene Wege aufgezeigt, welche man zum Aufräumen nutzen könnte.
Das Problem bei mir ist, dass Xubuntu bei der Installation eine zu kleine Partition angelegt hat und bei den Updates die dann einfach vollkloppt. In meinen Augen ein Fail vom OS, aber egal.
Ich vermute, dass bei dir das gleiche Problem besteht.
Ich würde dir raten, da deine Fehlermeldung ja besagt, dass /boot voll ist, dort zu schauen was da alles drin ist und dann mit Hilfe des Links und dessen Informationen langsam ältere Dateien entfernst bzw. auf eine andere Partition verschiebst.
Da das letzte Update von meinem Laptop etwas her ist, werde ich nachher mal eins durchführen und vielleicht stoße ich ja noch mal auf den Fehler, dann werde ich meine Schritte hier mal genau posten.
BTW. Ich übernehme keine Haftung bei möglichen Schäden oder Einschränkungen an deinem System. Sei vorsichtig und mache zur Not Backups.
Achte darauf was du verschiebst/löschst, ich kann dir nicht sagen welche Auswirkungen es auf das System hat, falls dort was falsches gelöscht wird.
Ich bin da immer eher mit ner Axt rein, da ich den Laptop nicht wirklich produktiv nutze und es bei dem nicht so schlimm ist, wenn ich das OS neu aufsetzen muss.
Wir brauchen mehr Infos:
1. Plattenplatz (und Inodezahl)
df -h
df -hi
2. Was hast Du für Partitionen? Wird Teilweise auch durch 1. erklährt, aber sicherheitshalber:
mount
Btw:
Auch Windows kennt bei NTFS so etwas vergleichbares wie inodes. Das Problem ist nur, das man dieses nicht so einfach rauskriegt ... und auch das Löschen ein größeres Problem. Da man bei Windows selten superviele Kleine Dateien, sondern eher wenige große hat, trifft es seltener im Heimbereich auf.
Das Problem kann man im Vorfeld mit der Wahl des Passenden Dateisystemes (z.B. kennt btrfs keine inodes) oder passenden Parametern (Inodezahl) lösen. Es würde mich abr sehr Wundern, wenn dieses Dein Problem währe.
Und noch etwas:
Wir bringen erstmal Dein System zum laufen. Wie wir dann die Überzähligen Kernelsachen und andere Programme löschen ist ein 2. Thema
Mituname -a raus finden welcher Kernel gebootet wird.
Dann incd /boot alles löschen was nicht zu diesem Kernel gehört.
Beispiel von einem meiner Systeme:root @ cubie :~# uname -a
Linux cubie 4.10.0-22-generic #24-Ubuntu SMP Mon May 22 17:43:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
root @ cubie :~# ls -la /boot
insgesamt 121352
drwxr-xr-x 3 root root 4096 Jun 7 19:34 .
drwxr-xr-x 27 root root 4096 Jun 7 17:42 ..
-rw-r--r-- 1 root root 1443149 Apr 28 12:41 abi-4.10.0-21-generic
-rw-r--r-- 1 root root 1443536 Mai 17 23:13 abi-4.10.0-22-generic
-rw-r--r-- 1 root root 204919 Apr 28 12:41 config-4.10.0-21-generic
-rw-r--r-- 1 root root 204997 Mai 17 23:13 config-4.10.0-22-generic
drwxr-xr-x 5 root root 4096 Jun 7 19:34 grub
-rw-r--r-- 1 root root 41308452 Mai 26 01:48 initrd.img-4.10.0-21-generic
-rw-r--r-- 1 root root 41316952 Jun 7 17:42 initrd.img-4.10.0-22-generic
-rw-r--r-- 1 root root 182704 Jan 28 2016 memtest86+.bin
-rw-r--r-- 1 root root 184380 Jan 28 2016 memtest86+.elf
-rw-r--r-- 1 root root 184840 Jan 28 2016 memtest86+_multiboot.bin
-rw------- 1 root root 3717426 Apr 28 12:41 System.map-4.10.0-21-generic
-rw------- 1 root root 3717887 Mai 17 23:13 System.map-4.10.0-22-generic
-rw------- 1 root root 7575312 Apr 28 12:41 vmlinuz-4.10.0-21-generic
-rw------- 1 root root 7577240 Mai 16 21:52 vmlinuz-4.10.0-21-generic.efi.signed
-rw------- 1 root root 7575312 Mai 17 23:13 vmlinuz-4.10.0-22-generic
-rw------- 1 root root 7577240 Jun 7 17:42 vmlinuz-4.10.0-22-generic.efi.signed
root @ cubie :~#
System bootet mit 4.10.0-22, also alles weg was nicht .........22...... heißt. Äh STOP das Verzeichniss grub bitte NICHT löschen! Voraussetzung ist das dein System mit gebootetem Kernel schon länger und stabil läuft!
Anschließend update-gruboderupdate-grub2und rebooten.
Zum Schluss die Header Files entfernen.
Inodes sind kein Thema, in der Hoffnung das du kein Skript hast das Amok läuft.
Gruß aus L.E.
Uwe
P.S.: Natürlich ist immer das OS Schuld wenn etwas nicht funktioniert auch wenn 10/15/20 Kernelversionen in /boot liegen!
Wobei .. bitte zuerst prüfen, was den die Uhrsache ist (Siehe mein Post 2 davor)
Edit:
Und bitte ins Passende Unterforum. Entweder "Linux-Server" oder "Einplatinencomputer" ... da wird es von den passenden Spezialisten besser gefunden ;D
Also ich sitze gerade an meinem Laptop und habe ebenfalls die Meldung bekommen, dass ich doch mal bitte auf /boot ein bisschen Platz machen soll.
Ich hab mir dann in /boot alle Dateien anzeigen lassen.
Ich hatte noch im Hinterkopf dass ich immer linux-image-X.X.X-XX-generic gelöscht hatte. Diese fand ich aber nicht.
Somit habe ich mir die anderen Dateien angeschaut und zudem noch meine aktuelle Kernelversion mit uname -a herausgefunden (4.4.0-78-generic)
Die anderen Dateien hatten alle ältere Versionen, somit habe ich einfach zwei große Dateien mit einer älteren Versionsnummer ausgesucht und gelöscht.
Löppt! ;)
Ich habe aber wie gesagt /boot auf einer eigenen (zu kleinen) Partition.
++++Nachtrag+++ mit einer besseren Lösung
Ich habe mir eben noch mal Gedanken gemacht, da meine oben beschriebene Möglichkeit nicht wirklich sauber ist.
Somit habe ich noch eine alte Kernel Version gelöscht.
Diesmal aber mittels dpkg
Zuerst habe ich geschaut welche Kernel Versionen noch installiert sind
dpkg -l | grep linux-image
Dann habe ich die älteste Version heraus gesucht und mittels folgenden Befehl entfernt.
sudo dpkg --purge linux-image-extra-4.4.0-59-generic
sudo dpkg --purge linux-image-4.4.0-59-generic
Die mit EXTRA musste ich, auf Grund der Abhängigkeit zuerst entfernen
Danach habe ich noch mal geprüft ob nun die Version entfernt wurde
dpkg -l | grep linux-image
und dann habe ich in /boot geprüft ob die Dateien zu der Version noch vorhanden sind
So habe ich mehr Platz gewonnen
Besser, lösche einfach mal alles sauber, was "nur" deinstalliert, aber nicht gepurged ist:
apt-get autoremove
dpkg --get-selections | grep deinstall
Beim 2. Sieht man eine Lista, WAS alles nun wirklich gepurged werden kann. Auomatisch (NACH dem gucken), get:
apt-get --purge $(dpkg --get-selections | grep deinstall | awk '{print $1}' | xargs)
P.S. Alles aus dem Kopf geschrieben, ungetestet und OHNE Gewähr!!
Zitat von: Wernieman am 15 Juni 2017, 18:43:31
Besser, lösche einfach mal alles sauber, was "nur" deinstalliert, aber nicht gepurged ist:
apt-get autoremove
dpkg --get-selections | grep deinstall
Beim 2. Sieht man eine Lista, WAS alles nun wirklich gepurged werden kann. Auomatisch (NACH dem gucken), get:
apt-get --purge $(dpkg --get-selections | grep deinstall | awk '{print $1}' | xargs)
P.S. Alles aus dem Kopf geschrieben, ungetestet und OHNE Gewähr!!
Klingt besser, gebe ich dir Recht.
Leider funktioniert der letzte Befehl nicht. Ich erhalte folgende Meldung
"E: Command line option --purge is not understood in combination with the other options"
Danke schon mal für die Optimierung :)
Siehe oben, aus dem gedächtnis getippt, es muß so lauten:
apt-get purge $(dpkg --get-selections | grep deinstall | awk '{print $1}' | xargs)
Siehe
man apt-get
jupp hatte ich gerade auch gesehen und entsprechend ausgeführt.
Danke noch mal, das erspart mir bei dem Problem ne Menge Arbeit.
Das mit den Abhängigkeiten ist ja eine sinnvolle Sache, aber wenn man sich plötzlich ma darin verfängt, kommt man schon leicht ins Schwitzen.
Hatte ich letztens auch mit einigen libs, wo dann eins vom anderen abhing, welches wieder, ihr wisst schon.
Hier war ja scheinbar eher der fehlende Plattenplatz das ursächliche Problem.
Es wird ja auch diverse gecached, was da im Laufe der Zeit so runtergeladen wurde.
Mit folgender Kombi kann man da "gucken & machen & wieder gucken", ohne dass man sich gleich mit den Abhängigkeiten rumschlägt.
df -h
apt-get clean
df -h
Hallo zusammen,
vielen Dank für die vielen Tipps und die rege Anteilnahme!
Der einzige Datenträger in meinem NUC ist eine SSD mit 128GB.
Das System wurde mit den Defaults von Ubuntu eingerichtet.
Das Ganze sieht aktuell so aus:
-Mounted File Systems-
udev /dev 0,00 % (3,8 GiB of 3,8 GiB)
tmpfs /run 1,24 % (777,2 MiB of 786,9 MiB)
/dev/mapper/Jarvis3--vg-root / 17,68 % (89,3 GiB of 108,5 GiB)
tmpfs /dev/shm 0,01 % (3,8 GiB of 3,8 GiB)
tmpfs /run/lock 0,08 % (5,0 MiB of 5,0 MiB)
tmpfs /sys/fs/cgroup 0,00 % (3,8 GiB of 3,8 GiB)
/dev/sda2 /boot 100,00 % (0,0 B of 472,6 MiB)
/dev/sda1 /boot/efi 0,68 % (507,5 MiB of 511,0 MiB)
tmpfs /run/user/1000 0,00 % (786,9 MiB of 786,9 MiB)
tmpfs /run/user/111 0,00 % (786,9 MiB of 786,9 MiB)
Anscheind sehen die Defaults ein relativ kleines Boot-Verzeichnis vor, in dem sich dann so lange alte Kernel-Images ansammeln bis es zwangsläufig knallt:
/dev/sda2 /boot 100,00 % (0,0 B of 472,6 MiB)
Hier wäre ein Automatismus clever, der regelmäßig die ältesten Images löscht.
Wenn ich jetzt mit meinen bescheidenen Linux-Kentnissen im boot-Verzeichnis aufräume,
mache ich sicher etwas kaputt.
Kann man vielleicht /dev/sda2 vergrößern?
In Windows würde ich in die Datenträgerverwaltung und mit ein paar Mausclicks die betreffende Partition vergrößern.
Unter Linux habe ich schon mal gparted verwendet, das ist aber nicht drauf und beim Versuch es zu installieren, laufe ich wieder in die Abhängigkeitsfalle.
Gruß
Markus
Nachtrag:
sudo dpkg --get-selections | grep deinstall ergibt folgendes:
markus@Jarvis3:~$ sudo dpkg --get-selections | grep deinstall
linux-image-4.4.0-31-generic deinstall
linux-image-4.4.0-38-generic deinstall
linux-image-4.4.0-42-generic deinstall
linux-image-4.4.0-45-generic deinstall
linux-image-4.4.0-47-generic deinstall
linux-image-4.4.0-51-generic deinstall
linux-image-4.4.0-53-generic deinstall
linux-image-4.4.0-57-generic deinstall
linux-image-4.4.0-59-generic deinstall
linux-image-4.4.0-63-generic deinstall
linux-image-extra-4.4.0-31-generic deinstall
linux-image-extra-4.4.0-38-generic deinstall
linux-image-extra-4.4.0-42-generic deinstall
linux-image-extra-4.4.0-45-generic deinstall
linux-image-extra-4.4.0-47-generic deinstall
linux-image-extra-4.4.0-51-generic deinstall
linux-image-extra-4.4.0-53-generic deinstall
linux-image-extra-4.4.0-57-generic deinstall
linux-image-extra-4.4.0-59-generic deinstall
linux-image-extra-4.4.0-63-generic deinstall
linux-signed-image-4.4.0-31-generic deinstall
linux-signed-image-4.4.0-38-generic deinstall
linux-signed-image-4.4.0-42-generic deinstall
linux-signed-image-4.4.0-45-generic deinstall
linux-signed-image-4.4.0-47-generic deinstall
linux-signed-image-4.4.0-51-generic deinstall
linux-signed-image-4.4.0-53-generic deinstall
linux-signed-image-4.4.0-57-generic deinstall
linux-signed-image-4.4.0-59-generic deinstall
linux-signed-image-4.4.0-63-generic deinstall
heißt das, dass ich alle obigen images löschen kann?
Leider ergibt
sudo apt-get purge $(dpkg --get-selections | grep deinstall | awk '{print $1}' | xargs)
folgendes:
markus@Jarvis3:~$ sudo apt-get purge $(dpkg --get-selections | grep deinstall | awk '{print $1}' | xargs)
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Probieren Sie »apt-get -f install«, um dies zu korrigieren:
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
linux-image-extra-4.4.0-78-generic : Hängt ab von: linux-image-4.4.0-78-generic soll aber nicht installiert werden
linux-signed-image-4.4.0-78-generic : Hängt ab von: linux-image-4.4.0-78-generic (= 4.4.0-78.99) soll aber nicht installiert werden
E: Unerfüllte Abhängigkeiten. Versuchen Sie »apt-get -f install« ohne Angabe eines Pakets (oder geben Sie eine Lösung an).
markus@Jarvis3:~$
Aktueller Kernel ist:
markus@Jarvis3:~$ uname -a
Linux Jarvis3 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Gruß
Markus
Kann Dir leider erst heute Abend helfen .... Da muss ich vorher etwas prüfen ....
Du könntest versuchen, die unerwünschten Kernel-Pakete mit 'dpkg --purge' zu löschen.
dann mach doch einfach mal, was Dein System Dir vorschlägt:
Probieren Sie »apt-get -f install«, um dies zu korrigieren:
und danach das Löschen nochmal.
Wobei Du das Kernel-Image 4.4.0.75 nicht löschen solltest, solange das noch der aktuell laufende Kernel ist.
Siehe Anfang des Threads ... das hat er schon probierte
Edit:
Kannst Du uns bitte Mal geben:ls -lha /boot/
Zitat von: MarkusAutomaticus am 16 Juni 2017, 23:38:40
Hier wäre ein Automatismus clever, der regelmäßig die ältesten Images löscht.
Den Automatismus gibt es, der heißt User bzw. System Adminidstration!
Zitat von: MarkusAutomaticus am 16 Juni 2017, 23:38:40Kann man vielleicht /dev/sda2 vergrößern?
Kann man/frau rate dir aber davon ab.
Zitat von: MarkusAutomaticus am 16 Juni 2017, 23:38:40In Windows würde ich in die Datenträgerverwaltung und mit ein paar Mausclicks die betreffende Partition vergrößern.
Ja is klar Windows kann alles besser.
Zitat von: MarkusAutomaticus am 16 Juni 2017, 23:38:40Unter Linux habe ich schon mal gparted verwendet, das ist aber nicht drauf und beim Versuch es zu installieren, laufe ich wieder in die Abhängigkeitsfalle.
Gibt es auch als Live-CD/USB.
Warum die sda2 vergrößern? Mal davon ab das du LVM verwendest, wobei sich mir nicht erschließt warum, ist das eine Aktion die ich ohne entsprechende Kenntnisse nicht durchführen würde.
Gruß aus L.E.
Uwe
Hallo zusammen,
es ist ein schönes Gefühl, dass wir hier alle so zusammenhalten und uns gegenseitig helfen.
Das wollte ich mal loswerden :)
ls -lha /boot/ ergibt folgendes:
markus@Jarvis3:~$ ls -lha /boot/
insgesamt 442M
drwxr-xr-x 5 root root 5,0K Jun 17 11:11 .
drwxr-xr-x 23 root root 4,0K Jun 17 00:23 ..
-rw-r--r-- 1 root root 1,2M Jan 18 16:59 abi-4.4.0-62-generic
-rw-r--r-- 1 root root 1,2M Feb 20 14:40 abi-4.4.0-64-generic
-rw-r--r-- 1 root root 1,2M Feb 23 21:00 abi-4.4.0-65-generic
-rw-r--r-- 1 root root 1,2M Mär 3 19:25 abi-4.4.0-66-generic
-rw-r--r-- 1 root root 1,2M Mär 22 17:11 abi-4.4.0-70-generic
-rw-r--r-- 1 root root 1,2M Mär 24 16:20 abi-4.4.0-71-generic
-rw-r--r-- 1 root root 1,2M Apr 20 14:02 abi-4.4.0-75-generic
-rw-r--r-- 1 root root 1,2M Apr 27 20:24 abi-4.4.0-78-generic
-rw-r--r-- 1 root root 186K Apr 20 14:02 config-4.4.0-75-generic
-rw-r--r-- 1 root root 186K Apr 27 20:24 config-4.4.0-78-generic
drwx------ 3 root root 4,0K Jan 1 1970 efi
drwxr-xr-x 5 root root 1,0K Jun 17 00:36 grub
-rw-r--r-- 1 root root 40M Jun 17 00:36 initrd.img-4.4.0-62-generic
-rw-r--r-- 1 root root 40M Jun 17 00:36 initrd.img-4.4.0-64-generic
-rw-r--r-- 1 root root 40M Jun 17 00:36 initrd.img-4.4.0-65-generic
-rw-r--r-- 1 root root 40M Jun 17 00:35 initrd.img-4.4.0-66-generic
-rw-r--r-- 1 root root 40M Jun 17 00:35 initrd.img-4.4.0-70-generic
-rw-r--r-- 1 root root 40M Jun 17 00:35 initrd.img-4.4.0-71-generic
-rw-r--r-- 1 root root 40M Jun 17 00:35 initrd.img-4.4.0-75-generic
-rw-r--r-- 1 root root 40M Jun 17 00:34 initrd.img-4.4.0-78-generic
drwx------ 2 root root 12K Okt 6 2016 lost+found
-rw-r--r-- 1 root root 179K Jan 28 2016 memtest86+.bin
-rw-r--r-- 1 root root 181K Jan 28 2016 memtest86+.elf
-rw-r--r-- 1 root root 181K Jan 28 2016 memtest86+_multiboot.bin
-rw------- 1 root root 3,7M Jan 18 16:59 System.map-4.4.0-62-generic
-rw------- 1 root root 3,8M Feb 20 14:40 System.map-4.4.0-64-generic
-rw------- 1 root root 3,8M Feb 23 21:00 System.map-4.4.0-65-generic
-rw------- 1 root root 3,8M Mär 3 19:25 System.map-4.4.0-66-generic
-rw------- 1 root root 3,8M Mär 22 17:11 System.map-4.4.0-70-generic
-rw------- 1 root root 3,8M Mär 24 16:20 System.map-4.4.0-71-generic
-rw------- 1 root root 3,8M Apr 20 14:02 System.map-4.4.0-75-generic
-rw------- 1 root root 3,8M Apr 27 20:24 System.map-4.4.0-78-generic
-rw------- 1 root root 6,8M Feb 3 14:44 vmlinuz-4.4.0-62-generic.efi.signed
-rw------- 1 root root 6,8M Feb 22 11:26 vmlinuz-4.4.0-64-generic.efi.signed
-rw------- 1 root root 6,8M Mär 2 16:21 vmlinuz-4.4.0-65-generic.efi.signed
-rw------- 1 root root 6,8M Mär 8 03:30 vmlinuz-4.4.0-66-generic.efi.signed
-rw------- 1 root root 6,8M Mär 22 17:11 vmlinuz-4.4.0-70-generic
-rw------- 1 root root 6,8M Mär 28 04:22 vmlinuz-4.4.0-70-generic.efi.signed
-rw------- 1 root root 6,8M Mär 24 16:20 vmlinuz-4.4.0-71-generic
-rw------- 1 root root 6,8M Mär 30 16:36 vmlinuz-4.4.0-71-generic.efi.signed
-rw------- 1 root root 6,8M Apr 20 14:02 vmlinuz-4.4.0-75-generic
-rw------- 1 root root 6,8M Jun 17 00:19 vmlinuz-4.4.0-75-generic.efi.signed
-rw------- 1 root root 6,8M Apr 27 20:24 vmlinuz-4.4.0-78-generic
-rw------- 1 root root 6,8M Jun 17 00:23 vmlinuz-4.4.0-78-generic.efi.signed
markus@Jarvis3:~$
Gestern habe ich in meiner Verzweiflung mit sudo rm auf Dateisystemebene die zu den alten Kerneln gehörenden Dateien gelöscht.
Darauf waren diese auch kurzzeitig weg.
Wunderbarerweise waren sie nach einem erneuten apt-get update/upgrade aber alle wieder da und /boot bei 100%
Wtf? >:(
Der Server lebt und will mich ärgern.
apt-get -f install
Wirft folgendes:
markus@Jarvis3:~$ sudo apt-get -f install
[sudo] Passwort für markus:
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 4 nicht aktualisiert.
1 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
initramfs-tools (0.122ubuntu8.8) wird eingerichtet ...
update-initramfs: deferring update (trigger activated)
Trigger für initramfs-tools (0.122ubuntu8.8) werden verarbeitet ...
update-initramfs: Generating /boot/initrd.img-4.4.0-78-generic
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
gzip: stdout: No space left on device
E: mkinitramfs failure cpio 141 gzip 1
update-initramfs: failed for /boot/initrd.img-4.4.0-78-generic with 1.
dpkg: Fehler beim Bearbeiten des Paketes initramfs-tools (--configure):
Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)
markus@Jarvis3:~$
Was ich nicht verstehe, ist folgendes:
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
Was will mir mein bockiges System damit sagen?
Ich finde, ein Betriebssystem sollte einfach nur laufen, sich automatisch aktuell halten und nicht den Anwender von den Anwendungen abhalten.
Ich habe den Ubuntu-Server komplett mit den Standard-Setting eingerichtet, da sollte man nicht in solche Zeitbomben reinlaufen, wenn man einfach nur regelmäßig
apt-get update und apt-get upgrade aufruft
Gruß
Markus
Ich habe keine Lust, hier auf eine Linux vs. Windows-Diskussion einzusteigen. Hast Du das "dpkg --purge" denn mal probiert?
Quelle: https://askubuntu.com/questions/171209/my-boot-partition-hit-100-and-now-i-cant-upgrade-cant-remove-old-kernels-to
So, hab meinen Beitrag mal fix wieder gelöscht und ersetze das einfach durch einen Link:
https://www.thomas-krenn.com/de/wiki/Alte_Kernel_in_Ubuntu_entfernen (https://www.thomas-krenn.com/de/wiki/Alte_Kernel_in_Ubuntu_entfernen)
So wie es aussieht ist das kein Linux-, sondern ein reines (altes) Ubuntu-Problem.
Kenne ich von Debian auch absolut nicht, und da läuft der Server schon zig Jahre.
Jep ... irgendwie kriegen die das nicht hin :o(
Wobei ein purgen aller gelöschten sachen ist trotzdem mal eine gute Idee ...
Das "Problem" kennt RedHat/CentOS auch, hat das aber IMHO einfacher gelöst IMHO:
[root@honstname boot]# ll *-3.10*
-rw-r--r-- 1 root root 137701 Mar 3 01:15 config-3.10.0-514.10.2.el7.x86_64
-rw-r--r-- 1 root root 137701 Apr 12 17:15 config-3.10.0-514.16.1.el7.x86_64
-rw-r--r-- 1 root root 137701 May 25 19:16 config-3.10.0-514.21.1.el7.x86_64
-rw------- 1 root root 45789948 Mar 9 19:52 initramfs-3.10.0-514.10.2.el7.x86_64.img
-rw------- 1 root root 18406265 Apr 5 18:14 initramfs-3.10.0-514.10.2.el7.x86_64kdump.img
-rw------- 1 root root 45792366 Apr 14 11:21 initramfs-3.10.0-514.16.1.el7.x86_64.img
-rw------- 1 root root 45792178 Jun 7 15:28 initramfs-3.10.0-514.21.1.el7.x86_64.img
-rw-r--r-- 1 root root 277969 Mar 3 01:17 symvers-3.10.0-514.10.2.el7.x86_64.gz
-rw-r--r-- 1 root root 277943 Apr 12 17:18 symvers-3.10.0-514.16.1.el7.x86_64.gz
-rw-r--r-- 1 root root 277955 May 25 19:18 symvers-3.10.0-514.21.1.el7.x86_64.gz
-rw------- 1 root root 3112473 Mar 3 01:15 System.map-3.10.0-514.10.2.el7.x86_64
-rw------- 1 root root 3113648 Apr 12 17:15 System.map-3.10.0-514.16.1.el7.x86_64
-rw------- 1 root root 3114102 May 25 19:16 System.map-3.10.0-514.21.1.el7.x86_64
-rwxr-xr-x 1 root root 5393008 Mar 3 01:15 vmlinuz-3.10.0-514.10.2.el7.x86_64*
-rwxr-xr-x 1 root root 5396240 Apr 12 17:15 vmlinuz-3.10.0-514.16.1.el7.x86_64*
-rwxr-xr-x 1 root root 5397552 May 25 19:16 vmlinuz-3.10.0-514.21.1.el7.x86_64*
[root@hostname boot]# package-cleanup --oldkernels --count=1
Loaded plugins: fastestmirror
Not removing kernel 3.10.0-514.10.2.el7 because it is the running kernel
--> Running transaction check
---> Package kernel.x86_64 0:3.10.0-514.16.1.el7 will be erased
---> Package kernel-devel.x86_64 0:3.10.0-514.16.1.el7 will be erased
--> Finished Dependency Resolution
Dependencies Resolved
=========================================================================================================================================
Package Arch Version Repository Size
=========================================================================================================================================
Removing:
kernel x86_64 3.10.0-514.16.1.el7 @updates 148 M
kernel-devel x86_64 3.10.0-514.16.1.el7 @updates 34 M
Transaction Summary
=========================================================================================================================================
Remove 2 Packages
Installed size: 182 M
Is this ok [y/N]:
@MarkusAutomaticus
hast Du die dpkg --purge sache jetzt mal gemacht oder nicht?
Hallo zusammen,
ich habe mir mit den kryptischen Befehlen von hier geholfen:
https://wiki.ubuntuusers.de/Skripte/Alte_Kernel_entfernen/ (https://wiki.ubuntuusers.de/Skripte/Alte_Kernel_entfernen/)
ls -lha /boot/ ergibt jetzt:
markus@Jarvis3:/boot$ ls -lha /boot/
insgesamt 130M
drwxr-xr-x 5 root root 5,0K Jun 18 14:38 .
drwxr-xr-x 23 root root 4,0K Jun 18 14:38 ..
-rw-r--r-- 1 root root 1,2M Apr 27 20:24 abi-4.4.0-78-generic
-rw-r--r-- 1 root root 1,2M Mai 18 00:09 abi-4.4.0-79-generic
-rw-r--r-- 1 root root 186K Apr 27 20:24 config-4.4.0-78-generic
-rw-r--r-- 1 root root 186K Mai 18 00:09 config-4.4.0-79-generic
drwx------ 3 root root 4,0K Jan 1 1970 efi
drwxr-xr-x 5 root root 1,0K Jun 18 14:38 grub
-rw-r--r-- 1 root root 12M Jun 18 14:38 initrd.img-4.4.0-75-generic
-rw-r--r-- 1 root root 40M Jun 17 00:34 initrd.img-4.4.0-78-generic
-rw-r--r-- 1 root root 40M Jun 18 14:38 initrd.img-4.4.0-79-generic
drwx------ 2 root root 12K Okt 6 2016 lost+found
-rw-r--r-- 1 root root 179K Jan 28 2016 memtest86+.bin
-rw-r--r-- 1 root root 181K Jan 28 2016 memtest86+.elf
-rw-r--r-- 1 root root 181K Jan 28 2016 memtest86+_multiboot.bin
-rw------- 1 root root 3,8M Apr 27 20:24 System.map-4.4.0-78-generic
-rw------- 1 root root 3,8M Mai 18 00:09 System.map-4.4.0-79-generic
-rw------- 1 root root 6,8M Apr 27 20:24 vmlinuz-4.4.0-78-generic
-rw------- 1 root root 6,8M Jun 17 00:23 vmlinuz-4.4.0-78-generic.efi.signed
-rw------- 1 root root 6,8M Mai 18 00:09 vmlinuz-4.4.0-79-generic
-rw------- 1 root root 6,8M Jun 18 14:38 vmlinuz-4.4.0-79-generic.efi.signed
markus@Jarvis3:/boot$
Ich traue mich jetzt nur nicht so recht, die Mühle zu rebooten, in der Angst, dass sie jetzt nicht mehr hoch fährt.
Souveränes Arbeiten mit einem Betriebssystem sieht anders aus.
Bei Windows weiß ich was ich tue.
Unix ist für mich nur Mittel zum Zweck und dafür verlangt es für meinen Geschmack viel zu viel Aufmerksamkeit.
Viele Grüße
Markus
Wenn Du von Windiows so begeistert bist, dann nimm Windows ... und meckere nicht, wenn Dein Windows durch updates immer langsamer wird .... wenn Du es nie pflegst!
Und wie sieht jetzt die Plattenbelegung aus, nachdem Du durch bist? Hast Du noch Probleme?
df -h
apt-get -f install
Und BITTE, Unterscheide ENDLICH zwischen Ubuntu (Dein Problem) und Linux ... Durch Dein Meckern (und langsamen Antworten) vergeht mir langsam die Lust
P.S. Was für eine Ubuntuversion hast Du eigentlich? Dieser Fehler wird eigentlich schon sehr lange anders gelöst ....
cat /etc/lsb-release
Zitat von: MarkusAutomaticus am 18 Juni 2017, 15:00:21
...Ich traue mich jetzt nur nicht so recht, die Mühle zu rebooten, in der Angst, dass sie jetzt nicht mehr hoch fährt.
Wenn die mit dem aktuell verwendeten Kernel sauber läuft und Du nichts anderes gelöscht hast, sollte auch ein Neustart problemlos funktionieren.
Wenn Du schon kryptische Befehle von anderen Seiten als die hier genannten Tipps verwendest, dann doch einfach denn, der alle Kernel-Pakete ausser dem aktuell verwendeten löscht. Dann hast Du wieder einen sauberen Stand.
Zitat
Souveränes Arbeiten mit einem Betriebssystem sieht anders aus.
Bei Windows weiß ich was ich tue...
Da hast Du recht, dieser Fehler im Klicki-Linux ist ärgerlich.
In der Regel läuft auch ein Linux problemlos, kann natürlich auch mal zicken.
Welches Server-Windows nutzt Du und wie viele Kernel hast Du da installiert bzw. auswählbar? ;)
Hat alles seine Vor- und Nachteile, jeder soll das nutzen was für ihn und den Zweck am Sinnvollsten ist.
Hallo zusammen,
Ich möchte mich für das Ubuntu/Linux - Bashing entschuldigen.
Es ist halt so, dass ich mir die Zeit für mein Smarthome-hobby vom Mund absparen muss.
Dass ich mich da lieber mit Fhem und Sensoren/Aktoren, als mit Linux-Interna beschäftigte, liegt auf der Hand.
Gruß
Markus
Kein Problem.
Wenn einen die leichte Panik befällt, weil man allein nicht weiter kommt, eskaliert es halt leicht mal. ;D
ZitatUbuntu 16.04
Damit sollte das Problem aber eigentlich gar nicht mehr auftreten. Kann es sein, daß Du ursprünglich mal eine ältere Ubuntu-Version installiert hattest?
Genau das ist auch meine Vermutung ... Ubuntu 16.04 baut im Normalfall keine /boot Partition mehr ...
Läuft jetzt eigentlich das System oder nicht?
Zitat von: mahowi am 19 Juni 2017, 09:36:45
Damit sollte das Problem aber eigentlich gar nicht mehr auftreten. Kann es sein, daß Du ursprünglich mal eine ältere Ubuntu-Version installiert hattest?
Im "Standard" sind IMHO auch keine backports aktiviert. ;)
.. habe ich etwas überlesen? Woran siehst Du das?
Vermutlich aus dem dritten Beitrag hier im Thread:
Holen:13 http://de.archive.ubuntu.com/ubuntu xenial-backports/main amd64 Packages [4.688 B]
Holen:14 http://de.archive.ubuntu.com/ubuntu xenial-backports/main i386 Packages [4.692 B]
Hallo zusammen,
wenn ich mich recht erinnere, bin ich im Herbst 2016 vom Raspi3 auf den Intel-NUC umgezogen.
Dabei habe ich als OS den damals aktuellen Ubuntu-Server installiert.
Da ich mich mit Linux nicht auskenne, wäre ich wohl kaum von alleine auf die Idee gekommen, 3 Partitionen mit unterschiedlichen Dateisystemen anzulegen.
Daher gehe ich davon aus, dass die Ubuntu-Installation diese so angelegt hat.
Ich habe zwischenzeitlich versucht mit Gparted die einzelnen Partitionen etwas sinnvoller zu dimensionieren.
Aber das klappt nicht so ohne weiteres. Vermutlich muss ich die /boot zuvor unmounten?
Aber bekomme ich diese dann wieder eingehängt?
Letztlich habe ich mir mit dem Löschen der alten Kernel ja nur wieder etwas Zeit verschaft.
Über kurz oder lang, wird /boot wieder voll sein.
Gruß
Markus
Wenn du die Partitionen mit gpartet ändern willst, müssen die Partitionen oder das gesamte LW ausgehangen sein, also am besten einen Rechner mit einer gepartet CD starten und dein fhem-host Laufwerk über einen usb adapter oder wie auch immer an den Rechner mit der Live CD stecken und dann von der CD booten. Damit kannst du die Partitionen ändern.
VG
Frank
Zitat von: MarkusAutomaticus am 19 Juni 2017, 15:50:16
Da ich mich mit Linux nicht auskenne, wäre ich wohl kaum von alleine auf die Idee gekommen, 3 Partitionen mit unterschiedlichen Dateisystemen anzulegen.
Daher gehe ich davon aus, dass die Ubuntu-Installation diese so angelegt hat.
Daher auch die LVM Konfigurtation.
Zitat von: MarkusAutomaticus am 19 Juni 2017, 15:50:16
Ich habe zwischenzeitlich versucht mit Gparted die einzelnen Partitionen etwas sinnvoller zu dimensionieren.
Aber das klappt nicht so ohne weiteres. Vermutlich muss ich die /boot zuvor unmounten?
Las dass! Ich wäre mir nicht sicher ob du da nicht deiner LVM Konfiguration quer kommst.
Sollte es dir wieder eng werden in /boot kannst du den Inhalt (mit dem einen oder andern Umweg) auf dein root Volume verschieben. Dann hast du aber eine leere Partition mit ca. 500MB mit der du evtl. nichts anfangen kannst.
Das sauberste wäre neuinstallieren. Ja is Sch....e aber dann ohne LVM ohne /boot (in eigener Partition). Mit nem Backup und Restore ist das in 1 Stunde erledigt,
Gruß aus L.E.
Uwe
1. Dieses ist so jedenfalls KEINE Standardinstallation
2. Hast Du die backports installiert?
3. was sagt denn jetzt
dpkg --get-selections | grep deinstall