Arch Linux csomagkezelése alapvetően nagyon egyszerű, de itt is lehetnek hibák, törött csomagok, feleslegesen zárolt fájlok stb. Ezekkel nem nagyon fogunk találkozni, mert ahogy tapasztaltam az Arch Linux csomagkezelése megbízható. Azt kell mondanom, hogy sokkal kevesebb problémába futottam bele, mint Debian alatt. De az ördög nem aszik, hibák mindenhol lehetnek. Így összeszedtem pár gondolatot a témában.
Törött csomagok javítása az Arch Linunon
Bár az Arch Linux csomagkezelője sok hasonlóságot mutat a Debianéval, ez egy teljesen más megoldásokat kívánó rendszer. Ezt azért kell kihangsúlyozni, mert sokan Debian, Mint, Ubuntu vonalról érkeztek, és az ott megszokott módszereket próbálhatják áthozni. Ami hiba! Itt a legtöbb törött csomag, és a hasonló, ijesztő hibakiírást adó szörnyűségek megoldása nagyon egyzserű.
A probléma diagnosztizálásának első lépése annak biztosítása, hogy a tárolók naprakészek legyenek, és megkíséreljük a teljes frissítést:
sudo pacman -Syu
A problémák egy jelentős résztét az okozhatja, ha az adatbázis nem naprakész, vagy ami nem a mi hibánk a tükörszerver, amiről frissül nem naprakész. A tükör adatbázis optimalizálására a reflector programocska alkalmas, a használatáról már volt szó.
Ha a csomag telepítésére vagy rendszer frissítésre tett kísérletek továbbra is sikertelenül végződnek, akkor a terminálban kiírtak szerint kell megfelelően el kell keresni az okot.
Kis kitérő
Az Arch Linux még a kezdőktől is elvár bizonyos alapvető jártasságot a terminálos munkában. Bár sokan ezt nehezményezik, de sajnos ez van. A terminálos feladatok, illetve problémamegoldások első és talán a legfontosabb lépése a hibaüzenetek elolvasása. Jellemzően értelmes, érthető és a hibát jól leíró hibaüzeneteket kapunk. Ha ezeket nem ismerjük, akkor a legjobb megoldás a hibaüzenet kimásolása és a google (vagy más) keresőben rákeresni. Nagyon kicsi az esélye, hogy olyan hibát sikerül produkálni, amire ott nem találunk megoldás. Bármelyik Linux disztribúciónak van saját wiki oldala, fóruma, discordja és egyéb olyan lehetősége ahol értelmesen lehet kérdezni. Így a legritkább esetben maradunk egyedül a problémánkkal. De ha a „nem, meg, valamit kiírt, de nem tudom mit” kérdést tesszük fel, a segítség hamar elapad…
Arch Linux csomagkezelési hibajelek
Pár alapvető, és előforduló kiírást érdemes megismerni, mert ezekkel találkozhatunk.
“Invalid or Corrupted Package”
Ami érvénytelen, vagy sérült csomagokra panaszkodik.
A „pacman.conf” bármilyen módon történő módosítása problémákat okozhat pacman-nak, hogy helytelenül címkézze fel a csomagokat, jellemzően sérültként.
A legvalószínűbb bűnös itt egy részleges (.part) fájl a csomagkezelő gyorsítótárában, és a megoldás logikusan az eltávolítása.
sudo find /var/cache/pacman/pkg/ -iname "*.part" -delete
A másik megoldás, hogy a kedvenc állománykezelőddel ide navigálsz és a .part kiterjesztésű állományokat kitörlöd.
A hiba elkerülése érdekében érdemes mindig odafigyelni, hogy a telepítés ne szakadjon meg, azaz nem kellene leállítani frissítés, telepítés és egyéb műveletek alatt a terminált, vagy a gépet. Bár igen intelligens a pacman, jellemzően nem kezd el siránkozni, hanem kezeli a helyzetet, de jobb nem kisérteni a sorsot. Itt is igaz, mint bármelyik disztribúciónál: nem adunk hozzá olyan tárolót, ami nem megbízható teljes mértékben. Ha valamit változtatunk a pacnam.conf-ban, akkor előtte lefuttatjuk a teljes frissítést, majd a módosítások után is egyet, hogy az adatbázisok frissüljenek. Hibákat ad, ha valami nem frissül le az adatbázisban. Itt is igaz: nem jelentkezik az esetek nagy részében probléma, de nem kellene gányolni!
Mindig fennáll annak a lehetősége, hogy a telepíteni kívánt csomag valóban sérült, és nem ad érvényes metaadatokat az Arch számára. Ebben az esetben meg kell várni, amíg a csomagkarbantartó frissíti. Ha a csomag telepítve van a rendszerben, és problémákat okoz a frissítés során, távolítsuk el:
sudo pacman -Rns [package name]
Itt jó ötlet, ha előtte utánanézel mi is ez a csomag, és ha bizonytalan vagy a fontosságában, akkor inkább vársz vele.
“Unable to Lock Database”
Azaz nem tudja zárolni az adatbázist. Arch csomagkezelője is zárolt fájlt készít a műveletek során. Ha áramszünetet miatt, illetve pacman kemény, durva megszakítása miatt, nem tudta eltávolítani a zárlatot, nagy valószínűséggel zárolt fájlt hagy maga után. A következő futáskor – mivel úgy érzékeli, hogy az zárolva van – nem fogja megnyitni, hanem udvariasan várakozik, amíg a másik folyamat, ami zárolta ki nem lép, és fel nem szabadítja a fájlt. Na erre várhat, hiszen nem fut másik folyamat, hanem csak a fájlon rajra maradt a zárolás, nem lesz aki felszabadítsa. A probléma így kétlépéses megoldás kíván.
Először is nézd meg, hogy a számítógépen futó folyamatok továbbra is használják-e a fájlt, azaz valóban jogos a zárolás:
sudo fuser /var/lib/pacman/db.lck
Ha valami már zárolta az adatbázist, akkot kapunk egy számot. Ahhoz, hogy megtudjuk ehhez a PID-hez melyik program tartozik a ps -p szám parancsot kell kiadni. Ha legálisan használja valami a zárolást, akkor érdemes megvárni a lefutást, ha nem akkor le kell azt állítani. A sudo kill PIDszám jellemzően leállítja.
Érdemes megszokni, hogy a csomagkezelést egy folyamatként kezeljük, nem indítjuk el a pacman-t. A paru-t és egyéb csomagkezelést végző programot egyszerre, több terminálban. Lineárisan, azaz lépésről-lépése kezeljük a csomagokat, nem fog gyorsabban lefutni a munkafolyamat, ha több terminálból, több paranccsal próbáljuk meg!
Ha pedig semmi nem használja a zárolást, csak valami ok miatt mégis létezik a zároló fájl, akkor egyszerűen törölhetjük.
sudo rm /var/lib/pacman/db.lck
“Conflicting Files/File Exists in Filesystem”
Ütköző fájlok/fájl vannak a fájlrendszerben. Előfordul, de nem gyakran. Ezt a frissítések során kapjuk hibajelként, ahol pacman konfliktust észlel. Mielőtt bármit javítanál, gondosan figyeld a fájl elérési útját, amelyre a csomagkezelő panaszkodik. Az első dolog, amit meg kell keresnünk, hogy kié a fájl:
pacman -Qo [ a elérési út ]
Ha egy felhasználó tulajdona, és nem egy másik csomag, egyszerűen távolítsuk el:
sudo rm [ a elérési útja fájl ]
Ilyen előfordulhat, ha valamelyik konfigurációs fájlt ide-oda másolunk, és az ütközik a telepítendővel, vagy fájlokat manuálisan másolunk be a rendszerbe stb. Nem gond, hiszen bele tudunk nézni az ütköző fájlba, és kiderül. Egy nem túl jól sikerült program eltávolítás, törlés is hagyhat olyan fájlt, amivel később gond lehet.
Ha egy másik csomag tulajdona, akkor a legbiztonságosabb, ha megvárod, amíg a csomag karbantartója maga oldja meg az ütközést. Ez a kiemelten jó megoldás. Ha nem vagy komoly Arch fejlesztő, nem napi szinten foglalkozol a függőségekkel, akkor jobb ha egy csomagkezelési, verziószám ütközési problémánál vársz egy picit. Komoly problémák esetén is órák, de maximum egy-két nap alatt megoldják. Ez értelemszerűen az Arch hivatalos tárolójára vonatkozik, ha a pacman.conf-ba idegen tárolókat is felvettél, és abban van gond, akkor az ottani tulajdonos, fejlesztő időbeosztása lesz a mérvadó.
Néha azonban ez nem lehetséges, és most szeretnéd elvégezni dolgokat, megoldani a problémát.
Ennek legegyszerűbb módja a overwrite kapcsoló pacman-nál. Csak tud, hogy ez általában nem biztonságos, és bizonyos alkalmazások nem megfelelő működéséhez vezethet a rendszerben. Azt javaslom, hogy a futtatás előtt készíts biztonsági másolatot. Ami alapvetően nem egy nagy agysebészet. A rendszer kiírta, hogy mi az amit nem tud kezelni, arról a fájlról kell egy másolatot készíteni. Ha ez gondot okoz, akkor a javasolt megoldást, a „várd meg, majd a fejlesztő megoldja” kell követni. Amit mindenképp érdemes megtenni, hogy a csomag oldalára felmész és megnézed, hogy ott a megjegyzésekben alul mit is írnak.
Az overwrite kapcsoló lehetővé teszi az Arch csomagkezelőjének, hogy figyelmen kívül hagyja egy adott fájl tulajdonjogi szabályait, és csak görgessen végig a frissítésen. Példa:
pacman -Syu --overwrite [ fájl neve ]
Ha a fenti parancs nem működik, cseréld ki a fájl nevét az abszolút elérési útjára. Egyes felhasználók arról számoltak be, hogy a perjel („/”) eltávolítása az elérési út előtt a parancs működését eredményezi, ha másképp nem megy.
Kitérő
Az Arch (és még sok egyéb) Linux disztribúció nagyon jól lett összehangolva. Bár lehetnek hibák, de jobb ha hagyjuk a javítást a megfelelően képzett szakemberekre. Egy durva felülírás lehet, hogy most megoldja a problémát, de hagyhat olyan aknákat, amik a későbbiekben gondot okozhatnak! Egy hét, egy hónap múlva nem fogunk emlékezni erre a műveletre, és ha akkor kapunk hibát, újra problémánk lesz. Jó esetben meg is tudjuk oldani, de ha nem, akkor nagyobb gondok is lehetnek. Az Arch Linux függőségei elég összetettek, így ha valamit durván felülírunk, akkor esetleg más programot is érint. Nem indul, pedig hozzá sem nyúltunk! Idegesítő, bosszantó hiba. Pedig mi írtunk valamit felül…
Ne gányoljunk éles rendszerben!
Rövid ideg várakozzunk, a fejlesztő megoldja, frissítsük az adatbázis, és ha kell a reflector használatával keressünk frissebb tükröt.
Azt is érdemes átgondolni, hogy milyen programról is van szó, ami nem működik? Egy egyszerű, helyettesíthető felhasználói programnál nagy gond nem lehet, de egy rendszerszintű eszköznél már komolyabban kell venni a „ne piszkáld amihez ne értesz” elvet.
Na és az AUR helperek?
Jogos kérdés, hiszen eddig kifejezetten a hivatalos utat, a hivatalos Arch tárolókat, a pacman-t emlegettük. A válasz nem egyértelmű, hiszen az AUR helper és a hiba függvénye, hogy miképp működik egy AUR csomagnál. Én azt tapasztaltam, hogy a paru-val nincs gond, a fentieket jellemzően el lehet végezni a paru-val is, de előtte kicsit a leírásokat érdemes átnézni.