Ztráta rpm databáze nainstalovaných balíčků

30.4.2023 17:20 | Přečteno: 1046× | linux | poslední úprava: 30.4.2023 17:20

Inu, bylo nebylo, řešil jsem upgrade kubernetího clusteru. Co jsem to jen nezjistil :(

Co se stalo

Potřeboval jsem povýšit kubernetí cluster na novější verzi. Běžně se o něj nestarám, nemám na to time, řeší to jiní. Řekl jsem si, že to tedy vezmu z čisté louky, naladím patche na OS, na docker a pak povýším kubernetes. Koukám, že jeden node stále visí na verzi AlmaLinux 8.6, přitom ostatní jsou na 8.7. To bylo ještě předtím, než jsem nějaký upgrade začal. Říkám si WTF. Dívám se na ten node, dávám upgrade a dnf mi hlásí, že nemůže detekovat verzi OS. Začínám pátrat proč, což byla otázka chvilky. dnf neznal jediný nainstalovaný balíček, rpm vypisoval 0 nainstalovaných balíčků. Někdo smazal rpm db, nebo jí v rámci migrace nějakým divným omylem nezmigroval.

Co dál? Jaké je řešení?

Nějaký srábotka by ten node zahodila a nahodila nový z template. Mě ovšem zajímalo, zda z toho existuje cesta ven. Zda lze v takové situaci OS zachránit, jak moc je to zdlouhavé, náročné atd. Inu, node jsem v rámci kubernetu odpojil a jal se po večerech hrát si, co a jak. K celému problému jsem přistupoval tak, že nemám nikde stejný node. Prostě simulace toho, že mám jeden server, který mi běží, a nemám nic na porovnání. Ono totiž, když bych to vzal jinak, tak stačí vylistovat seznam rpm z jednoho node a všechny balíky znovu nainstalovat.

Jak tedy řešit osamocený, unikátní server, který ztratí db s nainstalovanými balíky?

Řešení

Všichni asi víme, že lze k souboru na filesystému dohledat náležitý balík. Je tedy třeba mít aktuální db se seznamem balíku z mirroru. Ověříme si tedy, jakou verzi OS máme, podle toho si naladíme seznam balíků. tj.:

cat /etc/almalinux-release
AlmaLinux release 8.6 (Sky Tiger)

# nainstalujeme příslušný release balíček
rpm -ivh almalinux-release-8.6-2.el8.x86_64

# uděláme update
dnf --releasever=8.6 update

Teď tedy máme lokální cache se seznamem balíků z repositářů a můžeme začít porovnávat. Budeme porovnávat jen soubory v "/etc" a "/usr". Je to plně dostatečné a nejsou tam zbytečné soubory navíc. Našel jsem tento tip:

# projdi soubor po souboru a zeptej se pomocí dnf, zda k tomu existuje nějaké balík
find /usr /etc -type f -print0 | xargs -0 -P$(nproc) dnf --cacheonly whatprovides | sort -u > /tmp/packages.txt

# výsledkem po dlouhé době je tento soubor:
cat /tmp/packages.txt | wc -l
31242

Rovnou říkám, že takto pitomě neoptimalizovaně to na relativně malé instalaci trvá cca 30h, než se ten seznam balíků dohledá. Záleží hlavně na výkonu cpu a počtu jader.

Ve vygenerovaném souboru je spousta balastu:

"Filename    :"
"Repo        :"
"Matched from:"
"Last metadata expiration check:"
"Waiting for process with pid"

takže ho odsud odebereme:

# odebrat řádky s hloupostma
cat packages.txt | sed '/^Filename    :/d' | sed '/^Repo        :/d' | sed '/^Matched from:/d' | sed '/^Last metadata expiration check:/d' | sed '/^Waiting for process with pid/d' > packages2.txt

# následně už máme mnohem menší soubor
cat packages2.txt |wc -l
1461

# tento soubor má v sobě tento formát
...
docker-ce-3:19.03.13-3.el8.x86_64 : The open-source application container engine
docker-ce-3:19.03.14-3.el8.x86_64 : The open-source application container engine
docker-ce-3:19.03.15-3.el8.x86_64 : The open-source application container engine
docker-ce-3:20.10.0-3.el8.x86_64 : The open-source application container engine
docker-ce-3:20.10.10-3.el8.x86_64 : The open-source application container engine
...
docker-ce-cli-1:19.03.13-3.el8.x86_64 : The open-source application container engine
docker-ce-cli-1:19.03.14-3.el8.x86_64 : The open-source application container engine
docker-ce-cli-1:19.03.15-3.el8.x86_64 : The open-source application container engine
docker-ce-cli-1:20.10.0-3.el8.x86_64 : The open-source application container engine
docker-ce-cli-1:20.10.10-3.el8.x86_64 : The open-source application container engine
...
containerd.io-1.3.7-3.1.el8.x86_64 : An industry-standard container runtime
containerd.io-1.3.9-3.1.el8.x86_64 : An industry-standard container runtime
containerd.io-1.4.10-3.1.el8.x86_64 : An industry-standard container runtime
containerd.io-1.4.11-3.1.el8.x86_64 : An industry-standard container runtime
containerd.io-1.4.12-3.1.el8.x86_64 : An industry-standard container runtime
containerd.io-1.4.13-3.1.el8.x86_64 : An industry-standard container runtime
...
systemd-239-68.el8.x86_64 : System and Service Manager
systemd-libs-239-68.el8_7.1.i686 : systemd libraries
systemd-libs-239-68.el8_7.1.x86_64 : systemd libraries
systemd-libs-239-68.el8_7.2.i686 : systemd libraries
systemd-libs-239-68.el8_7.2.x86_64 : systemd libraries
...

Musíme tedy z toho souboru vykostit spoustu duplicit a nejlépe i balíky, které mají v sobě verzi. Nejjednodušší je si obsah splitnout podle architektur:

# ověříme si počet řádků, zda nám něco nezmizí, takže nejdřív celkový a poté pro jednotlivé architektury
cat packages2.txt |wc -l
1461

cat packages2.txt |grep ".noarch" |wc -l
148

cat packages2.txt |grep ".i686" |wc -l
246

cat packages2.txt |grep ".x86_64" |wc -l
1064

148 + 246 + 1067 = 1461

# pokud máme číslo nižší, tak si ověříme, co je ten zbytek:
grep -v i686 packages2.txt | grep -v x86_64 |grep -v noarch

# dáme si tedy split
cat packages2.txt |grep ".noarch" > packages-noarch.txt
cat packages2.txt |grep ".i686" > packages-i686.txt
cat packages2.txt |grep ".x86_64" > packages-x86_64.txt

# na další filtrování nám stáčí sort a awk. Sort chceme reverzní pořadí, abychom awkem mazali nejstarší balíčky a nechali případně univerzální bez definování verze
sort -r packages-noarch.txt | awk -F' : ' '!seen[$2]++' >> packages-final.txt
sort -r packages-i686.txt | awk -F' : ' '!seen[$2]++' >> packages-final.txt
sort -r packages-x86_64.txt | awk -F' : ' '!seen[$2]++' >> packages-final.txt

Ověříme si, co máme:

# výsledný seznam si můžeme projít takto:
sort packages-final.txt

# počet řádků/balíčků je stále trochu vyšší:
cat packages-final.txt |wc -l
822

# následně ho ještě okostíme od popisku, tj. aby tam nebylo "docker-ce-cli-1:19.03.13-3.el8.x86_64 : The open-source application container engine", ale jen název balíčku "docker-ce-cli-1:19.03.13-3.el8.x86_64"
cat packages-final.txt | awk '{print $1}' > packages-final2.txt

Tak, máme seznam balíčků, které zřejmě potřebujeme. Jdeme je stáhnout:

mkdir /var/cache/dnf/temp
cd /var/cache/dnf/temp
dnf download $(</root/packages-final2.txt)

a teď je všechny nainstalujeme:

dnf install *
Last metadata expiration check: 0:05:51 ago on Wed 01 Mar 2023 05:38:34 PM CET.
Error:
 Problem 1: package docker-ce-rootless-extras-23.0.1-1.el8.x86_64 requires docker-ce, but none of the providers can be installed
  - conflicting requests
  - package docker-ce-3:19.03.13-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:19.03.14-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:19.03.15-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.0-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.1-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.10-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.11-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.12-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.13-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.14-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.15-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.16-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.17-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.18-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.19-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.2-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.20-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.21-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.22-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.23-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.3-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.4-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.5-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.6-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.7-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.8-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:20.10.9-3.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:23.0.0-1.el8.x86_64 is filtered out by exclude filtering
  - package docker-ce-3:23.0.1-1.el8.x86_64 is filtered out by exclude filtering
 Problem 2: package containerd.io-1.6.9-3.1.el8.x86_64 conflicts with runc provided by runc-1:1.1.4-1.module_el8.7.0+3407+95aa0ca9.x86_64
  - conflicting requests
 Problem 3: package coreutils-8.30-13.el8.x86_64 conflicts with coreutils-single provided by coreutils-single-8.30-13.el8.x86_64
  - conflicting requests
 Problem 4: package fwupd-1.7.8-1.el8.alma.x86_64 obsoletes dbxtool < 9 provided by dbxtool-8-5.el8_3.2.x86_64
  - conflicting requests
 Problem 5: package docker-ce-cli-1:23.0.1-1.el8.x86_64 conflicts with docker provided by podman-docker-3:4.2.0-8.module_el8.7.0+3407+95aa0ca9.noarch
  - conflicting requests
 Problem 6: package libcurl-minimal-7.61.1-25.el8.x86_64 conflicts with libcurl(x86-64) provided by libcurl-7.61.1-25.el8.x86_64
  - conflicting requests
 Problem 7: package syslog-ng-logrotate-3.23.1-3.el8.x86_64 conflicts with rsyslog provided by rsyslog-8.2102.0-10.el8.x86_64
  - conflicting requests
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

Na výpisu vidíme, kde je prolém. Generování seznamu balíčků na základě existence souboru je pěkná věc, ale spousta balíků může mít společné soubory. Tj. konfliktní balíky. V mém případě stačilo pořešit takto:

# konflikt syslogu
dnf instal rsyslog
rm syslog-ng-logrotate-3.23.1-3.el8.x86_64.rpm

# podman nepoužíváme, jen docker
rm podman-docker-4.2.0-8.module_el8.7.0+3407+95aa0ca9.noarch.rpm

# curl minimal také ne, takže naladíme curl a stažený minimal mázneme
dnf install libcurl
rm libcurl-minimal-7.61.1-25.el8.x86_64.rpm

# to samé coreutils
dnf install coreutils
rm coreutils-single-8.30-13.el8.x86_64.rpm

# to samé fwupd
dnf install fwupd
rm fwupdate-11-3.el8.alma.1.x86_64.rp
rm dbxtool-8-5.el8_3.2.x86_64.rpm

# taktéž nepoužíváme, takže pryč
rm runc-1.1.4-1.module_el8.7.0+3407+95aa0ca9.x86_64.rpm

# příliš nová verze, pryč
rm docker-ce-rootless-extras-23.0.1-1.el8.x86_64.rpm

Hahá, hotovo, jde to konečně naladit:

dnf install *

Error Summary
-------------
Disk Requirements:
   At least 1451MB more space needed on the /usr filesystem.

Nojo, on dnf neví, že přeinstalovává již nainstalované balíky, takže zbytečně chce alokovat další místo, které nepotřebuje. Dočasně si tedy vypneme kontrolu místa

nano /etc/yum.conf
...
diskspacecheck=0

Tak snad už:

# a znovu (můžeme asi přidat i parametr --noscripts)
dnf install *

# následně update
dnf update

# volné místo skoro neubylo, balíčků trochu přibylo
rpm -qa |wc -l
874

Proč máme o tolik balíčků více?

Porovnání počtu balíčků jiný node a tento opravený:

# jiný node
rpm -qa |wc -l
655

# náš opravený
rpm -qa |wc -l
874

Je to prosté, těch 200 navíc jsou totiž i686, tj. 32bit balíčky, protože mají stejné konfigurační soubory v "/etc" a další věci. Co s tím? Jo, to nevím :). Na osamocenmém OS můžete naslepo odinstalovávat 32bit balíčky, o kterých si myslíte, že je nepotřebujete. Já už jsem tuto třešničku nechtěl řešit, takže jsem si nakonec vyjel porovnání s jiným node.

