Erzwingen Sie das Entfernen unerwünschter Linux-Image-Extra * -Pakete

7

Um eine machen lange Geschichte kurz, bin ich mit einer Handvoll von unerwünschten, halb konfigurierten Bildpakete fest , dass ich versuche, sie wieder loszuwerden:

$ dpkg -l |grep linux-im
iF  linux-image-3.13.0-100-generic       3.13.0-100.147 i386 Linux kernel image for version 3.13.0 on 32 bit x86 SMP
iF  linux-image-3.13.0-101-generic       3.13.0-101.148 i386 Linux kernel image for version 3.13.0 on 32 bit x86 SMP
iF  linux-image-3.13.0-92-generic        3.13.0-92.139  i386 Linux kernel image for version 3.13.0 on 32 bit x86 SMP
iF  linux-image-3.13.0-93-generic        3.13.0-93.140  i386 Linux kernel image for version 3.13.0 on 32 bit x86 SMP
iF  linux-image-3.13.0-96-generic        3.13.0-96.143  i386 Linux kernel image for version 3.13.0 on 32 bit x86 SMP
iH  linux-image-extra-3.13.0-100-generic 3.13.0-100.147 i386 Linux kernel extra modules for version 3.13.0 on 32 bit x86 SMP
iH  linux-image-extra-3.13.0-101-generic 3.13.0-101.148 i386 Linux kernel extra modules for version 3.13.0 on 32 bit x86 SMP
iH  linux-image-extra-3.13.0-92-generic  3.13.0-92.139  i386 Linux kernel extra modules for version 3.13.0 on 32 bit x86 SMP
iH  linux-image-extra-3.13.0-93-generic  3.13.0-93.140  i386 Linux kernel extra modules for version 3.13.0 on 32 bit x86 SMP
iH  linux-image-extra-3.13.0-96-generic  3.13.0-96.143  i386 Linux kernel extra modules for version 3.13.0 on 32 bit x86 SMP

Diese Images sind in der Tat nutzlos, da mein 32-Bit-14.04-System in einem OpenVZ-Container lebt, der allein für den Kernel verantwortlich ist. Wie Sie sehen können, eine viel ältere:

$ uname -r
2.6.32-042stab116.2

Im Gegensatz zu den meisten ähnlichen Fragen, die sich darauf konzentrieren, wie alte Kernel-Images nach routinemäßigen Upgrades entfernt werden können, versuche ich hier, ALLE DIESEN 3.13-PAKETE VOLLSTÄNDIG ZU LÖSCHEN , die eigentlich gar nicht vorhanden sein sollten.

Hier ist eine Zusammenfassung meiner bisherigen Versuche.

Der Versuch , die Pakete zu entfernen / reinigen die üblichen Wege ( apt-get, apt, aptitude, es spielt keine Rolle) scheint nicht zu arbeiten, aufgrund eines offensichtlichen Teufelskreis.

sudo apt-get purge linux-image-3.13.0-100-generic linux-image-3.13.0-101-generic linux-image-3.13.0-92-generic linux-image-3.13.0-93-generic linux-image-3.13.0-96-generic linux-image-extra-3.13.0-100-generic linux-image-extra-3.13.0-101-generic linux-image-extra-3.13.0-92-generic linux-image-extra-3.13.0-93-generic linux-image-extra-3.13.0-96-generic

Wie Sie der Ausgabe entnehmen können , wird nichts entfernt. Auf der anderen Seite aptitudeschafft es ein wenig weiter zu kommen:

sudo aptitude purge linux-image-3.13.0-100-generic linux-image-3.13.0-101-generic linux-image-3.13.0-92-generic linux-image-3.13.0-93-generic linux-image-3.13.0-96-generic linux-image-extra-3.13.0-100-generic linux-image-extra-3.13.0-101-generic linux-image-extra-3.13.0-92-generic linux-image-extra-3.13.0-93-generic linux-image-extra-3.13.0-96-generic

Am Ende dieses Vorgangs sind die *image-3.13*s verschwunden, zusammen mit übereinstimmenden Dateien und Ordnern, die normalerweise in /bootund in gefunden /lib/moduleswerden. Die image-extras werden jedoch weiterhin als halbinstalliert gemeldet (obwohl sie scheinbar keine Dateien enthalten, wie durch dpkg -L... )

Darüber hinaus werden Abhängigkeiten jetzt aufgehoben, da das Wiederholen der Bereinigung in dieser Phase dazu führt, dass Sie sich über fehlende Dateien / Ordner in /bootund in beschweren /lib/modules. Ich habe versucht, Dummy-Dateien an den erwarteten Speicherorten zu platzieren, wie hier vorgeschlagen , aber am Ende bin ich auf die ursprünglichen Fehler gestoßen. Ich glaube, das Folgende ist der entscheidende Auszug:

