Läuft "cruft" mal wieder nicht, oder habe ich Tomaten auf den Augen ?

Du kommst mit der Installation nicht voran oder willst noch was nachfragen? Schau auch in den "Tipps und Tricks"-Bereich.
Antworten
Odysseus24
Beiträge: 145
Registriert: 04.01.2005 04:32:46
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Bremen

Läuft "cruft" mal wieder nicht, oder habe ich Tomaten auf den Augen ?

Beitrag von Odysseus24 » 09.10.2019 16:58:38

Guten Tag mal wieder hier im Forum !


Vielleicht bin ich nicht so ganz richtig in diesem Sub-Forum, doch ich habe keinen passenderen Themenbereich gefunden. Es geht nämlich nur indirekt um das dist-upgrade von Stretch zu Buster:

Seit gefühlt zehn Jahren mache ich nach den neuen "Stable"-Releases immer mal wieder (sagen wir mal: bei jedem zweiten Release) den z.B. in den Release-Notes zum Dist-Upgrade empfohlenen "Test" mit cruft - um zu sehen, welcher Müll sich so angesammelt hat und natürlich, ob noch alles schön an seinem Platz ist. Und wieder habe ich (fälschlicherweise) Tausende von nicht erklärten (unexplained) Files und tausende an fehlenden (missing) im Report von cruft (pastebin/?mode=view&s=40880). Die unerklärten Files sind allerdings sehrwohl von dpkg registriert als auch die "fehlenden" vorhanden (soweit ich das kontrolliert habe, was ich natürlich nur "pars pro toto", also exemplarisch gemacht habe).

Dies ist aktuell wieder auf meinem Desktop-Arbeitssystem und auf meinem Backup-System aufgetreten; zumindest letzteres ist dabei praktisch vollkommen unverbaut seit der Ur-Installation ca. 2013 oder 2014 (nur immer wieder dist-upgraded plus ca. 10 aktiv installierte Packete (aptitude, mc, debfoster, deborphan, cruft und vielleicht fünf weitere)). Beide Systeme sind zudem frisch von Stretch auf Buster dist-upgraded.

Meine erste Arbeishypothese (dies liege am neu installierten Packet "usrmerge", da die Files, die speziell für /bin/ oder auch für /lib/ erklärt werden, dann dort nicht gefunden würden, sondern stattdessen unerklärterweise in /usr/bin/ oder auch in /usr/lib/) hat sich aber nicht bestätigt. Es hat offenbar mit usrmege nix zu tun, denn:

- (ebenfalls tausende) andere Files werden auch noch als "unexplained" bzw. "missing" reported, die sich aber unter /usr/bin/, /usr/sbin/ oder auch /usr/lib/ etc. finden lassen und von dpkg dort registriert sind.

- ich habe einen Versuch mit folgendem Script durch geführt. Es fragt die registrierten Dateien von dpkg ab, erzeugt ein Explain-Script, das die unter /bin/, /sbin/, /lib/ usw. regisrierten Files gegenüber cruft erklärt und es erzeugt zudem eine Filter-Muster-Liste für diese Dateien (die in /bin/, /sbin/, /lib/ usw. erlärt sind, aber unter /usr/bin/, /usr/sbin/ oder auch /usr/lib/ hausen), um ein Reporten als "missing" zu vermeiden. Schließlich der Aufruf von cruft:

Code: Alles auswählen

root@HAL-9000:/# cat /home/juwe24/Scripts/Cruft
#! /bin/bash

# registered Files:
dpkg-query --listfiles $(dpkg -l | cut -b2- | grep '^i' | gawk -F'[[:blank:]]+' '{print $2}') > /tmp/DPKG.files

# Filter, not to be reported as "missing":
# makes more sense, but Bash denies because of too much patterns:
#grep -E '^/sbin|^/bin|^/lib|^/lib32|^/lib64|^/libx32' /tmp/DPKG.files | sort | uniq >/etc/cruft/filters/USRMERGE
# therefor:
echo '/sbin/**' > /etc/cruft/filters/USRMERGE
echo '/bin/**' >> /etc/cruft/filters/USRMERGE
echo '/lib/**' >> /etc/cruft/filters/USRMERGE
echo '/lib32/**' >> /etc/cruft/filters/USRMERGE
echo '/lib64/**' >> /etc/cruft/filters/USRMERGE
echo '/libx32/**' >> /etc/cruft/filters/USRMERGE

# Explain-Script creation:
echo '#! /bin/bash' > /etc/cruft/explain/USRMERGE
sed -En '\;^/sbin|^/bin|^/lib|^/lib32|^/lib64|^/libx32;s;^/;echo "/usr/;p' /tmp/DPKG.files \
| sed 's/$/" >\&3/' | sort | uniq >>/etc/cruft/explain/USRMERGE
chmod 755 /etc/cruft/explain/USRMERGE

# final call:
cruft --ignore "/root /home /mnt /proc /sys /Dummy /Schafott /Pax /dev /lost+found /opt /run /srv /tmp" -r ~/Cruft.report

