Welcome, Guest. Please login or register.
Did you miss your activation email?

Author Topic: [DE] /lib/modules/<kernel-version> wird (bei mir) nicht mehr entfernt  (Read 3384 times)

Offline ro_sid

  • User
  • Posts: 327
Eine Beobachtung: Seit einigen Kernelversionen (eventuell beginnend mit 6.9) wird bei mir selbst bei einem "Purge" der Ordner /lib/modules/<kernel-version> nicht mehr entfernt. "Übeltäter" ist eine (neu erzeugte, aber stets bis auf einen Kommentar leere) Datei "modules.weakdep", die sich das System "abzuräumen" nicht traut.
ich bin mir nicht sicher und habe bisher nicht untersucht, woher das kommt. Es könnte, muß aber nicht auf Siduction-Kernel beschränkt sein.
Basis-System: Siduction KDE, installiert per MoW, stets aktualisiert - auf "neuestem" Stand.
Besonderheiten, die mit modules.weakdep zu tun haben könnten: Proprietärer Nvidia-(Graphik-)Treiber und bbswitch, die als Kernel-Module gebaut werden.
Das Problem ist lästig, aber unschädlich. Ein manuelles Entfernen ist immer möglich. Vielleicht machen sich "Berufenere" als ich an die Ursachenforschung und Beseititung ;).

Online towo

  • Administrator
  • User
  • *****
  • Posts: 2.998
Also mit dem kernel-remover wird hier™ trotz Warnung (Verzeichnis nicht leer, kann nicht gelöscht werden) alles entfernt.
Ich gehe nicht zum Karneval, ich verleihe nur manchmal mein Gesicht.

Offline ro_sid

  • User
  • Posts: 327
Also mit dem kernel-remover wird hier™ trotz Warnung (Verzeichnis nicht leer, kann nicht gelöscht werden) alles entfernt.
Aha, danke. Ja, die Information fehlte noch von mir - ich erledige es immer interaktiv per aptitude.
Dann verhält sich letzteres unterschiedlich, sic! Es ist allerdings, wie geschrieben, dort ein neues Verhalten.

Nochmals Dank für den Hinweis.

Offline micspabo

  • User
  • Posts: 21
@ro_sid: Ich kann das neue Verhalten bestätigen,- auch wenn ich einen anderen Weg beschreite!

Zum Aufräumen nach einem DU oder FU benutze ich ein Skript, das ich so auch unter Debian (Testing) verwende.
Code: [Select]
# cat ~/scripts/cleanupAfterAnUpgrade.sh
#!/bin/bash

echo
apt --assume-yes autoremove --purge 2>/dev/null | grep -v "Reading\|Building" | sed -e 's/^[[:space:]]*//'
apt --assume-yes autoclean          2>/dev/null | grep -v "Reading\|Building" | sed -e 's/^[[:space:]]*//'

# Der folgende Befehl findet heraus, ob sich immer noch
#   Konfigurationsdateien im System herumtreiben, deren
#   Pakete schon längst deinstalliert sind.
CoDe=$(dpkg -l | grep "^rc" | wc -l)
if [ $CoDe -gt 0 ]; then
  # Found some configs for already deleted packages. So, print them,-
  echo -e "\n[Decomposing Conf's]"
  ## dpkg -l | grep "^rc"
  # and delete them.
  dpkg -P `dpkg -l | grep "^rc" | awk -F" " '{ print $2 }'`
  printf "%d orphaned configuration(s) deleted.\n" $CoDe
fi
#EOF

Code: [Select]
# ls /lib/modules/
  drwxr-xr-x 1 root root  30 2024-06-16 19:01 6.9.3-1-siduction-amd64
  drwxr-xr-x 1 root root  30 2024-06-24 19:47 6.9.4-1-siduction-amd64
  drwxr-xr-x 1 root root 482 2024-06-16 18:12 6.9.5-1-siduction-amd64
  drwxr-xr-x 1 root root 482 2024-06-24 19:40 6.9.6-1-siduction-amd64