# zjištění, které balíky přebývají v opraveném OS
grep -v -f rpm-list-node-ok.txt rpm-list-node-opraveny.txt > packages.txt

# odinstalace se zachováním 64bit verze
dnf remove $(<packages.txt) -x '*.x86_64'

# vyřešení problému s protected package
rpm -e systemd.i686
# nebo asi i takto:
dnf --disableplugin=protected_packages erase systemd.i686

# porovnání, co chybí na opraveném node
grep -v -f rpm-list-node-opraveny.txt rpm-list-node-ok.txt > packages1.txt
...

Tipy

Při přeinstalování by možná bylo dobré vypnout scripty, jelikož jsou již provedeny, takže:

rpm -ivh --noscripts --notriggers *

Taktéž se teoreticky nemusí balíky přeinstalovávat, stačí je jen zaindexovat:

rpm -ivh --noscripts --notriggers --justdb *rpm

Problém s indexací je ale ten, že si nejste jisti, jakou verzi balíku máte reálně nainstalovanou. Takže doporučuji přeinstalovat.

Po přeinstalaci je pak dobré udělat update na aktuální verze baklíčků:

dnf update

Další možnosti pro obnovení

Výše uvedený postup není jediný, který lze aplikovat. Vše záleží, co vám zbylo, co máte k dispozici. Další možný postup je popsán např. v KB RedHatu:
How to recover rpm database using /var/log/rpmpkgs?

