Willkommen Gast. Bitte einloggen oder registrieren. Haben Sie Ihre Aktivierungs E-Mail übersehen?
15.07.2020, 13:50:55

.
Einloggen mit Benutzername, Passwort und Sitzungslänge

Mitglieder
Statistiken
  • Beiträge insgesamt: 670996
  • Themen insgesamt: 54379
  • Heute online: 432
  • Am meisten online: 2287
  • (22.01.2020, 19:20:24)
Benutzer Online

Autor Thema:  [alpha]cikspoc Check Installed Kernels for Support and Purge Obsolete Cautiously  (Gelesen 7313 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Angespornt von der derzeitigen Kernel-Häufung habe ich ein Skript gebastelt, das beim Aufräumen hilft. Es ist unter LM 17.x und 18.x lauffähig und getestet. Trotzdem kann ich etwas übersehen haben und stufe es zunächst als alpha ein. Wer Fehler findet, darf diese nicht behalten! ;) Ein weiterer Grund ist, dass ich bislang einfach drauf los codiert habe ohne auf irgendwas anderes als die Funktion zu achten. Das muss noch geändert werden.
Der bisherige Arbeitstitel ist zwar sperrig, aber selbsterklärend.

Was macht das Skript?
Im Kern ermittelt es die installierten Kernel und sortiert diese so wie wir Menschen sie uns denken, die höchste zu erst. Dann wird nach Kernel-Linien absteigend untersucht, ob diese Kernel-Linie noch mit Updates versorgt wird und wieviele Kernel dieser Linie installiert sind.
Wird die Kernel-Linie nicht mehr unterstützt, wird bei LM 18.x zusätzlich noch geprüft, wie groß der Versionsunterschied der aktuellen Linie zu deren Erscheinen ist. So wird ein wenig Zeit verschafft, um die aktuelle Linie erst ausgiebig zu testen und die alte Linie noch als Fallback zu behalten.
Danach und für LM 17 wird vorgeschlagen alle Kernel dieser nicht unterstützten Linie zu entfernen.

    Geht das nicht zu weit?
Wer sich mit der Kernel-Thematik auseinander gesetzt hat, wird einen Vorschlag seitens dieses Skriptes die Kernel-Linie zu wechseln nicht benötigen und daher den entsprechenden Hinweis nie zu Gesicht bekommen.
Für Einstieger in die Kernel-Geschichten halte ich das für sinnvoll und habe es daher in das Skript aufgenommen.

Beim ersten Fund einer nicht mehr unterstützen Kernel-Linie wird zudem ein Hinweis angezeigt, der das einfache "j/n?" erläutert. Bei Bestätigung werden allen Kernel dieser Linie zum Entfernen markiert; Bei Verneinung wird zur Prüfung weiter gereicht, wieviele Kernel dieser Liene installiert sind.

Sind mehr als zwei Kernel einer Linie installiert, werden die beiden zuletzt installierten als Behalten markiert, der Rest als zu löschen.

Sind alle Kernel-Linien abgefragt, findet nun zunächst eine Prüfung statt, ob nicht zufällig (ungewollt) alle Kernel zum Entfernen markiert würden; Dies führt zum Abbruch. Eine wieter Prüfung findet statt, ob der gerade aktive Kernel, der durch seine Verwendung als funtionionstüchtig gelten kann, zumindest startfähig, auch unter denen ist, die erhalten bleiben sollen. Ist das nicht der Fall erscheint eine entsprechende Meldung.

Nach Bestätigung einer separierten Auflistung der zu behaltenen und zu löschenden Kernel wird der Löschvorgang eingeleitet. Sollte dabei ein Fehler auftreten wird danach auf alle Fälle nochmal die Liste der installierten Kernel ermittelt.

