Paketverwaltung und Updates

Ein Arch-Teilupdate hinterlässt inkompatible Bibliotheken

Ein Teilupdate kann Bibliotheksnutzer oder pacman stören. Transaktionsverlauf und ELF-Abhängigkeiten prüfen, statt Bibliotheks-Symlinks zu erfinden.

Auf dieser Seite
  1. Symptome und Geltungsbereich
  2. Mögliche Ursachen
  3. Sicher prüfen
  4. Nächste Schritte nach Befund
  5. Quellen und Prüfung
  6. Verwandte Probleme

Symptome und Geltungsbereich

  • Anwendungen verlangen nach selektiven Updates einen entfernten Bibliotheks-Soname.
  • pacman selbst endet mit einem Shared-Library-Ladefehler.

Betroffene Umgebung

Rollende Arch-Linux-Paketstände; readelf funktioniert auch, wenn pacman seine eigenen Shared Libraries nicht laden kann.

Erkennbare Meldungen (synthetische Beispiele)
pacman: error while loading shared libraries: libalpm.so.99: cannot open shared object file: No such file or directory

Ein Teilupdate ist eine Ursache; fehlende Dateien oder veränderte Suchpfade können denselben Ladefehler erzeugen.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

  • Neue Repository-Datenbanken mit anschließender Einzelinstallation können einen nicht unterstützten Paketmix erzeugen.
  • Eine lokal gebaute/AUR-Anwendung kann auch nach vollständigem Update noch eine ältere Bibliotheks-ABI erwarten.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

Liest die ELF-Abhängigkeiten, ohne pacman zu starten. Für ein anderes betroffenes natives Programm den Pfad ersetzen.

readelf -d /usr/bin/pacman

Ergebnis einordnen: NEEDED-Sonames zeigen erwartete ABI-Namen. Eine anders nummerierte installierte Bibliothek ist nicht automatisch binärkompatibel.

Prüfschritt 2

Liest Paketverlauf und protokollierte pacman-Aufrufe; den Zeitraum unmittelbar vor dem Ladefehler prüfen.

rg -n "\[ALPM\] (installed|upgraded|removed)|\[PACMAN\] Running" /var/log/pacman.log

Ergebnis einordnen: Selektive Updates oder -Sy vor -S stützen einen Paketmix. Auch eine vollständige Transaktion kann lokale Fremdpakete mit nötigem Neubau hinterlassen.

Nächste Schritte nach Befund

Ein unterstütztes vollständiges Systemupdate abschließen

Wenn pacman läuft und der Verlauf ein Teilupdate zeigt, Arch-Neuigkeiten prüfen, einen Rettungssnapshot sichern und das unterstützte pacman -Syu vollständig durchführen, statt nur die fehlende Bibliothek zu aktualisieren. Verbliebene betroffene Pakete aus lokalen oder AUR-Installationen gegen den aktuellen Bibliotheksstand neu bauen.

Vorsicht: Keine alte Soname-Datei auf eine andere ABI verlinken oder -Sy mit anschließenden Einzelinstallationen nutzen. Nötige manuelle Eingriffe vorher prüfen.

Wiederherstellung / Rücknahme: Bei nötiger Rücknahme den vollständigen vorherigen Paketsnapshot herstellen; einzelne Bibliotheksdowngrades können gerade aktualisierte Nutzer stören.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Ein nicht startbares pacman mit vertrauenswürdigem Installationsmedium retten

Wenn pacman nicht startet, ein geprüftes aktuelles Arch-Rettungsmedium booten und die tatsächliche Installation samt nötigen Boot-Dateisystemen einhängen. Mit dem pacman der Live-Umgebung und dessen dokumentiertem --sysroot den Arch-Rettungsweg für einen zusammenpassenden Zielpaketstand nutzen. Vor Schreibzugriffen das Ziel bestätigen.

Vorsicht: Ein einfacher chroot mit dem defekten Ziel-pacman kann gleich scheitern. Falsche Wurzel oder fehlender Boot-Mount kann das falsche System aktualisieren.

Wiederherstellung / Rücknahme: Gesicherten zusammenhängenden Snapshot oder Paket-/Konfigurationssicherung über dieselbe vertrauenswürdige Rettungsumgebung herstellen; Medium bis zum erfolgreichen Systemstart behalten.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Quellen und Prüfung

Diese Anleitung basiert auf Originalquellen von Projekten oder Distributionen und wurde am genannten Datum redaktionell geprüft. Das ist eine Quellenprüfung, kein Nachweis einer auf deiner Hardware reproduzierten Lösung. Log-Beispiele sind synthetische Testdaten. Versionsabhängige Details müssen zur installierten Ausgabe passen.