System-Update bricht ab

[sodoku23]

Hallo,

beim Update auf
Linux-Kernel 5.10.179-1
und
glibc 2.31-13+deb11u6

bleibt der Update-Vorgang stecken. Danach muss ich immer ein Live-USB-System starten, um ein timeshift-snapshot wiederherzustellen. Echt doof. Alle anderen Updates haben geklappt. Ich kann nur ein Handy-Foto von den Fehlermeldungen anhängen, weil danach so gut wie nichts mehr geht im System.

Folgendes lese ich beim Updatevorgang, vom Foto angetippt

Entpacken von libc6...
dpkg: Fehler beim Bearbeiten des Archivs /var/cache/apt/archieves/libc6...
Neue Version von /lib64/ld-linux-x86-64.so.2 kann nicht installiert werden. Datei oder Verzeichnis nicht gefunden
dpkg: Fehler beim Aufräumen
Post-removal-Unterprozess gab den Fehlerwert 2 zurück

Kann jemand helfen? Wäre super.

Viele Grüße!

[sodoku23]

Hier die Bildschirmausgabe:

gallery/image/4062

[Livingston]

Hast Du /var als eigene Partition eingebunden? Vielleicht ist die voll gelaufen. Am Besten checkst Du mal mit

Code: Alles auswählen

#df -h

die Füllstände.

[sodoku23]

Danke für die Nachricht. /var ist mit auf der Systempartition. Sieht da vom Speicher noch alles gut aus. Alle anderen Updates laufen problemlos durch.

Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
udev 7,7G 0 7,7G 0% /dev
tmpfs 1,6G 3,2M 1,6G 1% /run
/dev/nvme0n1p3 98G 31G 63G 34% /
tmpfs 7,8G 0 7,8G 0% /dev/shm
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
/dev/nvme0n1p4 698G 371G 292G 56% /home
/dev/nvme0n1p5 96M 27M 70M 29% /boot/efi
tmpfs 1,6G 120K 1,6G 1% /run/user/1000
tmpfs 1,6G 880K 1,6G 1% /run/user/1001

[Livingston]

Die Meldungen von dpkg geben leider meist wenig her. Ich wünschte mir auch manchmal, dass es gesprächiger wäre.
Eine Idee habe ich noch: Die Installationsscripte der deb-Pakete werden zwischenzeitlich im Verzeichnis /tmp ausgepackt, dort ausgeführt und anschließend wieder gelöscht. Fehlen dem tmp-Verzeichnis vielleicht Ausführungsrechte? Was sagt ls -l /tmp? Wenn das der Fall ist, erstmal manuell als root

Code: Alles auswählen

# chmod u+x /tmp

ausprobieren und nochmal die Paket-Installation starten. (Die Ursache der falschgesetzten Rechte können wir ja dann danach suchen.)

[sodoku23]

Danke für die Idee:

drwxrwxrwt 19 root root 4096 23. Mai 16:00 /tmp

Ich denke, da stimmt alles.

[Livingston]

Ja, /tmp ist in Ordnung.
Sorry, aber im Moment fällt mir nix Neues ein.

[MSfree]

Es schadet nicht, in die Logs zu schauen:
/var/log/dpkg.* und alles unter /var/log/apt kann Hinweise liefern.

Die Meldung in deinem Screenshot, daß libc6 nicht installiert werden kann, deutet wage auf [--unpack] hin. Das kann bedeuten, daß das Paket nicht korrekt runtergeladen wurden und Übertragungsfehler entanden sein könnten, und sich dadurch das Paket nicht (vollständig) entpacken läßt.

Ich würde hier zuerst mal den Paketcache löschen:

Code: Alles auswählen

apt-get clean

Ohne den Cache werden die zu installierenden Pakete nochmal runtergeladen und im Cache verstaut.

Dann nochmal

Code: Alles auswählen

apt-get dist-upgrade 

ausführen. (Ja dist-upgrade und nicht upgrade)

[sodoku23]

Danke für's Mitdenken und Posten. Mit apt-get clean et al. arbeite ich schon seit Tagen. Habe mich in den letzten Tagen durch x Internetseiten durchgeackert.... nix. Hab's aber noch einmal wie von dir vorgeschlagen probiert. Leider nein. Gleicher Fehler. Ich hatte die aktuell installlierte Version von libc6 auch einmal händisch aus dem debian-repository als .deb-File runtergeladen und damit einen lokalen --reinstall gemacht -- nix --> Fehler --> Absturz.