Was macht das Skript noch?
Die Aktualisierungsverwaltung entfernt Kernel bislang nur per «remove», d. h. es bleiben Reste der Konfiguration («purge» ist auf der Roadmap; wird möglicherweise nur ab LM 18.2 zur Verfügung stehen).
Diese Reste werden auch gesucht, die betroffen Kernel-Version angezeigt und nachgefragt, ob diese (Konfigurationsreste) entfernt werden sollen.

Im Paket-Zwischenspeicher /var/cache/apt/archives werden alle Installationspakete für die nicht mehr installierten Kernel gesucht, aufgelistet und nach Rückfrage entfernt.

Als letztes wird das Verzeichnis /lib/modules anhand der eingang erzeugten Liste der zu behaltenen Kernel abgesucht, nach überzähligen Dateien und Verzeichnissen. Nach Rückfrage wird auch hier aufgeräumt.

Das Skript ist für Linux Mint 17 und 18 konzipiert und getestet. Es findet deshalb zu Anfang auch eine Prüfung statt, ob dies gegeben ist, ansonsten wird das Skript beendet.
Begründung: Unter LMDE funktioniert das Kernel-Update anderes, weshalb dies definitiv ausgeschlossen werden muss um das System zu schützen. Unter ubuntu werden die Befehle nicht funktionieren, da apt nicht gleich apt ist (siehe Diskussion). Eine ubuntu-Version werde ich bei ubuntuuseres.de vorstellen, wenn diese entsprechend angepasst und getestet ist.

Wie prüft das Skript?
Für LM 17.x sind die nicht mehr unterstützten Kernel bereits bekannt. Da sind sie schlicht fest in den Code geschrieben. Für LM 18.x erfolgt ein Vergleich der Versionsnummern zwischen den Metapaketen «linux-generic-hwe-16.04» und «linux-generic-hwe-16.04-edge». Ist ein Unterschied in der Kernel-Linie, so verweist «egde» auf eine höhere Linie, so zu sagen ein preview. Ist die Kernel-Linie gleich und die Differenz der letzten Versionsnummer kleiner 20, gilt die vorhergehende Linie noch nicht als veraltet.

known issues
Sollte das Skript als unprivilegierter Benutzer gestartet werden UND dieser Benutzer nicht abgemeldet, sondern nur zum privilegierten Benutzer gewechselt werden, dann kann das Skript auf seine benötigten temporären Dateien nicht zugreifen, da sie dem unprivilegierten Benutzer gehören. Abhilfe: unprivilegierten Benutzer abmelden.

Ein Umgang mit Kernel aus anderen als der Standard-Quellen wurde ebenso wenig getestet wie der Umgang mit speziellen Kernel-Varianten, z. B. lowlatency.

feature request
Ich fange frech selbst damit an, mir Dinge zu wünschen.

Konfigurationsmöglichkeit
für die Anzahl der Kernel, die im System verbleiben sollen
sowie für die Größe des Versionsunterschieds nach Erscheinen einer neuen Kernel-Linie, bis die alte dann automatisch als alt gemeldet wird. Mit anderen Worten: Wieviel Zeit wird dem Benutzer gelassen, die neue Kernel-Linie zu testen, ehe die alte zum Entfernen vorgeschlagen wird.

Klarere Benutzerführung. Der Sprung von Skript zu «apt purge» und dessen Ausgabe sowie zurück zum Skript kann bestimmt der erfahrene Konsolero verkraften, aber gerade die Einsteiger dürften etwas erschlagen werden.

Einrichtung
Ich empfehle das  Skript aus dem ersten Anhang nach /usr/local/bin zu verschieben, bspw. aus dem Download-Verzeichnis
sudo mv ~/Downloads/cikspoc.sh.txt /usr/local/bin/cikspoc
sudo chown root: /usr/local/bin/cikspoc
sudo chmod 755 /usr/local/bin/cikspoc
So ist das Skript vor versehentlichen Änderungen geschützt, aber letztlich ist das jedem selbst überlassen.

Anhang 2 zeigt ein Beispiel der Terminalausgabe.


EDIT vom 8.4.2018: Dateianhang mit dem Skript findet sich nun weiter hinten.