Unterhalb von 6.9.3 und 6.9.4 liegt nur noch eine Datei mit dem Namen modules.weakdep
Damit werden auch bei mir die übergeordneten Ordner nicht mehr gelöscht.
⢀⣴⠾⠻⢶⣦⠀  
⣾⠁⢠⠒⠀⣿⡁   Debian's Gesellschaftsvertrag
⢿⡄⠘⠷⠚⠋⠀     <https://www.debian.org/social_contract.de.html>
⠈⠳⣄⠀         Danke dafür!


Offline samtfalterblau

  • User
  • Posts: 37
Es beschränkt sich meiner Meinung nicht nur auf den Kernel:
Code: [Select]
apt purge hplip hplip-gui
apt autopurge
REMOVING:
  hplip-data*  libsane-hpaio*  python3-dbus.mainloop.pyqt5*  python3-freetype*  python3-notify2*  python3-reportlab*  python3-rlpycairo*
Entfernen von hplip-data (3.22.10+dfsg0-5) ...
dpkg: Warnung: Während Entfernens von hplip-data ist Verzeichnis »/usr/share/hplip/ui5« nicht leer, wird daher nicht gelöscht
dpkg: Warnung: Während Entfernens von hplip-data ist Verzeichnis »/usr/share/hplip/scan« nicht leer, wird daher nicht gelöscht
dpkg: Warnung: Während Entfernens von hplip-data ist Verzeichnis »/usr/share/hplip/prnt« nicht leer, wird daher nicht gelöscht
dpkg: Warnung: Während Entfernens von hplip-data ist Verzeichnis »/usr/share/hplip/pcard« nicht leer, wird daher nicht gelöscht
dpkg: Warnung: Während Entfernens von hplip-data ist Verzeichnis »/usr/share/hplip/installer« nicht leer, wird daher nicht gelöscht
dpkg: Warnung: Während Entfernens von hplip-data ist Verzeichnis »/usr/share/hplip/fax« nicht leer, wird daher nicht gelöscht
dpkg: Warnung: Während Entfernens von hplip-data ist Verzeichnis »/usr/share/hplip/copier« nicht leer, wird daher nicht gelöscht
dpkg: Warnung: Während Entfernens von hplip-data ist Verzeichnis »/usr/share/hplip/base/pexpect« nicht leer, wird daher nicht gelöscht
Entfernen von libsane-hpaio:amd64 (3.22.10+dfsg0-5) ...
Keine Umleitung »Umleitung von /lib/udev/rules.d/56-hpmud.rules zu /lib/udev/rules.d/56-hpmud.rules.usr-is-merged durch usr-is-merged«, keine entfernt.
Entfernen von python3-dbus.mainloop.pyqt5 (5.15.10+dfsg-1+b2) ...
Entfernen von python3-reportlab (4.2.0-2) ...
Entfernen von python3-rlpycairo (0.3.0-3) ...
Entfernen von python3-freetype (2.4.0-2) ...
Entfernen von python3-notify2 (0.3-5) ...
(Lese Datenbank ... 331735 Dateien und Verzeichnisse sind derzeit installiert.)
Löschen der Konfigurationsdateien von libsane-hpaio:amd64 (3.22.10+dfsg0-5) ...
dpkg: Warnung: Während Entfernens von libsane-hpaio:amd64 ist Verzeichnis »/usr/share/hplip« nicht leer, wird daher nicht gelöscht

cd  /usr/share/
rmdir hplip
rmdir: 'hplip' konnte nicht entfernt werden: Das Verzeichnis ist nicht leer

Meine Lösung war jetzt, die leeren Pfade im krusader mit root-Rechten zu löschen.

Offline ro_sid

  • User
  • Posts: 327
Seit heute entfernt (auch) aptitude wieder den Ordner /lib/modules/<kernel-version>. Bei mir erstmals bei der Version 6.9.7-1 nachdem die Version 6.9.8-1 installiert war.

Offline unklarer

  • User
  • Posts: 886