Danke für den Hinweis mit den Logs. Habe ich mir gerade angeschaut. Keine Fehlermeldungen. Sieht alles OK aus. Mir scheint da eher was mit den Packaging-files nicht zu stimmen. Oder da hängt irgendwo eine unkorrekte Installation zwischen Baum und Borke fest, und die blockiert da irgend etwas. Es betrifft nur das Paket libc6. Alles andere läuft!

[MSfree]

Was geben

Code: Alles auswählen

ls -l /lib64

und

Code: Alles auswählen

ls -l /lib64/ld-linux-x86-64.so.2 

bei dir aus?

[sodoku23]

In /lib64 sind 2842 Ordner/Dateien gelistet.

ls ld-linux-x86-64* -l ergibt:

lrwxrwxrwx 1 root root 32 14. Okt 2022 ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.31.so
lrwxrwxrwx 1 root root 10 14. Okt 2022 ld-linux-x86-64.so.2.bak -> ld-2.31.so
lrwxrwxrwx 1 root root 46 31. Okt 2022 ld-linux-x86-64.so.2.usrmerge-broken -> /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

broken?

[MSfree]

In /lib64 sind 2842 Ordner/Dateien gelistet....
broken?

Normal ist das jedenfalls nicht. Bei mir ist /lib64 in symbolischer Link auf usr/lib64. In /usr/lib64 gibt es bei mir nur einen symbolischen Link namens ld-linux-x86-64.so.2, der auf /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 zeigt.

Das gilt sowohl für einen meiner Rechner, auf dem Bullseye installiert ist als auch für einen anderen Rechner mit Bookworm.

[Livingston]

Jetzt wird's unübersichtlich. Bei mir (direkt installiertes Bullseye, nicht upgegradet) sieht das nochmal anders aus:

Code: Alles auswählen

# /usr/lib64$ ls -l
lrwxrwxrwx 1 root root 32 19. Apr 23:17 ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.31.so

NACHTRAG:
Ich erinnere mich, dass ich dieses System mit debootstrap eingerichtet und auf usr-merge vezichtet habe. Was bei mir aber auch noch ähnlich ist:

Code: Alles auswählen

/lib/x86_64-linux-gnu$ ls -d -l ld-*
-rwxr-xr-x 1 root root 177928 19. Apr 23:17 ld-2.31.so
lrwxrwxrwx 1 root root     10 19. Apr 23:17 ld-linux-x86-64.so.2 -> ld-2.31.so

Das passt soweit. Von vielen Paketen wird erwartet, dass der Linker ld* unter verschiedenen Namen erreichbar ist, eben einmal mit der maschinenspezifischen Bezeichnung (ld-linux-x86-64.so.2) als auch mit dem generischen Namen (ld-2.31.so).
Dass hier Links vorliegen ist entsprechend notwendig und korrekt.

Diese beiden bei sodoku23 machen mich stutzig:

Code: Alles auswählen

lrwxrwxrwx 1 root root 10 14. Okt 2022 ld-linux-x86-64.so.2.bak -> ld-2.31.so
lrwxrwxrwx 1 root root 46 31. Okt 2022 ld-linux-x86-64.so.2.usrmerge-broken -> /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

Wäre die Frage, wo die herkommen.

[MSfree]

Ich erinnere mich, dass ich dieses System mit debootstrap eingerichtet und auf usr-merge vezichtet habe.

Wenn bei dir /bin ein Link auf /usr/bin ist (ähnlich für /lib auf /usr/lib), dann ist usrmerge bei dir bereits durchgeführt worden.

Mein Bullseye hatte ich mit dem Netinstaller eingerichtet und auch hier ist usrmerge bereits durchgeführt worden. Offiziell wird ursmerge erst mit Bookworm zwingend.

sodoku23s System scheint aber ein nicht erfolgreiches usrmerge hinter sich zu haben. Das zeigt sich einierseits durch den symbolischen Link

ls ld-linux-x86-64* -l ergibt:

lrwxrwxrwx 1 root root 46 31. Okt 2022 ld-linux-x86-64.so.2.usrmerge-broken -> /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

mit namen ld-linux-x86-64.so.2.usrmerge-broken. und auch in der Anzahl Dateien und Verzeichnisse unter /lib64.

Leider habe ich aber auch keine Erfahrung mit so einer Situation, kann also auch nur spekulieren, wie man das wieder ins Lot rückt.

[sodoku23]

Erst einmal vielen Dank allen hier für's Mitdenken, Ideen und Tipps. Ich bin da jetzt nicht weiter gekommen; konnte das Problem also NICHT lösen. Daher habe ich mir ein frisches Linux Mint 21.1 aufgespielt. Alles prima Der Thread hier kann also geschlossen werden.