staging.inyokaproject.org

Hallöle,

ich glaube im Wiki-Artikel zwei Fehler entdeckt zuhaben. Der erste betrifft den Befehl:

dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' 

Hier heißt es im Wiki, dass alle alte Kernelversionen aufgelistet werden, bis auf die letzten zwei. Und das stimmt so nicht. Es werden alle Versionen aufgelistet bis auf die letzte die aktuelle. Entsprechend werden dann natürlich auch mit dem Befehlszusatz

 xargs sudo apt-get -y purge

alle Kernel entfernt und man hat keinen weiteren Kernel für den Fall der Fälle zur Hand.

Als Beweis meiner Behauptung die Ausgabe meines Rechners.

uname -a

Linux Flachmann 3.2.0-60-generic #91-Ubuntu SMP Wed Feb 19 03:54:44 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d'

linux-headers-3.2.0-49
linux-headers-3.2.0-49-generic
linux-headers-3.2.0-51
linux-headers-3.2.0-51-generic
linux-headers-3.2.0-52
linux-headers-3.2.0-52-generic
linux-headers-3.2.0-53
linux-headers-3.2.0-53-generic
linux-headers-3.2.0-54
linux-headers-3.2.0-54-generic
linux-headers-3.2.0-55
linux-headers-3.2.0-55-generic
linux-headers-3.2.0-56
linux-headers-3.2.0-56-generic
linux-headers-3.2.0-57
linux-headers-3.2.0-57-generic
linux-headers-3.2.0-58
linux-headers-3.2.0-58-generic
linux-headers-3.2.0-59
linux-headers-3.2.0-59-generic
linux-image-3.2.0-49-generic
linux-image-3.2.0-51-generic
linux-image-3.2.0-52-generic
linux-image-3.2.0-53-generic
linux-image-3.2.0-54-generic
linux-image-3.2.0-55-generic
linux-image-3.2.0-56-generic
linux-image-3.2.0-57-generic
linux-image-3.2.0-58-generic
linux-image-3.2.0-59-generic

Um doch noch den einen oder anderen Kernel, neben dem aktuellen zu behalten, muss, wie Tuxlog schreibt, der Befehl nur erweitert werden:

dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' > kernelliste

Die vorhandenen Kernel werden dadurch in die Datei „kernelliste“ geschrieben. Aus der Datei, die man im /home findet, dann die Kernel löschen die man behalten möchte, abspeichern und mit dem Befehl

cat kernelliste | xargs sudo apt-get -y purge

die Kernel entfernen. Als Beweis, dass das funktioniert, muss wieder mein Rechner herhalten:

dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d'
linux-headers-3.2.0-59
linux-headers-3.2.0-59-generic
linux-image-3.2.0-59-generic
uname -a
Linux Flachmann 3.2.0-60-generic #91-Ubuntu SMP Wed Feb 19 03:54:44 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Das zweite ist eigentlich kein Fehler, sondern eher der Hinweis, dass man die Kernel sehrwohl aus dem Softwarecenter heraus entfernen kann. Zumindest bei mir werden oder besser wurden die installierten Kernel schön säuberlich, nach Eingabe des Suchbegriffs „linux-image-3.2.0-“ bzw „linux-headers-3.2.0-“, mit einem Häkchen versehen, aufgelistet. Ok, etwas scrollen und suchen muss man dann schon noch, auch sind zwei Deinstallationsschritte nötig, aber es geht.

VlG Dimanche

Ich möchte diesen Beitrag nochmals nach vorne holen.

Dimanche schrieb:

ich glaube im Wiki-Artikel zwei Fehler entdeckt zuhaben. Der erste betrifft den Befehl:

dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' 

Hier heißt es im Wiki, dass alle alte Kernelversionen aufgelistet werden, bis auf die letzten zwei. Und das stimmt so nicht. Es werden alle Versionen aufgelistet bis auf die letzte die aktuelle. Entsprechend werden dann natürlich auch mit dem Befehlszusatz

 xargs sudo apt-get -y purge

alle Kernel entfernt und man hat keinen weiteren Kernel für den Fall der Fälle zur Hand.

Da dieser Befehl immer wieder unbedarften Anwendern zur Deinstallation alter Kernel mit der Bemerkung "Bis auf die letzten zwei" empfohlen wird, dabei aber tatsächlich alle Kernel bis auf den aktuellen gelöscht werden, halte ich das für gefährlich.

Es sollte entweder die vom Vorposter vorgeschlagene Lösung ins Wiki übernommen oder der Befehl entsprechend angepasst werden, so dass er wie beschrieben funktioniert.

Eben in einer LTrusty-VM extra einige zusätzliche Kernels installiert, um über die lange Befehlszeile zu deinstallieren:

$ dpkg -l linux-image-3* | grep ii
ii  linux-image-3.13.0-30-generic        3.13.0-30.55                                i386         Linux kernel image for version 3.13.0 on 32 bit x86 SMP
ii  linux-image-3.13.0-32-generic        3.13.0-32.57                                i386         Linux kernel image for version 3.13.0 on 32 bit x86 SMP
ii  linux-image-3.15.0-6-generic         3.15.0-6.11                                 i386         Linux kernel image for version 3.15.0 on 32 bit x86 SMP
ii  linux-image-3.16.0-5-generic         3.16.0-5.10                                 i386         Linux kernel image for version 3.16.0 on 32 bit x86 SMP
ii  linux-image-3.16.0-6-generic         3.16.0-6.11                                 i386         Linux kernel image for version 3.16.0 on 32 bit x86 SMP
$ dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' | xargs sudo apt-get -y purge
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  linux-generic* linux-headers-3.13.0-30* linux-headers-3.13.0-30-generic*
  linux-headers-3.13.0-32* linux-headers-3.13.0-32-generic*
  linux-headers-3.15.0-6* linux-headers-3.15.0-6-generic*
  linux-headers-3.16.0-5* linux-headers-3.16.0-5-generic*
  linux-headers-generic* linux-image-3.13.0-30-generic*
  linux-image-3.13.0-32-generic* linux-image-3.15.0-6-generic*
  linux-image-3.16.0-5-generic* linux-image-extra-3.13.0-30-generic*
  linux-image-extra-3.13.0-32-generic* linux-image-extra-3.15.0-6-generic*
  linux-image-extra-3.16.0-5-generic* linux-image-generic*
0 upgraded, 0 newly installed, 19 to remove and 8 not upgraded.
After this operation, 899 MB disk space will be freed.

{snip}

$ dpkg -l linux-image-3* | grep ii
ii  linux-image-3.16.0-6-generic         3.16.0-6.11                                 i386         Linux kernel image for version 3.16.0 on 32 bit x86 SMP

Also nachvollziehbar. Das mit der manuell zu editierenden kernellist-Datei halte ich jedoch für äußerst unpraktisch, insbesondere wenn Linux-Beginner das noch zusätzlich zur schon kryptischen Befehlszeile durchführen sollen. Es sollte daher diese Befehlszeile selbst verbessert werden.

axt schrieb:

Es sollte daher diese Befehlszeile selbst verbessert werden.

Ja. Nur sehr kompliziert und ohne tiefere Kenntnisse in Sachen shell-script nahezu unmöglich.

rklm wäre ein Spezi für solche Dinge.

axt schrieb:

Eben in einer LTrusty-VM extra einige zusätzliche Kernels installiert, um über die lange Befehlszeile zu deinstallieren:

  linux-generic*
  linux-headers-generic* 

Warum eigentlich die Metapakete mit deinstallieren?

Theoretisch könnte man sich bei Ubuntu auch der grub.cfg bemächtigen und ein superlanges Ferkelskript basteln:

1

dpkg -l $(grep "recovery mode" /boot/grub/grub.cfg | cut -d" " -f5 | grep -v $(uname -r) | sed -e '1,1d' -e s/^/*/ -e s/'-generic'/*/) | grep ii | awk '{print $2}' | xargs sudo apt-get purge -y

🙄

Hans9876543210 schrieb:

Warum eigentlich die Metapakete mit deinstallieren?

Ich habe nicht gesagt, daß man das soll. Die Zeile ist nicht mein Geschöpf. 😉 (Dann würde ich mich ja darum kümmern können.)

Aber gut, daß Du das erwähnst, sprich wenn wir wieder in einem Thread die Zeile bringen, dann gleich die Metapakete wieder installieren (das sind ja nun keine Riesendateien).

❗ Warnung!

Deine Befehlszeile bringt nach einer Weile Rödeln in einer LTrusty/32-VM:

0 upgraded, 0 newly installed, 1402 to remove and 0 not upgraded.
After this operation, 2.467 MB disk space will be freed.
E: There are problems and -y was used without --force-yes

Kein schlechter Ansatz,Hans9876543210. Primär soll es darum gehen, den vorletzten Kernel zu erhalten. Ich habe mich zwar mit der Zeile befasst, allerdings muß ich gestehen, dass dies meine Fähigkeiten übersteigt.

axt schrieb:

❗ Warnung!

Deine Befehlszeile bringt nach einer Weile Rödeln in einer LTrusty/32-VM:

0 upgraded, 0 newly installed, 1402 to remove and 0 not upgraded.
After this operation, 2.467 MB disk space will be freed.
E: There are problems and -y was used without --force-yes

Ach Mist, das liegt daran, das wenn er weniger als 2 Kernel findet, er dann ein Nullwert an dpkg liefert. 😳 dpkg denkt dann: jo, alles klar. Ich nehm alles. Daher kommen die 1402 Pakete. Das solls natürlich nicht sein.

1