Bitte das Thema auch bis zum Ende durchschauen. Es gibt bspw. eine verbesserte Fassung vom Oktober 2017. Weitere Fehlerkorrekturen nicht ausgeschlossen.
« Letzte Änderung: 08.04.2018, 11:48:28 von {°-°} »

Irre ich mich, oder passt da was an den Befehlen nicht?

Hylli

LM-18.1 Cinnamon
Gerade einen Testlauf (im Terminal ausführen) gemacht.
Von /home/user/bin/chikspoc.sh aus, Doppelklick auf die Datei.
Einfaches "Ausführen" funktioniert nicht.

Fängt aber im Terminal gut an, nicht aktuelle Kernel-Versionen der Serie 4.4 und 4.8 bemerkt, es werden zu entfernende Dateien (/lib/modules/…) gefunden und das Entfernen angeboten.
aber nach Bestätigung mit 'Ja' und Passwort-Eingabe stürzt das Terminal sofort ab.

Edit
Bei einem zweiten Versuch erscheint kurz eine Terminalausgabe, bevor das Script erneut abstürzt (nach "[  OK  ] Es mussten keine alten Kernels gelöscht werden") und das Terminalfenster sich ohne weitere Meldung schließt.
Ist mMn (insbesondere für Anfänger, für die es ja gedacht sein soll) noch sehr ungeeignet.

Dritter Versuch per direktem Terminal-Start: user@W530 ~/bin $ ./chikspoc.sh
cikspoc (Check Installed Kernels for Support and Purge Obsolete Cautiously) Version 17.04 (April 2017) für Linux Mint 17 und 18

aktueller Füllstand des Wurzelverzeichnisses
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda5        20G    6,9G   12G   37% /

[  OK  ] Das Betriebsystem ist ein Linux Mint 18, wofür dieses Skript entwickelt wurde.

[  OK  ] Die Paketlisten sind jünger als drei Tage.


. .

[ info ] Es erscheint demnächst eine neue Kernel-Linie 4.10.0
         Der Zeitpunkt für eine Datensicherung wäre sehr günstig. ;)

