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 ;).
Also mit dem kernel-remover wird hier™ trotz Warnung (Verzeichnis nicht leer, kann nicht gelöscht werden) alles entfernt.
Quote from: towo on 2024/06/24, 10:27:02
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.
@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.
# 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
# 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.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073998
Es beschränkt sich meiner Meinung nicht nur auf den Kernel:
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.
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.
'Gelöst', wie gelöst?
Ich frage deshalb so blöd, weil der kernel-remover es bei mir nur in dieser Installation macht:
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, apt autopurge funktioniert ebenso nicht, weil auch hier das VZ mit dieser Datei nach der Warnung erhalten bleibt.
Ich bitte um Aufklärung. ;)
Quote from: unklarer on 2024/07/06, 11:44:03
'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.
Danke!
Quote from: ro_sidEin "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
Quote from: unklarer on 2024/07/06, 14:42:35
[...]
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. :(
Das "Geheimnis" steckt im postrm des Kernelimage Paketes.
Quote from: towo on 2024/07/07, 15:04:03
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.