root@HAL-9000:/# 
Ergebnis: kein Unterschied zu erkennen.

Meine Frage ist nun: hat jemand hier positive Erfahrung mit cruft - ohne dieses eskalative Reporting von fehlenden bzw. unerkärten Dateien ? Vielleicht habe ich die gesamte Anwendung einfach nicht verstanden und mach' mal wieder etwas grundsätzliches verkehrt.


Gruß
Odysseus24
...in a sea of random images
the self-destructing animal
waiting for the waves to break
(Richard Wright)

uname
Beiträge: 12041
Registriert: 03.06.2008 09:33:02

Re: Läuft "cruft" mal wieder nicht, oder habe ich Tomaten auf den Augen ?

Beitrag von uname » 10.10.2019 11:01:40

Ich kenne die Anwendung "cruft" nicht. Vielleicht ist es auch gut, dass ich die Anwendung nicht kenne ;-) Auf meinem Produktivsystem IBM T60 (!!!) habe ich bestimmt schon etliche Releases ohne jegliche Neuinstallation durchgeführt. Noch läuft alles super ;-) Aber ich werde es mir auch mal anschauen ;-)

Was ich aber bei jedem Release mache ist über Debianapt-show-versions die Pakete rauszusuchen, die nicht zum aktuellen Release (|fgrep -v buster) gehören. Ich weiß das geht auch anders, leider vergesse ich immer die Syntax. Die nicht zum Release gehörenden Pakete deinstalliere ich inkl. aller Konfigurationsdateien (--purge). Sicherheitshalber schaue ich über "dpkg -l" ob dort noch was mit "rc" steht und die Pakete deinstalliere ich mit "--purge".

Vielleicht hilft auch dir dieses Vorgehen und die Liste von "cruft" wird dann kürzer. Ist aber nur eine Idee.
Kann aber sein, dass Debiandeborphan das bereits abfängt und es keine Pakete aus alten Releases mehr gibt.

Odysseus24
Beiträge: 145
Registriert: 04.01.2005 04:32:46
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Bremen

Re: Läuft "cruft" mal wieder nicht, oder habe ich Tomaten auf den Augen ?

Beitrag von Odysseus24 » 10.10.2019 12:15:13

Danke uname.

Habe sogar zwei neuere Pakete an Bord, aber keine alten mehr... aptitude im interaktiven Modus zeigt einem auch die veralteten und selbst erstellten Pakete an, die hatte ich schon alle 'rausgeworfen. Woher die neuen kommen ? ...keine Ahnung, habe kein apt-pinning, keine Backports aus "testing" (falls es sowas schon gibt), bin komplett auf "buster".

Code: Alles auswählen

root@HAL-9000:/home/juwe24# apt-show-versions | grep -v buster
libmp3lame0:i386 1:3.99.5-dmo4 newer than version in archive
libxvidcore4:i386 3:1.3.3-dmo1 newer than version in archive
root@HAL-9000:/home/juwe24#
Vor dem dist-upgrade hatte ich allerdings apt-pinning, was ich zuvor dann deaktiviert habe (wg. des Pakets dnscrypt-proxy, das unter "Stretch" nicht mehr lief). Jetzt geht es wieder (nachdem ich einen Fehler fixen musste - egal), daher brauche ich kein Pinning mehr. Aber da die Pakete seinerzeit ja aus "Buster" stammen mussten, ist dies eigentlich auch keine brauchbare Erklärung hierfür...

Wie dem auch sei, eine Erklärung für tausende von falsch "unregistrierten" bzw. "fehlenden" Files auf zwei verschiedenen Systemen wäre dies ohnehin nicht. Und nur konfigurierte, aber nicht installierte Pakete habe ich auch nicht mehr...

Gruß
Odysseus24
...in a sea of random images
the self-destructing animal
waiting for the waves to break
(Richard Wright)

uname
Beiträge: 12041
Registriert: 03.06.2008 09:33:02

Re: Läuft "cruft" mal wieder nicht, oder habe ich Tomaten auf den Augen ?

Beitrag von uname » 10.10.2019 12:34:04

Die beiden Pakete kannst du deinstallieren und direkt aus Buster neu installieren.
Sonst habe ich leider keine Idee mehr. Schau dir evtl. noch Debiandebsums an.

Odysseus24
Beiträge: 145
Registriert: 04.01.2005 04:32:46
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Bremen

Re: Läuft "cruft" mal wieder nicht, oder habe ich Tomaten auf den Augen ?

Beitrag von Odysseus24 » 10.10.2019 14:57:54

Ahoi nochmal, uname !

Die beiden Pakete waren nicht zu neu, sondern irgendwie zu alt. Die Syntax der Paketversion war nicht mehr up to date... Musste ich mit dpkg entfernen und neu installieren, jetzt ist auch nach apt-show-versions alles auf dem neusten Stand...

Danke für den Tipp und Gruß
Odysseus24
...in a sea of random images
the self-destructing animal
waiting for the waves to break
(Richard Wright)

Antworten