Paketverwaltung und Updates

pacman erhält seine Datenbanksperre nicht

Ein libalpm-Schreiber oder eine alte db.lck nach einem Abbruch kann pacman sperren. Den Fall vor Änderungen an der Sperrdatei nachweisen.

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

  • pacman meldet unable to lock database.
  • Ein abgebrochenes Update hinterlässt db.lck ohne aktives Paketfrontend.

Betroffene Umgebung

Arch-Linux-pacman/libalpm; anders als dpkg-Regionalsperrdateien ist pacmans db.lck eine Transaktionsmarkierung.

Erkennbare Meldungen (synthetische Beispiele)
error: failed to init transaction (unable to lock database)

Vor Annahme einer alten Markierung auf aktive Schreiber prüfen; die Meldung trennt die Fälle nicht.

Mögliche Ursachen

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

  • Ein anderes pacman- oder grafisches libalpm-Frontend kann die Datenbank aktualisieren.
  • Ein unterbrochener Schreiber kann eine alte Sperrmarkierung und eventuell unvollständige Pakete hinterlassen.

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 Prozesse an der Sperrdatei; kein -k verwenden. Vollständige Prüfung kann administrative Leserechte benötigen.

fuser /var/lib/pacman/db.lck

Ergebnis einordnen: Einen gemeldeten Prozess untersuchen. Keine Ausgabe allein reicht nicht: alle Paketfrontends und Leserechtegrenzen prüfen.

Prüfschritt 2

Liest die letzten Transaktionsereignisse, ohne die Paketdatenbank zu öffnen oder zu ändern.

tail -n 80 /var/log/pacman.log

Ergebnis einordnen: Eine gestartete Transaktion ohne Abschluss stützt einen Abbruch, kann aber noch laufen; den Prozesszustand bestätigen.

Nächste Schritte nach Befund

Den aktiven libalpm-Schreiber abwarten

Wenn ein berechtigtes Paketfrontend aktiv ist, dessen Fortschrittsanzeige nutzen und den Abschluss abwarten. Doppelte Updater schließen und erst nach Ende des Schreibers und Freigabe einen Paketvorgang ausführen.

Vorsicht: db.lck nicht entfernen oder den Schreiber beenden, während er Dateien und Hooks anwendet.

Wiederherstellung / Rücknahme: Warten benötigt keinen Paket-Rollback. Das doppelte Frontend erst nach Abschluss der aktiven Transaktion wieder öffnen.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Nur eine nachweislich veraltete pacman-Sperre entfernen

Erst nach Bestätigung, dass weder pacman noch ein anderer libalpm-Schreiber aktiv ist, die alte /var/lib/pacman/db.lck administrativ entfernen. Anschließend mit pacman -Dk die lokale Datenbank prüfen und die unterbrochene Transaktion vor einem vollständigen unterstützten Systemupdate auswerten.

Vorsicht: Das gilt für die pacman-Markierung, nicht für dpkg-Sperrdateien. Eine alte Sperre beweist keinen gesunden unterbrochenen Paketstand.

Wiederherstellung / Rücknahme: Die nächste Transaktion erzeugt ihre Sperre selbst. Bei Paket-/Datenbankschäden einen zusammenhängenden Snapshot oder Arch-Rettungsweg nutzen, statt eine verwaiste Sperre wiederherzustellen.

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.