dpkg -l "linux-"$(grep "recovery mode" /boot/grub/grub.cfg | cut -d" " -f5 | grep -v $(uname -r) | sed -e '1,1d' -e s/^/*/ -e s/'-generic'/*/) | grep ii | awk '{print $2}' | xargs sudo apt-get purge -y -s

🙄

axt schrieb:

Deine Befehlszeile bringt nach einer Weile Rödeln in einer LTrusty/32-VM:

0 upgraded, 0 newly installed, 1402 to remove and 0 not upgraded.
After this operation, 2.467 MB disk space will be freed.
E: There are problems and -y was used without --force-yes

und freu dich doch soviel Platz zum frei werden. 😈

Falscher Button 😳

Hans9876543210 schrieb:

wenn er weniger als 2 Kernel findet,

Da sind derzeit 2 Kernels installiert (der aktuelle von Trusty und der aktuelle von Utopic).

Knarf68, bei 1402 Paketen in dieser VM dürfte er alles erschlagen. Wäre ja sogar interessant, was zurückbleibt. Empty. 😉

axt schrieb:

Da sind derzeit 2 Kernels installiert (der aktuelle von Trusty und der aktuelle von Utopic).

Genau. Da sollte dann auch mit der korrigierten Version keine Ausgabe kommen.

Hans9876543210 schrieb:

weniger als 2 Kernel findet

Also bei 2 Kernel und weniger. 😇

Wäre schön zu Wissen ob sich dpkg selber deinstallieren kann.

Ich bin schon lange über die Phase hinaus, in der ich solche Befehle cool und witzig fand:

dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' | xargs sudo apt-get -y purge 

Wenn es so schwierig ist Informationen herauszufiltern, ist das ein Zeichen dafür dass man das falsche Interface verwendet. Auch ist die Ausgabe von dpkg -l 'linux-*' nicht zu Parsen durch Skripts gedacht, schaut euch mal die Ausgabe davon an, vielleicht fällt euch ja was auf.

Die Diskussion hatten wir hier übrigens schon einmal.

Hallo,

ich habe den Abschnitt Problemlösungen eingefügt, da ich es leid bin, im Forum zu diesem Problem nicht einfach auf's Wiki verlinken zu können und das hier sinnvoll finde. Ich möchte Supporter durch Optimierung entlasten.

Dazu gehört auch eine optimale Vernetzung. Die Problemlösung habe ich im Artikel Kernel eingefügt, weil das Problem bei der Installation von Kernels auftritt und diese sich nicht mehr deinstallieren lassen - und hier würde ein Hilfesuchender dann zuerst suchen. Das Installieren neuer Kernel ist die Ursache. Die Wirkung dagegen ist eine defekte Paketverwaltung - auch dort gehört ein Hinweis hin, allerdings kann dann auch die /-Partition mit normalen Updates vollgelaufen sein. Erledigt: /Paketverwaltung/Problembehebung#Voller-Speicher-verhindert-die-Deinstallation-von-Paketen.

Der Artikel Systempflege bekam auch einen kurzen Hinweis im Abschnitt Systempflege#Problemloesungen.

Wenn jemand eine bessere Lösung weiß, dann bitte melden oder machen. Ich hab mir Gedanken dazu gemacht und sehe das als Vorschlag an, der gerne angenommen oder optimiert werden kann. Nur Nichtstun ist auch keine Lösung, daher hab ich nun diese gefunden und bewusst so umgesetzt, was nicht heißt, dass das für alle Ewigkeit exakt so bleiben soll.

Die drei Stellen halte ich für die Vernetzung wichtig, damit Hilfesuchende und Supporter schneller eine Lösung an den richtigen Stellen finden, die ja durchaus mehrere sein können.

Grüße, Benno

Edit:

Mit Grub oder Partitionierung hat es ja nichts direkt zu tun, also gehört es in diese Artikel. Und Systempflege ist zu präventiv und einseitig orientiert, daher kein Rücklink von Kernel auf Systempflege, da die Sichtweise nach der bereits eingetretenen Panne fehlt und einige Aspekte wie reservierte Blöcke auch, andere wiederum wie Papierkorb sind schon in meinem Hinweis auf Homeverzeichnis verlinkt (in Paketverwaltungsprobleme).

Und da der Abschnitt dort ohnehin knackig kurz ist, sollte das so passen. Der Kernelteil entsprechend nach hier in Kernel ausgelagert. Die Verlinkung ist nun sinnvollerweise linear und unidirektional folgendermaßen:

kurzer Hinweis in Systempflege (Abschnitt „Problemloesungen“) auf → Paketverwaltung/Problembehebung (Abschnitt „Voller-Speicher-verhindert-die-Deinstallation-von-Paketen“) - dort Lösung für volles /- und Link bei vollem /boot-Verzeichnis auf → Kernel (Abschnitt „Problemlösungen“)