Błąd mniam: otwarcie rpmdb nie powiodło się

42

Próbuję uruchomić yum updatei uruchamiam ten błąd:

rpmdb: PANIC: fatal region error detected; run recovery
error: db3 error(-30974) from dbenv->open: DB_RUNRECOVERY: Fatal error, run database recovery
error: cannot open Packages index using db3 - (-30974)
error: cannot open Packages database in /var/lib/rpm
CRITICAL:yum.main:

Error: rpmdb open failed

Sprawdziłem stronę taką jak ta, ale w yum clean allsystemie działa ten sam błąd.

Jak mogę to rozwiązać?

centos yum

— Alex Jolig
źródło

84

W ten sposób naprawiłem mój problem.

To dość niechlujna sytuacja. Możesz to naprawić, usuwając bazę danych rpm. Aby zminimalizować ryzyko, wykonaj kopię zapasową plików /var/lib/rpm/za pomocą cppolecenia:

mkdir /root/backups.rpm.mm_dd_yyyy/
cp -avr /var/lib/rpm/ /root/backups.rpm.mm_dd_yyyy/

Aby rozwiązać ten problem, spróbuj:

# rm -f /var/lib/rpm/__db*
# db_verify /var/lib/rpm/Packages
# rpm --rebuilddb
# yum clean all

Sprawdź, czy wystąpił błąd za pomocą następującego polecenia yum

# yum update

— Alex Jolig
źródło

Wydaje się, że to rozwiązanie działa również z dnf zamiast yum.

— młot

Po wykonaniu tego wszystkiego dostaję „niedokończone transakcje pozostałe…”, a uszkodzone pakiety, które spowodowały problem, nadal blokują wszelkie przyszłe instalacje. Jeśli o to chodzi, dlaczego użytkownik końcowy musiałby to zobaczyć / zrobić? Jeśli yum-db ma problem, powinien wyczyścić / naprawić się automatycznie - z co najwyżej pytaniem ay / n, z którego os-tinkerer może zrezygnować. Znaleziono poprawkę dla mojego przypadku - wykonaj powyższe czynności, a następnie wykonaj „mniam-kompletna transakcja - tylko do

— czyszczenia

8

Dlaczego nie tylko cd /var/lib/rpm; db_recover? W większości przypadków jest to znacznie mniej opcji nuklearnej.

— Craig Ringer

3

Uważam, że sudo rpm --rebuilddbsam rozwiązuje moją sprawę. Niemniej jednak zawsze wykonaj kopię zapasową /var/lib/rpmdla bezpieczeństwa.

— alick

Dla tych, którzy nadal widzą komunikat „zabity” podczas instalacji yum, po prostu uruchom ponownie serwer. Tak, ponowne uruchomienie jest bardzo trudne, aby uzyskać coś takiego podstawowego, ale to była jedyna rzecz, która działała dla mnie.

— Nirmal

0

Dzięki Alex, twoja odpowiedź zadziałała dla mnie oprócz jednej drobnej zmiany, którą musiałem wprowadzić.

rm -f /var/lib/rpm/__db*

zwróciło błędy

rm: cannot remove `/var/lib/rpm/__db.001': Is a directory
rm: cannot remove `/var/lib/rpm/__db.002': Is a directory
rm: cannot remove `/var/lib/rpm/__db.004': Is a directory

więc musiałem powrócić

rm -rf /var/lib/rpm/__db*

— Ian Ellis
źródło

2

To nie powinny być katalogi. Jeśli to zobaczysz, możesz chcieć uruchomić fsckna partycji, aby upewnić się, że nie masz uszkodzonych plików.

— docwhat

0

Próbowałem powyższego, ale to nie zadziałało

poniżej działa dobrze

# cd /var/lib
# tar -zcvf /var/preserve/rpmdb-$(date +%Y-%m-%d_%H-%M-%S).tar.gz rpm

Uwaga: Tej kopii zapasowej tar można użyć, jeśli występują problemy z próbą odzyskania bazy danych RPM.

Sprawdź integralność pliku Packages:

# cd /var/lib/rpm
# rm -f __db*      # to avoid stale locks
# /usr/lib/rpm/rpmdb_verify Packages

# mv Packages Packages.orig
# /usr/lib/rpm/rpmdb_dump Packages.orig | /usr/lib/rpm/rpmdb_load Packages


# rpm -vv --rebuilddb

Jeszcze raz sprawdź bazę danych RPM:

# cd /var/lib/rpm
# /usr/lib/rpm/rpmdb_verify Packages

— Kundel
źródło

0

Wszystko, co musiałem zrobić, to usunąć dwa pliki z rozszerzeniem „.lock” i trzy pliki, które rozpoczęły się od „__db”.

# rm /var/lib/rpm/.dbenv.lock
# rm /var/lib/rpm/.rpm.lock
# rm /var/lib/rpm/__db*

Potem yum updatedziałało.

— isapir
źródło