I Linux er apt, dnf og pacman grundlaget for installation og opdatering af software. Når de ser ud til at være “gået i stykker”, betyder det ikke kun, at man ikke længere kan installere nye programmer. Ofte stopper også sikkerhedsopdateringerne, og vedligeholdelsen af hele systemet bliver langt mere besværlig. Almindelige årsager er afbrudte opdateringer, defekte mirrors, inkonsistente pakkedatabaser, fejl i signaturkontrol, ødelagte afhængigheder eller tilbageblevne låsefiler. Det vigtigste er ikke straks at begynde at slette cache og konfiguration tilfældigt, men først at forstå, hvilken del der reelt er beskadiget.
Nogle gange ser det ud, som om selve pakkehåndteringen er defekt, mens den egentlige årsag ligger i netværket, DNS, repository-indstillinger eller manglende diskplads. Derfor bør fejlsøgningen begynde med at afgøre, om problemet ligger i forbindelsen, i repository’et, i den lokale database eller i afhængighederne.
Typiske symptomer
apt update,dnf updateellerpacman -Syustopper med fejl- Der vises beskeder om uløselige afhængigheder eller ødelagte pakker
- Repository’er kan ikke bruges på grund af GPG- eller signaturfejl
- Databasen er låst, så ingen pakkeoperationer virker
- Mirrors returnerer 404 eller timeout
- Efter en afbrudt opdatering fungerer pakkehåndteringen ikke længere korrekt
- Efter opdatering af visse biblioteker kan selve pakkehåndteringen ikke starte
Hvad skal kontrolleres først
Det første skridt er at afgøre, om problemet virkelig ligger i pakkehåndteringen, eller om det i stedet skyldes netværket eller DNS.
ping -c 4 8.8.8.8
ping -c 4 google.com
ip addr
ip routeHvis netværket eller DNS allerede er defekt, kan fejl i apt, dnf eller pacman blot være en følge af det. Hvis normal netværkstrafik fungerer, men pakkeoperationer fejler, bør fokus rettes mod repository’er, nøgler, låse, cache, databaser og afhængigheder.
Fælles årsager ved apt / dnf / pacman
1. Afbrudt opdatering
En af de mest almindelige årsager er en opdatering, der blev afbrudt midt i processen. Strømsvigt, en lukket terminal, afbrudt SSH-forbindelse eller et grafisk miljø, der fryser, kan efterlade pakkedatabasen eller enkelte pakker i en halvfærdig tilstand.
I sådanne tilfælde bør man ikke straks begynde at slette filer, men i stedet forsøge at færdiggøre den uafsluttede tilstand korrekt.
2. Tilbageblevne låsefiler
Pakkehåndteringsværktøjer bruger låse for at forhindre flere samtidige operationer. Hvis en anden proces stadig kører, eller hvis kun låsefilen blev tilbage efter et crash, vil systemet sige, at pakkehåndteringen allerede er i brug.
Men man bør ikke slette låsefiler blindt. Først skal man sikre sig, at ingen relevante processer faktisk stadig kører.
ps aux | grep -E 'apt|dpkg|dnf|yum|pacman'3. Beskadiget repository-konfiguration
Tredjeparts-repository’er, gamle PPA’er, ugyldige mirrors eller rester af konfiguration efter en distributionsopgradering kan gøre selve pakkekilderne ugyldige. Typiske tegn er 404-fejl, manglende Release-fil eller problemer med at hente metadata.
4. Problemer med GPG-nøgler og signaturer
Repository’er kontrolleres normalt kryptografisk. Hvis en nøgle er udløbet, ikke er importeret, nøglestyringen er ændret, eller den lokale keyring er beskadiget, vil pakkehåndteringen stoppe af sikkerhedshensyn.
5. Ødelagte afhængigheder
Afhængigheder går ofte i stykker, når man tvinger inkompatible versioner af pakker ind, blander forskellige repository’er, udfører delvise opdateringer eller overskriver systembiblioteker manuelt. Det er især kritisk på pacman-baserede systemer, men apt og dnf bliver også ustabile, når kilder blandes ukontrolleret.
6. Beskadiget cache eller metadata
Delvist hentede pakker, forældede metadata eller ødelagte synkroniseringsdatabaser kan forhindre korrekt læsning af pakkelister og få installationer til at fejle.
7. Manglende diskplads
En hyppig, men ofte overset årsag er for lidt ledig plads. Hvis partitioner som /var eller /boot er fyldte, kan udpakning og filskrivning fejle midtvejs og efterlade pakkesystemet i en inkonsistent tilstand.
df -h
du -sh /var/cache/* 2>/dev/nullHvad skal kontrolleres, når apt fejler
På Debian- og Ubuntu-systemer er det vigtigt ikke kun at kigge på apt, men også på tilstanden af dpkg nedenunder.
Ret ufuldstændigt konfigurerede pakker
sudo dpkg --configure -a
sudo apt --fix-broken installEfter en afbrudt opdatering er disse to kommandoer ofte det vigtigste første skridt.
Hent pakkelister igen
sudo apt updateHvis der her vises 404-, signatur- eller Release file-fejl, skal /etc/apt/sources.list og indholdet af /etc/apt/sources.list.d/ kontrolleres.
Ryd cache
sudo apt clean
sudo apt autocleanHvis problemet skyldes beskadiget eller forældet cache, kan dette hjælpe.
Hvad skal kontrolleres, når dnf fejler
På Fedora- og RHEL-systemer bør man især se på metadata, transaktionshistorik og repository-konfiguration.
Gendan metadata
sudo dnf clean all
sudo dnf makecacheHvis mirror-information eller metadata er beskadiget, er dette ofte et godt første skridt.
Kontrollér afhængigheder og systemkonsistens
sudo dnf check
sudo dnf distro-syncDet hjælper med at afgøre, om systemet stadig passer til distributionens forventede pakketilstand.
Se historik
sudo dnf history
sudo dnf history info lastHistorikken viser ofte, efter hvilken opdatering problemerne begyndte.
Hvad skal kontrolleres, når pacman fejler
På Arch Linux skal man især fokusere på synkroniseringsdatabaser, nøgler, mirrors og eventuelle delvise opdateringer.
Synkronisér databaser igen
sudo pacman -SyyHvis den lokale synkroniseringsdatabase ikke længere passer til repository’et, er dette ofte første skridt.
Udfør en fuld opdatering
sudo pacman -SyuPå Arch bør delvise opdateringer undgås. At opdatere nogle pakker og lade andre forblive gamle er en klassisk vej til inkonsistens.
Kontrollér nøgleproblemer
sudo pacman-key --init
sudo pacman-key --populateHvis problemet ligger i signaturer eller keyring, kan en ny initialisering være nødvendig.
Logfiler er meget vigtige
Ved fejl i pakkehåndteringen er det sjældent nok at se på den sidste linje. Kun logfiler og detaljeret output viser, om problemet skyldes signaturer, afhængigheder, netværk eller databasen.
apt / dpkg
sudo tail -n 100 /var/log/apt/history.log
sudo tail -n 100 /var/log/dpkg.logdnf
sudo dnf history
sudo journalctl -xe --no-pager | tail -n 100pacman
sudo tail -n 100 /var/log/pacman.logPraktisk rækkefølge for fejlsøgning
Trin 1: Kontrollér netværk og DNS
ping -c 4 8.8.8.8
ping -c 4 google.comTrin 2: Kontrollér ledig diskplads
df -hTrin 3: Kontrollér processer og låsefiler
ps aux | grep -E 'apt|dpkg|dnf|yum|pacman'Trin 4: Læs logfilerne
Man bør først finde ud af, hvilken konkret handling der faktisk fejlede sidst.
Trin 5: Brug de rigtige gendannelseskommandoer til distributionen
For apt starter man ofte med dpkg --configure -a, for dnf med metadata-rensning, og for pacman med fuld synkronisering og nøglekontrol.
Hvad man bør undgå
- At slette låsefiler uden at forstå årsagen
- At installere tilfældige .deb / .rpm / andre pakker fra utroværdige kilder
- At foretage gentagne delvise opdateringer på Arch
- At blande apt med dpkg, dnf med rpm eller pacman med manuelle filændringer uden kontrol
- At deaktivere signaturkontrol uden at forstå fejlen
Sådan undgår du, at problemet vender tilbage
- Undgå strømafbrydelser og tvungen lukning under opdateringer
- Tilføj ikke for mange tredjeparts-repository’er
- Lav snapshots eller backup før større opdateringer
- Følg distributionens anbefalede opdateringsmetode
- Undgå især delvise opdateringer på Arch
Konklusion
Selv om det ser ud, som om det er apt, dnf eller pacman selv, der er gået i stykker, ligger den virkelige årsag ofte i netværket, låsefiler, signaturer, afhængigheder, cache, diskplads eller repository-indstillinger. Det vigtigste er ikke straks at slette eller geninstallere tilfældigt, men først at forstå gennem logfilerne, på hvilket niveau fejlen faktisk opstod. Derefter bør man bruge den rigtige fremgangsmåde: reparation af dpkg for apt, metadata og historik for dnf, samt fuld synkronisering og nøglekontrol for pacman.