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:/#
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
Auf meinem Produktivsystem IBM T60 (!!!) habe ich bestimmt schon etliche Releases ohne jegliche Neuinstallation durchgeführt. Noch läuft alles super 