'Gelöst', wie gelöst?
Ich frage deshalb so blöd, weil der kernel-remover es bei mir nur in dieser Installation macht:

Code: [Select]
inxi -S
System:
  Host: labwc Kernel: 6.9.8-1-siduction-amd64 arch: x86_64 bits: 64
  Desktop: LabWC v: N/A Distro: siduction 2023.1.1 giants - nox -
    (202401191535)

Was auffällt, das Terminal-Fenster schließt sich bei allen danach kommentarlos.

In den anderen Installationen macht er das auch nicht. Und,
Code: [Select]
apt autopurge funktioniert ebenso nicht, weil auch hier das VZ mit dieser Datei nach der Warnung erhalten bleibt.
Ich bitte um Aufklärung.  ;)

Offline ro_sid

  • User
  • Posts: 327
'Gelöst', wie gelöst?
Ich frage deshalb so blöd, weil der kernel-remover es bei mir nur in dieser Installation macht:
[...]
Ich bitte um Aufklärung.  ;)
Aber gerne. Ferner gibt es bekanntlich keine blöden Fragen ;).
In meinem ursprünglichen Posting schilderte ich ja meine Beobachtung nach meiner(!) Vorgehensweise und schob später nach, daß ich so etwas (immer) per aptitude erledige. Normalerweise "interaktiv" mittels "purge"!
Nachdem dieses Verfahren eine Zeitlang den zugehörigen /lib/modules/-Ordner nicht "abräumte", tut es das nun wieder (für mich)!
Da ich zwischenzeitlich kein Update von aptitude, wohl aber mehrere der "apt-Familie" (apt, apt-get, libapt ...) gesehen habe, vermute ich die Ursache/Reparatur dort. aptitude arbeitet ja mit dem apt-Umfeld zusammen.
Vermutlich - ich kann ja nur einmal "purgen" :) - "tut" es auch ein "apt(-get) purge ...".
Ein "autopurge" hilft ja nur/erst, wenn das zugehörige Paket schon ausgemustert ist oder vorherige Abhängigkeiten entfernt wurden.

Ein Nachtrag: "Alte solche" Verzeichnisse werden nachträglich so natürlich nicht gelöscht.
« Last Edit: 2024/07/06, 13:48:44 by ro_sid »

Offline unklarer

  • User
  • Posts: 886
Danke!

Quote from: ro_sid
Ein "autopurge" hilft ja nur/erst, wenn das zugehörige Paket schon ausgemustert ist oder vorherige Abhängigkeiten entfernt wurden.

Ein Nachtrag: "Alte solche" Verzeichnisse werden nachträglich so natürlich nicht gelöscht.

autopurge entfernt ja auch vorher korrekt den kernel und 'nachträglich' ist schon klar.  ;)

Ich habe jetzt bei zwei weiteren Installlationen auf 6.9.8 aufgerüstet und der kernel-remover macht es auch dort.  :)
Als Schuß in's Blaue... vielleicht liegt das an dem neuen Paket linux-sysctl-defaults

Offline ro_sid

  • User
  • Posts: 327
[...]
Als Schuß in's Blaue... vielleicht liegt das an dem neuen Paket linux-sysctl-defaults
Diese Vermutung hat mich neugierig gemacht, daher habe ich nachgesehen. Aber das Paket hat nur eine einzige "effektive" Datei "/usr/lib/sysctl.d/50-default.conf" (der Rest ist Dokumentation (/usr/share/doc/...)). Darin erkenne ich nichts, was mit "unserem Problem" zu tun haben könnte.  :(

Online towo

  • Administrator
  • User
  • *****
  • Posts: 2.998
Das "Geheimnis" steckt im postrm des Kernelimage Paketes.
Ich gehe nicht zum Karneval, ich verleihe nur manchmal mein Gesicht.

Offline ro_sid

  • User
  • Posts: 327
Das "Geheimnis" steckt im postrm des Kernelimage Paketes.
Ah, vielen Dank! Das ergibt Sinn. Also nix "apt & Co.", sondern eine völlig "unverdächtige" :) Stelle.