Závěr

Takže ano, opravit to jde, počítejte, že to může být na delší dobu a nebude to hned a budete mít nejspíše pár 32bit balíčků navíc, oproti původnímu plánu. Akce to byla zábavná a rád jsem si s tím pohrál :D.

Ještě dodám, že příkazy ohledně parsování, generování apod. píši čitelně. Některé mám rozdělené schválně do více kroků, aby to bylo i přehledné a jasné, co se v kterém kroku děje. Tím chci říci, že připomínky, že používám zbytečně "cat", zbytečně volám 4x sed, místo abych ho volal jednou s více podmínkami apod., jsou zbytečné.

Jistě přijde v diskusi i řeč na to, jak se taková věc může stát z procesního hlediska. Tj. jak je možné, že to někdo podělá, že ty nody někdo aktualizuje a nevšimne si, že to na jednom neprobíhá atd. Vzhledem k tomu, že se to stalo, tak je zřejmé, že na to nemohu mít uspokojivou odpověď. Každopádně snažíme se psát playbooky v ansible, všechno postupně automatizovat a postupně víc logovat a testovat, aby se podobné věci odhalily hned, resp. se nestaly.

Zdar Max

       

Komentáře

[zdar fax]

Jako mentalni cviceni ok, ale jako proces je to blbost, protze normalni lidi maji zalohy :D