[...]
Removing linux-image-extra-3.13.0-101-generic (3.13.0-101.148) ...
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 3.13.0-101-generic /boot/vmlinuz-3.13.0-101-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.13.0-101-generic /boot/vmlinuz-3.13.0-101-generic
update-initramfs: Generating /boot/initrd.img-3.13.0-101-generic
E: /usr/share/initramfs-tools/hooks/fixrtc failed with return 1.
update-initramfs: failed for /boot/initrd.img-3.13.0-101-generic with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: error processing package linux-image-extra-3.13.0-101-generic (--purge):
subprocess installed post-removal script returned error exit status 1
[...]

Nachdem erfolglos versucht wurde, eine angeblich nukleare Option zu wählen :

sudo dpkg --remove --force-remove-reinstreq package_name

Mir gingen die Ideen aus.

14.04  apt  kernel  dpkg  openvz 
— Giuseppe
quelle
Ich habe ein bisschen unter der Haube gegraben, und ich habe die Vermutung, dass der Fehler durch das dpgkAusführen der Skripte verursacht wird /etc/kernel/postrm.d.
— Yeedle

Antworten:

3

Vorausgesetzt, dass:

  • die linux-image-3.13.0-XXX-genericwurden erfolgreich gelöscht
  • Die linux-image-extra-3.13.0-XXX-genericwerden immer noch als halb installiert gemeldet
  • nicht aktuell installierten Pakete hängen von diesen image-extras
  • Keines dieser Images sollte überhaupt vorhanden sein (da der 2.6-Kernel vom Host-OpenVZ-Container bereitgestellt wird).
  • Keiner der traditionellen Versuche gelingt es, das System zu reinigen

Dann besteht ein möglicher Ansatz darin, diese baumelnden Einträge dpkgwie hier vorgeschlagen zwangsweise aus der Datenbank zu entfernen .

BITTE BEACHTEN SIE: Dies ist eine hackige, niedrige, potenziell gefährliche Operation.

  • Suchen Sie nach Dateien, die zu dem Paket gehören, das Sie entfernen möchten (versuchen Sie es $ dpkg -L linux-image-extra-3.13.0-XXX-generic), und löschen Sie sie
  • Öffnen Sie die Datei /var/lib/dpkg/status, suchen und löschen Sie die Textblöcke, die die Pakete beschreiben, die dpkg vergessen soll
  • Seien Sie besonders vorsichtig, wenn Sie Leerzeilen zwischen Paketdeskriptoren, Leerzeichen am Zeilenanfang usw. beibehalten. Sie sagen, dass die apt-Datenbank keine Tippfehler enthält.
  • Nach dem Speichern der Statusdatei sollten dpkgalle aptzugehörigen Programme wieder normal sein
— Giuseppe
quelle
0

Dabei ls /bootsollten einige vmlinuz-X.XX.XXDateien angezeigt werden . Tun Sie dies apt-get purge linux-image-X.XX.XX-genericfür jeden, aber ENTFERNEN SIE NICHT den Kernel, den Sie ausführen . Sie können überprüfen, mit welchem uname -r.

@ Zanna Frage behoben.
cool, ich schlage vor, auch einen Ersatzkernel zu lassen
— Zanna
2
@ MarkYisri, der /bootOrdner zeigt überhaupt keine Einträge. Wie ich geschrieben habe, läuft Ubuntu in einem OpenVZ-Container und der Kernel (siehe Q) gehört zum Host, ich habe keine Kontrolle darüber. Auch das Versagen apt-get purgedieser irrelevanten Pakete ist das Wesentliche des Problems, das beschrieben wird.
— Giuseppe
0

Ich verwende Folgendes in einem Bash-Skript, um alles außer dem aktiven Kernel zu zerstören: 

dpkg -l linux-* | awk '/^ii/{ print $2}' | grep -v -e "$(uname -r | cut -f1,2 -d"-")" | grep -e "[0-9]" | grep -E "(image|headers)" | xargs sudo apt-get -y purge

Es ist ziemlich nah an dem, was Sie aufgerufen haben, aber vielleicht dpkgist es der notwendige Unterschied.

Die vollständigen Skripte finden Sie bei Interesse hier:
https://github.com/mtompkins/linux-kernel-utilities

— Kennzeichen
quelle
Soweit ich das beurteilen kann, wird diese Zeile einfach apt-get purgefür alle zutreffenden Pakete aufgerufen. Das habe ich schon mehrfach versucht, ohne Erfolg.
— Giuseppe
Das ist in der Tat alles, aber ich war mir nicht sicher, ob Sie die Paketnamen in gewissem Sinne richtig übergeben haben, und hoffte, dass der dpkgAufruf damit umgehen könnte. Keine Sorge.
— Mark
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.