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.lckErgebnis 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.logErgebnis 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?
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?
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.
- Arch pacman manual: query, sync and alternate system roots (Projekt- oder Distributionsdokumentation)
- ArchWiki: pacman lock and file-conflict recovery (Projekt- oder Distributionsdokumentation)