[Max]

No však jsem to psal, že normálně bych tu vm zahodil, jen mě zajímalo, zda z toho lze vybruslit a jak moc náročně. Úkol splněn :D
Jen tedy nevím, proč jsem ten zápisek nevydal, visí mi tam dlouho takto napsaný a dnes jsem si toho všiml, tak jsem to poslal.
Zdar Max

[X]

Nestacilo by vycist co se instalovalo z /var/log/dnf* souboru?

[Max]

Ne, zkoumal jsem různé možnosti, jak to vypadá i jinde a v tom logu toho moc není.
Ještě je možnost pokusit se obnovit zálohu rpmdb, ale zase, k tomu ty data člověk musí mít. Pokud větší část kolem těch dat vezme za své, nemá člověk v ruce nic, co by zajistilo 100% rekonstrukci a nejspolehlivěji se pak jeví ono dohledávání balíků pomocí nainstalovaných souborů na fs.
Zdar Max

[takové Linuxovské]

A nešlo by to udělat jedním tlačítkem?

[tom]

sed umi delat vic operaci najednou, takze sed '/aaa/d' | sed '/bbb/d' jde napsat jako sed -e '/aaa/d' -e '/bbb/d' a nebo jako sed '/aaa/d;/bbb/d'

[Max]

Citace ze zápisku:

...Ještě dodám, že příkazy ohledně parsování, generování apod. píši čitelně. Některé mám rozdělené schválně do více kroků, aby to bylo i přehledné a jasné, co se v kterém kroku děje. Tím chci říci, že připomínky, že používám zbytečně "cat", zbytečně volám 4x sed, místo abych ho volal jednou s více podmínkami apod., jsou zbytečné...

Zdar Max

[J]

Mentalni cviceni nekde na doma hezke, ale kdyby se mi timhle chlubil zamestnanec tak ho poslu do prdele ze mrda za me prachy v pracovnim case.

[Max]

Počáteční diag v jobu, pak jsem to odložil a nechal si to na doma.
Zdar Max

[Want]

Ubožák, který by snášel na vedoucí pozici kokota jako seš ty, si stejně nic jiného nezaslouží.

[Want]

^^^ Nitemedia, zakažte už tohle jelito vařený

[podlesh]

Pokud to není na úkor jiné práce (termíny atd), tak se něco naučil a to je dobrá investice.

[plostenka]

A ja ho obratem zamestnam. O schopne lidi, kteri kdyz na to prijde, tak rozeberou cely traktor, je nouze.

[hefo]

A ešte väčšia o takých, čo ho budú vedieť aj zložiť