[  OK  ] Kernel 4.8.0 befindet sich innerhalb des Unterstützungszeitraumes
[ :-(( ] Der aktuelle Kernel der Linie 4.8.0 ist nicht installiert. Bitte nachholen.
[  OK  ] In Kernel-Linie 4.8.0 sind weniger als drei installiert.

[  OK  ] Kernel 4.4.0 mit Langzeitunterstützung (LTS)
[ :-(( ] Der aktuelle Kernel der Linie 4.4.0 ist nicht installiert. Bitte nachholen.
[  OK  ] In Kernel-Linie 4.4.0 sind weniger als drei installiert.
[  OK  ] Der aktive Kernel ist unter denen, die installiert bleiben sollen.
[  OK  ] Folgende Kernel können installiert bleiben.
4.8.0-42
4.4.0-67
[  OK  ] Es mussten keine alten Kernels gelöscht werden.

[  OK  ] Es wurden keine zurückgebliebenen Konfigurationsdateien entfernter Kernel gefunden.

ls: Zugriff auf 'linux*' nicht möglich: Datei oder Verzeichnis nicht gefunden
[  OK  ] Im Paket-Zwischenspeicher liegen keine Installationsdateien entfernter Kernel.
[  OK  ] Im Verzeichnis /lib/modules wurden keine Module entfernter Kernel gefunden.
neuer Füllstand des Wurzelverzeichnisses
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda5        20G    6,9G   12G   37% /
Es wurden 0 kB befreit
user@W530 ~/bin $
« Letzte Änderung: 05.04.2017, 15:11:41 von aexe »

Ich hab das Script mal über LM 18.1 Cinnamon laufen lassen und bekommen eine Meldung die ich nicht deuten kann.

[ :-(  ] Kernel 4.10.8 außerhalb des Unterstützungszeitraumes
         Sollen alle Kernel dieser Linie zum "Löschen" markiert werden?
Anmerkung: Wenn sie zum "Behalten" markiert werden, wird im nächsten Schritt geprüft,
           ob mehr als zwei installiert sind und überzählige zum "Löschen" markiert.
         Sollen die Änderungen durchgeführt werden? j/n

An dieser Stelle hab ich dann abgebrochen. Der 4.10.8 ist mein aktuell verwendeter Kernel.
Was bedeutet "außerhalb des Unterstützungszeitraumes" und falls ich die Frage mit Ja beantworte, zieht das Script mir dann den 4.10.8 mit weg?

Gruss

Test Nr.4
mit einem anderen relativ frischen LM-18.1 : user@X240 ~/bin $ ./chikspoc.sh
cikspoc (Check Installed Kernels for Support and Purge Obsolete Cautiously) Version 17.04 (April 2017) für Linux Mint 17 und 18

aktueller Füllstand des Wurzelverzeichnisses
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda9        16G    5,7G  9,2G   39% /

[  OK  ] Das Betriebsystem ist ein Linux Mint 18, wofür dieses Skript entwickelt wurde.

date: /var/cache/apt/srcpkgcache.bin: Datei oder Verzeichnis nicht gefunden
(standard_in) 2: syntax error
./chikspoc.sh: Zeile 114: [: -lt: Einstelliger (unärer) Operator erwartet.
[ :-(  ] Die Paketlisten sind älter als drei Tage, sie sollten aufgefrischt werden.


[  OK  ] Kernel 4.4.0 mit Langzeitunterstützung (LTS)
[  OK  ] Der aktuelle Kernel der Linie 4.4.0 ist installiert.
[  OK  ] In Kernel-Linie 4.4.0 sind weniger als drei installiert.
[  OK  ] Der aktive Kernel ist unter denen, die installiert bleiben sollen.
[  OK  ] Folgende Kernel können installiert bleiben.
4.4.0-72
[  OK  ] Es mussten keine alten Kernels gelöscht werden.

[  OK  ] Es wurden keine zurückgebliebenen Konfigurationsdateien entfernter Kernel gefunden.

ls: Zugriff auf 'linux*' nicht möglich: Datei oder Verzeichnis nicht gefunden
[  OK  ] Im Paket-Zwischenspeicher liegen keine Installationsdateien entfernter Kernel.
[ :-(  ] Im Verzeichnis /lib/modules wurden noch Module entfernter Kernel gefunden.
         Sollen diese entfernt werden?
         Sollen die Änderungen durchgeführt werden? j/n
         Dann kann's ja losgehen!
[sudo] Passwort für user:
neuer Füllstand des Wurzelverzeichnisses
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda9        16G    5,7G  9,2G   39% /
Es wurden 3 MB befreit
Ist diesmal, zwar mit neuen Meldungen, aber ohne Absturz und mit Erfolg durchgelaufen.
Vorher: user@X240 /lib/modules $ ls
4.4.0-53-generic  4.4.0-66-generic  4.4.0-67-generic  4.4.0-70-generic  4.4.0-71-generic  4.4.0-72-generic
Nachher: user@X240 /lib/modules $ ls
4.4.0-72-generic
« Letzte Änderung: 05.04.2017, 19:48:51 von aexe »

Zitat von: hylli
Irre ich mich, oder passt da was an den Befehlen nicht?
Meintest du cikspoc.sh >< cikspoc (ohne .sh)? fixed

Zitat von: aexe
. . . aber nach Bestätigung mit 'Ja' und Passwort-Eingabe stürzt das Terminal sofort ab.
Noch Ratlosigkeit . . .

Zitat von: aexe
ls: Zugriff auf 'linux*' nicht möglich: Datei oder Verzeichnis nicht gefunden
Du verwendest wohl «apt clean», dann kann auch nichts gezeigt werden.

Fehlerkorrektur 1:
sed -i 's/ls linux*/ls linux* 2> \/dev\/null/' ~/Downloads/chikspoc.sh.txtfixed

Zitat von: Renalto
[ :-(  ] Kernel 4.10.8 außerhalb des Unterstützungszeitraumes
Zitat von: {°-°}
known issues
. . .
Ein Umgang mit Kernel aus anderen als der Standard-Quellen wurde ebenso wenig getestet wie . .
Wenn du nein wählst, wird mit der Prüfung der Anzahl der installierten Kernels fortgefahren.

Bei mir übrigens seit heute:
. .

[ info ] Es erscheint demnächst eine neue Kernel-Linie 4.10.0
         Der Zeitpunkt für eine Datensicherung wäre sehr günstig. ;)


Ja, ich verwende regelmäßig nach Updates 'apt clean', nachdem ich die heruntergeladenen Pakete nach der Installation an zentraler Stelle archiviert habe.

Die Kernel-Linie 4.10  wird übrigens nach Auffrischen der Paketlisten bereits von der Kernel Verwaltung in Mintupdate angeboten (Kernel 4.10.0-14).
« Letzte Änderung: 05.04.2017, 19:51:27 von aexe »

Zitat
Die Kernel-Linie 4.10  wird übrigens nach Auffrischen der Paketlisten bereits von der Kernel Verwaltung in Mintupdate angeboten (Kernel 4.10.0-14).
Dann kann diese Verwaltung aber nicht nach
apt-cache search linux-imagearbeiten wie du in dem anderen Beitrag meintest, oder es nutzt nicht die Ubuntuquellen, denn dort wird nur bis zum 4.8 angezeigt.
Der letzte ist selbst bei yaketty noch
linux-image-4.8.0-45-generic - Linux kernel image for version 4.8.0 on 64 bit x86 SMP
« Letzte Änderung: 05.04.2017, 20:49:47 von DocHifi »

user@X240 ~ $ apt-cache search linux-image-4.10.0-14-generic
linux-image-4.10.0-14-generic - Linux kernel image for version 4.10.0 on 64 bit x86 SMP
user@X240 ~ $ uname -a
Linux X240 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
user@X240 ~ $

Zitat
apt-cache search linux-image-4.10.0-14-generic
Gibt unter Ubuntu 16.10 keine Ausgabe, keine Ahnung wo Mint den herholt.
16.04 kann ich grad nicht testen, weil nicht vor Ort.

Das meta-Paket «linux-generic-hwe-16.04-edge» verweist seit heute auf 4.10.0.14.11.
http://packages.ubuntu.com/search?keywords=linux-generic-hwe-16.04-edge&searchon=names&suite=xenial&section=all
« Letzte Änderung: 05.04.2017, 21:12:49 von {°-°} »

Alles klar, dann liegt wohl es daran, das 16.10 keine LTS ist.

Wir reden hier ja auch nicht von Ubuntu, sondern von LinuxMint.  ;)
Obwohl der Kernel selbstverständlich von Ubuntu kommt.
(das orange Sternchen in Synaptic verrät es)

Zitat
Wir reden hier ja auch nicht von Ubuntu, sondern von LinuxMint.  ;)
Es ging mir ja darum, wo Mint den Kernel herholt, da ist Ubuntu schon eine gute Referenz.
Angeblich basiert Mint ja auf Ubuntu. 8)
« Letzte Änderung: 05.04.2017, 21:33:44 von DocHifi »

Wir reden hier ja auch nicht von Ubuntu, sondern von LinuxMint. 
Obwohl der Kernel selbstverständlich von Ubuntu kommt.
Off-Topic:
Zu blöd richtig zu zitieren, oder böse Absicht?
Manchmal frag ich mich schon, worum es Dir wirklich geht …
Zitat
Wir reden hier ja auch nicht von Ubuntu, sondern von LinuxMint.  ;)
Es ging mir ja darum, wo Mint den Kernel herholt, da ist Ubuntu schon eine gute Referenz.
Angeblich basiert Mint ja auf Ubuntu. 8)