Felsökning av Ubuntu APT: Åtgärda trasiga paket, hållningar och GPG-fel

APT-fel är vanliga på Ubuntu-maskiner med lång användningstid, och de dyker oftast upp efter en versionsuppdatering, en ändring av ett tredjepartsrepository, ett borttaget PPA, en manuellt installerad .deb-fil eller en avbruten paketinstallation.

Felmeddelandet kan se dramatiskt ut, men de flesta APT-problem är inte mystiska – de är tillståndsproblem där APT:s bild av repositoryn, versioner och installerade paket inte längre stämmer överens.

APT försöker besvara fyra frågor:

1. Vilka repositoryn är aktiverade?
2. Vilka paketversioner finns tillgängliga?
3. Vilka paket är redan installerade?
4. Vilka paketändringar är tillåtna?

När svaren på dessa frågor strider mot varandra får du paket som hålls tillbaka (kept back), trasiga beroenden, saknade nycklar, felaktiga PPA-fel eller paket som hålls tillbaka under uppdatering. Den här guiden ger dig en praktisk felsökningssekvens för Ubuntu APT, skriven för utvecklare, DevOps-ingenjörer och Linux-användare som vill laga systemet utan att blindt klistra in slumpmässiga kommandon från forumtrådar. Kombinera den med vår Ubuntu APT och dpkg cheat sheet för dagliga installations- och uppdateringskommandon, och bläddra i den bredare Utvecklarverktyg-samlingen för relaterade Linux-arbetsflöden.

Den korta versionen

Om ditt system bara är lätt skadat, börja här:

sudo apt update
sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt update
sudo apt upgrade

Om paket hålls tillbaka:

apt list --upgradable
apt-mark showhold
sudo apt full-upgrade

Om ett PPA eller tredjepartsrepository misslyckas:

ls /etc/apt/sources.list.d/
sudo apt update

Läs raden för det misslyckade repositoryt, inaktivera eller laga det repositoryt. Om du ser NO_PUBKEY, importera inte blindt slumpmässiga nycklar från en nyckelserver – hitta de officiella repositoryinstruktionerna, installera repositorynyckeln i /etc/apt/keyrings och bind den till det repositoryt med signed-by.

Innan du lagar något: Läs APT-felet först

Kör detta först:

sudo apt update

Hoppa inte över det. apt update uppdaterar paketmetadata. Den uppgraderar inte paket. Den berättar för dig om Ubuntu kan läsa alla konfigurerade repositoryn och verifiera deras metadata.

Kontrollera sedan din Ubuntu-version och kodnamn – ett gammalt versionsnamn i /etc/apt/sources.list.d/ är en vanlig orsak till 404- och Release-fil-fel. Om du är osäker på vilken version du är på, se hur du kontrollerar din Ubuntu-version:

lsb_release -a

Eller:

cat /etc/os-release

Kontrollera också vad som är uppdateringsbart:

apt list --upgradable

Och kontrollera om något paket hålls tillbaka:

apt-mark showhold

Detta ger dig den första uppdelningen i besluts trädet – att identifiera felklassen först underlättar felsökningen eftersom varje klass har en annan första fix:

• Repositoryproblem: apt update misslyckas.
• Beroendeproblem: apt update fungerar, men installation eller uppdatering misslyckas.
• Problem med hållna paket: APT vägrar ändra specifika paket.
• Problem med blandade källor: Ett PPA, en manuell .deb eller ett gammalt repository tillhandahåller inkompatibla versioner.
• Problem med avbruten installation: dpkg har packat upp paket som aldrig konfigurerats.

Vanliga Ubuntu APT-feltyper

Paket som hålls tillbaka (Kept Back)

Ett paket som hålls tillbaka är inte alltid ett fel; det betyder att APT valde inte att uppgradera ett paket med det aktuella kommandot. Detta händer ofta när uppdateringen kräver installation av nya beroenden, borttagning av gamla paket eller ändring av ett paket på ett sätt som vanlig apt upgrade inte utför.

Kontrollera detaljer:

apt list --upgradable
apt-cache policy package-name

Försök en full uppdatering först efter att ha läst vad APT vill göra:

sudo apt full-upgrade

full-upgrade får installera nya paket och ta bort paket om det behövs för att slutföra uppdateringen. Det är användbart, men det är också varför du bör läsa de föreslagna ändringarna innan du accepterar. På en arbetsstation är full-upgrade oftast okej efter granskning; på en server, läs borttagen lista två gånger.

Hållna paket (Held Packages)

Ett hållna paket är annorlunda än ett paket som bara hålls tillbaka. En hold (hållning) är ett explicit instruktion som förhindrar APT från att automatiskt installera, uppgradera eller ta bort det paketet. Holds är användbara för att fästa en kernel, databas, drivrutin eller runtime-version, och de är också lätta att glömma.

Lista hållna paket:

apt-mark showhold

Håll ett paket:

sudo apt-mark hold package-name

Ta bort en hållning:

sudo apt-mark unhold package-name

Om du ser beroendefel som involverar ett hållna paket, avgör om hållningen fortfarande är avsiktlig. Ta inte bort holds automatiskt. De kan skydda en produktionstjänst, drivrutin eller kompatibilitetskänslig verktygskedja.

Trasiga beroenden

Trasiga beroenden betyder att APT inte kan hitta en giltig paketuppsättning, vilket oftast pekar på ett versionskonflikt snarare än en korrupt nedladdning.

Vanliga orsaker inkluderar:

• Ett paket kräver en version som inte finns tillgänglig.
• Ett PPA tillhandahåller en nyare bibliotek än vad Ubuntu förväntar sig.
• Ett manuellt installerat .deb beror på paket från en annan version.
• En paketinstallation avbröts.
• Ett repository för fel Ubuntu-version är aktiverat.
• Paketpinning eller holds förhindrar den behövliga versionsändringen.

Börja med:

sudo dpkg --configure -a
sudo apt --fix-broken install

Inspektera sedan paketet:

apt-cache policy package-name
apt-cache depends package-name
apt-cache rdepends package-name

Använd sedan dessa kommandon för att hitta den paketversionskonflikt som blockerar APT, istället för att köra varje reparationskommando i följd.

GPG-nyckel och NO_PUBKEY-fel

Ett NO_PUBKEY-fel betyder att APT mottagit repositorymetadata, men den kan inte verifiera signaturen eftersom den erforderliga publika nyckeln saknas – ett förtroendeproblem, inte bara ett nedladdningsproblem.

Ett typiskt fel ser ut så här:

The following signatures could not be verified because the public key is not available: NO_PUBKEY ABCD1234EF567890

Gamla instruktioner använde ofta apt-key add, men undvik det för ny repositoryinställning. Moderna Ubuntu-system bör använda en repositoryspecifik nyckelring och signed-by.

Ett bättre mönster ser ut så här:

sudo install -d -m 0755 /etc/apt/keyrings

curl -fsSL https://example.com/repo-key.gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg

echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/apt stable main" \
  | sudo tee /etc/apt/sources.list.d/example.list

sudo apt update

Byt ut URL och repositoryrad mot de officiella instruktionerna från leverantören.

Den viktiga delen är denna:

signed-by=/etc/apt/keyrings/example.gpg

Den signed-by-raden binder nyckeln till ett repository, vilket är renare och säkrare än att lägga varje tredjepartsnyckel i en global förtroendelagring.

Bad PPA eller Release File-fel

PPA-fel ser ofta ut så här:

The repository does not have a Release file.

Eller:

404 Not Found

Vanliga orsaker:

• PPA:n stöder inte din Ubuntu-version.
• Du uppgraderade Ubuntu, men PPA:n pekar fortfarande på det gamla kodnamnet.
• PPA:n raderades.
• Underhållaren slutade publicera paket.
• Du lade till en PPA avsedd för en annan Ubuntu-version.

Kontrollera ditt kodnamn:

. /etc/os-release
echo "$VERSION_CODENAME"

Lista tredjepartskällfiler:

ls /etc/apt/sources.list.d/

Inspektera dem:

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

Inaktivera en misstänkt källa genom att byta namn på den:

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

Om APT fungerar efter att filen inaktiverats, har du hittat den problematiska källan och kan laga eller ta bort den permanent.

En säker APT-felsökningsarbetsflöde

Steg 1: Uppdatera metadata

sudo apt update

Om detta misslyckas, laga repositoryn innan du försöker paketreparation. APT kan inte lösa beroenden korrekt om dess paketindex är gammalt eller ofullständigt.

Leta efter rader som innehåller:

NO_PUBKEY
Release file
404 Not Found
does not have a Release file
The repository is not signed

Detta är repository- eller förtroendeproblem, och de bör lagas innan du försöker någon paketreparation.

Steg 2: Slutför avbruten pakethantering

Om en paketinstallation avbröts, kan dpkg ha packat upp filer men inte konfigurerat paketet.

Kör:

sudo dpkg --configure -a

Om detta lyckas, fortsätt:

sudo apt --fix-broken install

Om det misslyckas, läs paketnamnet och felet noggrant. Paketet som nämns i botten av felet är ofta viktigare än paketet du ursprungligen försökte installera.

Steg 3: Be APT laga beroenden

sudo apt --fix-broken install

Detta kommando ber APT korrigera beroendeproblem genom att installera saknade beroenden eller ta bort paket som inte kan uppfyllas. Läs den föreslagna åtgärden noggrant, särskilt några borttagningar.

Var försiktig om APT vill ta bort:

• ubuntu-desktop
• ubuntu-server
• linux-generic
• display manager-paket
• nätverkspaket
• databaspaket
• container runtime-paket
• skrivbordsmiljöpaket

Ibland är det ofarligt att ta bort ett metapaket. Ibland är det en varningssignal om att dina paketskällor är blandade dåligt. Acceptera inte stora borttagningar utan att förstå dem.

Steg 4: Kontrollera hållna paket

apt-mark showhold

Om ett hållna paket blockerar uppdateringen, inspektera det:

apt-cache policy package-name

Om hållningen inte längre behövs:

sudo apt-mark unhold package-name
sudo apt update
sudo apt upgrade

Om hållningen är avsiktlig, kämpa inte mot APT – laga repositoryt eller paketsammanställningen kring hållningen istället för att ta bort skyddet.

Steg 5: Inspektera paketversioner

För ett paket med beroendeproblem:

apt-cache policy package-name

Detta visar:

• Installerad version
• Kandidatversion
• Tillgängliga versioner
• Vilket repository som tillhandahåller varje version

apt-cache policy är ett av de mest användbara APT-felsökningskommandona eftersom det visar var varje tillgänglig version kommer ifrån.

Exempel:

apt-cache policy docker-ce

Om kandidatversionen kommer från ett oväntat PPA eller gammalt repository, har du hittat den troliga orsaken till beroendekonflikten.

Steg 6: Leta efter blandade repositoryn

Lista aktiverade källor:

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

Leta efter:

• Gamla Ubuntu-kodnamn
• Debian-repositoryn på Ubuntu
• PPAs för en annan Ubuntu-version
• Dubbla leverantörsrepositoryn
• Både Snap- och APT-instruktioner blandade för samma verktyg
• Gamla .list-filer som lämnats kvar efter avinstallation av programvara

Ett vanligt anti-mönster är att installera ett verktyg från en leverantörsrepository, och senare lägga till ett PPA eller manuell .deb som tillhandahåller överlappande bibliotek. APT kan hantera många källor, men den kan inte försona motstridiga intentioner om du inte justerar repositoryn själv.

Steg 7: Försök en simulerad installation eller uppdatering

Innan du gör ändringar, simulera:

apt -s install package-name

Eller:

apt -s full-upgrade

Flaggan -s simulerar operationen. Det är användbart när du vill se vad APT skulle göra utan att ändra systemet.

Laga hållna paket

Lista hållna paket

apt-mark showhold

Om inget skrivs ut, inga paket hålls med apt-mark, och du kan gå vidare till beroende- eller repositorykontroller.

Håll ett paket avsiktligt

sudo apt-mark hold package-name

Bra skäl att hålla ett paket:

• En kernelversion är känd för att fungera med din hårdvara.
• En databasuppgradering kräver planering.
• En drivrutinuppdatering kraschar din GPU.
• En runtime-version måste matcha produktionen.
• Ett leverantörs paket är inte kompatibelt med senaste beroende.

Dåliga skäl att hålla ett paket:

• Du kopierade ett kommando från en gammal guide.
• Du glömde varför det hölls.
• Du undviker ett beroendefel utan att förstå det.

Ta bort en hållning

sudo apt-mark unhold package-name

Uppdatera och uppgradera sedan:

sudo apt update
sudo apt upgrade

Om paketet fortfarande inte uppgraderas, var det inte bara ett hållningsproblem. Kontrollera policy:

apt-cache policy package-name

Laga trasiga beroenden

Den standardiserade reparationssekvensen

Använd denna sekvens när paketinstallation eller uppdatering misslyckades halvvägs:

sudo apt update
sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt upgrade

Denna ordning är viktig eftersom varje steg förbereder grunden för nästa: apt update uppdaterar repositorymetadata, dpkg --configure -a slutför konfigurering av packade paket, apt --fix-broken install låter APT försona saknade eller motstridiga beroenden, och apt upgrade återupptar normala paketuppdateringar.

Ta bort ett dåligt installerat lokalt paket

Om problemet började efter installation av en nedladdad .deb, inspektera det:

dpkg -l | grep package-name
apt-cache policy package-name

Ta bort det:

sudo apt remove package-name

Om konfigurationsfiler också orsakar problem:

sudo apt purge package-name

Laga sedan:

sudo apt --fix-broken install

Återinstallera ett skadat paket

Om ett paket är installerat men trasigt:

sudo apt install --reinstall package-name

Detta är användbart när filer saknas eller är korrupta, men paketskällorna i övrigt är friska och du vill uppdatera de installerade filerna utan att ändra versioner.

Laga PPA- och tredjepartsrepositoryproblem

Hitta PPAs och tredjepartsrepositoryn

ls /etc/apt/sources.list.d/

Visa aktiva repositoryrader:

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

På nyare Ubuntu-system kan du också se .sources-filer som använder deb822-formatet:

ls /etc/apt/sources.list.d/*.sources

Visa dem:

cat /etc/apt/sources.list.d/*.sources

Inaktivera en PPA säkert

Byt namn på källfilen:

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

För deb822-filer:

sudo mv /etc/apt/sources.list.d/example.sources /etc/apt/sources.list.d/example.sources.disabled
sudo apt update

Att byta namn på källfilen är reversibelt och säkrare än att radera repositorykonfiguration omedelbart, eftersom du kan byta tillbaka namnet om du inaktiverade fel källa.

Ta bort paket från en PPA

Att inaktivera en PPA stoppar framtida paketnedladdningar från den. Den downgraderar inte automatiskt paket som redan är installerade från den PPA:n.

Om PPA:n orsakade bibliotekskonflikter, kan du behöva downgradera paket tillbaka till Ubuntu-versioner.

Installera ppa-purge:

sudo apt install ppa-purge

Purgena sedan PPA:n:

sudo ppa-purge ppa:owner/name

Använd ppa-purge med försiktighet och läs de föreslagna ändringarna innan du accepterar, eftersom den kan ta bort eller downgradera flera relaterade paket.

Efter en versionsuppdatering

Efter att ha uppgraderat Ubuntu, är gamla PPAs en vanlig källa till fel.

Kontrollera gamla kodnamn:

grep -R "jammy\|noble\|oracular\|plucky" /etc/apt/sources.list /etc/apt/sources.list.d/

Justera kodnamnen för ditt riktiga system. Till exempel, om du är på Ubuntu 24.04, är ditt kodnamn noble. Om en tredjepartskälla fortfarande pekar på ett äldre kodnamn, verifiera om den leverantören stöder din aktuella Ubuntu-version. Om du ställer in en ny maskin snarare än att reparera en uppdatering, går vår Ubuntu 24.04 installationsguide igenom att lägga till leverantörsrepositoryn med signed-by från start.

Redigera inte bara kodnamnet och hoppas på det bästa – vissa repositoryn publicerar inte paket för varje Ubuntu-version, så verifiera leverantörsstöd för din version först.

Laga GPG- och NO_PUBKEY-fel

Vad NO_PUBKEY betyder

APT-repositoryn publicerar signerad metadata, och din maskin behöver den matchande publika nyckeln för att verifiera den metadata. Om nyckeln saknas vägrar APT att lita på repositoryt, vilket är beteendet du vill ha – inaktivera inte signaturekontroller bara för att få felet att försvinna.

Det moderna nyckelringmönstret

Skapa nyckelringmappen:

sudo install -d -m 0755 /etc/apt/keyrings

Ladda ner och dearmorera leverantörsnyckeln:

curl -fsSL https://example.com/repository-key.gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg

Ställ in läsbara behörigheter:

sudo chmod 0644 /etc/apt/keyrings/example.gpg

Lägg till repositoryt med signed-by:

echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/linux/ubuntu noble stable" \
  | sudo tee /etc/apt/sources.list.d/example.list

Uppdatera sedan:

sudo apt update

Byt ut noble mot ditt Ubuntu-kodnamn om nödvändigt:

. /etc/os-release
echo "$VERSION_CODENAME"

Varför apt-key är en dålig vana

Gamla guider använder ofta:

curl -fsSL https://example.com/key.gpg | sudo apt-key add -

Undvik apt-key add för nya installationer. Den gamla apt-key-stilen lägger till nycklar i ett brett förtroendeområde, vilket gör det svårare att resonera om vilken nyckel som litar på vilket repository, medan den moderna signed-by-stilen scopear nyckeln till ett specifikt repository och är grundläggande leveranskedjehygiene.

Hitta legacy-förtroende nycklar

Du kan fortfarande ha gamla nycklar i:

/etc/apt/trusted.gpg
/etc/apt/trusted.gpg.d/

Lista filer:

ls -l /etc/apt/trusted.gpg.d/

Radera inte nycklar slumpmässigt – mappa först varje nyckel till ett repository, migrera sedan ett repository i taget till /etc/apt/keyrings och signed-by.

Vanliga GPG-fel

Använd inte slumpmässiga nyckelservrar som ditt första val när du lagar NO_PUBKEY-fel.

Bättre ordning:

1. Använd leverantörens officiella installationsdokumentation.
2. Ladda ner nyckeln från leverantörens officiella HTTPS-URL.
3. Lagra den i /etc/apt/keyrings.
4. Bind den med signed-by.
5. Kör sudo apt update.

Undvik dessa genvägar:

sudo apt update --allow-unauthenticated
sudo apt install --allow-unauthenticated package-name

De kan fungera tillfälligt, men de tar bort signatureverifieringen som skyddar dig mot manipulerad repositorymetadata.

Laga “Repositoryt är inte signerat”

Detta fel betyder oftast något av följande:

• Repositoryt publicerar inte signerad metadata.
• Repository-URL:n är fel.
• Repositoryt stöder inte längre din Ubuntu-version.
• En proxy eller spegel returnerar fel innehåll.
• Du använder HTTP där leverantören nu förväntar sig HTTPS.
• Källfilen har fel suite eller komponent.

Hitta den misslyckade källan:

sudo apt update

APT kommer att skriva ut URL:n. Sök sedan efter den:

grep -R "example.com" /etc/apt/sources.list /etc/apt/sources.list.d/

Inaktivera den tillfälligt:

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

Om APT fungerar igen efter att filen inaktiverats, installera om det repositoryt från leverantörens aktuella officiella instruktioner snarare än att aktivera den gamla konfigurationen igen.

Laga varningar för dubbla repositoryn

APT kan varna att ett mål är konfigurerat flera gånger.

Lista matchande poster:

grep -R "repo-url-or-domain" /etc/apt/sources.list /etc/apt/sources.list.d/

Dubbla repositoryn dyker ofta upp efter att ha kört leverantörsinstallationsskript flera gånger.

Behåll en källfil. Inaktivera de andra:

sudo mv /etc/apt/sources.list.d/duplicate.list /etc/apt/sources.list.d/duplicate.list.disabled
sudo apt update

Dubblingsvarningar är inte alltid dödliga, men de är ett tecken på slarvig konfiguration, så behåll en källfil och inaktivera dubletterna.

Laga paket från fel Ubuntu-version

Ett av de värsta APT-problemen är att blanda Ubuntu-versioner – till exempel, en maskin på Ubuntu 24.04 bör inte casually dra paket från Ubuntu 22.04 eller Debian testing. Ibland fungerar det en stund, men till slut blir beroendegrafen ett pussel som APT inte kan lösa rent.

Kontrollera din version:

. /etc/os-release
echo "$VERSION_CODENAME"

Sök källor:

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

Leta efter främmande kodnamn i de aktiverade källorna, inspektera sedan det påverkade paketet:

apt-cache policy package-name

Om den installerade versionen kom från ett gammalt eller främmande repository, inaktivera det repositoryt och downgradera eller återinstallera det påverkade paketet från Ubuntu-repositoryn.

En konservativ reparationsväg är:

sudo apt update
sudo apt install --reinstall package-name

För djupare konflikter kan du behöva ta bort paketet och installera det om från korrekt källa snarare än att tvinga en uppdatering över en främmande version.

Rensa APT-cache och oanvända paket

APT-cache-rensning är inte en beroendefix i sig, men den kan hjälpa efter många misslyckade installationer genom att frigöra diskutrymme och rensa gamla paketfiler.

Ta bort paket som installerades automatiskt och inte längre behövs:

sudo apt autoremove

Rensa nedladdade paketfiler:

sudo apt clean

Eller ta bort bara oaktuella paketfiler:

sudo apt autoclean

Använd autoremove med försiktighet på servrar och skrivbord med manuellt installerade drivrutinsstackar, och läs borttagningslistan innan du accepterar.

Praktiska APT-felsökningsrecept

Recept: Paket hålls tillbaka

sudo apt update
apt list --upgradable
apt-mark showhold
sudo apt full-upgrade

Om APT föreslår rimliga ändringar efter simulering, acceptera dem. Om den föreslår stora borttagningar, stoppa och inspektera:

apt-cache policy package-name

Recept: Hållna paket blockerar uppdatering

apt-mark showhold
apt-cache policy package-name
sudo apt-mark unhold package-name
sudo apt upgrade

Ta bara bort hållning från ett paket om hållningen inte längre är avsiktlig, eftersom att ta bort en hållning som skyddar produktionsprogramvara kan utlösa en brytande uppdatering.

Recept: Avbruten installation

sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt upgrade

Recept: NO_PUBKEY-fel

1. Identifiera repositoryt från sudo apt update.
2. Hitta leverantörens aktuella officiella installationsinstruktioner.
3. Installera nyckeln i /etc/apt/keyrings.
4. Använd signed-by i källfilen.
5. Kör sudo apt update.

Exempelstruktur:

sudo install -d -m 0755 /etc/apt/keyrings

curl -fsSL https://example.com/key.gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg

sudo chmod 0644 /etc/apt/keyrings/example.gpg

echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/ubuntu noble main" \
  | sudo tee /etc/apt/sources.list.d/example.list

sudo apt update

Recept: PPA har ingen Release-fil

sudo apt update
ls /etc/apt/sources.list.d/
grep -R "ppa.launchpadcontent.net\|launchpad" /etc/apt/sources.list.d/

Inaktivera PPA:n:

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

Avgör sedan om du ska ta bort, ersätta eller purgea paket från den PPA:n.

Recept: Manuell .deb brakade beroenden

dpkg -l | grep package-name
apt-cache policy package-name
sudo apt remove package-name
sudo apt --fix-broken install

Om du fortfarande behöver programvaran, föredra leverantörens aktuella APT-repository framför upprepade manuella .deb-installationer, som tenderar att ackumulera beroendekonflikter över tid.

Väsentliga APT-felsökningskommandon

Repository och metadata

sudo apt update
grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/
ls /etc/apt/sources.list.d/

Pakettillstånd

apt list --installed
apt list --upgradable
apt-mark showhold
dpkg -l | grep package-name

Paketpolicy och beroenden

apt-cache policy package-name
apt-cache depends package-name
apt-cache rdepends package-name

Reparation

sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt install --reinstall package-name
sudo apt full-upgrade

Rensning

sudo apt autoremove
sudo apt autoclean
sudo apt clean

Simulering

apt -s install package-name
apt -s full-upgrade

Vad du inte ska göra

Radera inte /var/lib/dpkg slumpmässigt

Om du ser råd om att radera dpkg-tillståndsfilerna, var skeptisk. Dpkg-databasen är registret över installerade paket, och att radera delar av den kan förvandla ett reparerbart paketproblem till ett fullt systemåterställningsprojekt.

Inaktivera inte signatureverifiering

Undvik:

--allow-unauthenticated

Om ett repository inte kan verifieras, laga nyckeln eller inaktivera repositoryt snarare än att kringgå autentisering.

Blanda inte Ubuntu-versioner casually

Lägg inte till repositoryn för en annan Ubuntu-version om du inte förstår APT-pinning och beroendekONSEKVENSER.

Detta gäller särskilt för:

• Skrivbordsmiljöer
• Grafikdrivrutiner
• Python-stacks
• Container runtimes
• Kubernetes-paket
• Databaspaket

Behandla inte PPAs som ofarliga

PPAs är användbara, men de är fortfarande repositoryn som kan ersätta bibliotek och systempaket – vilket kan vara exakt vad du vill, eller exakt varför din nästa uppdatering brakar. Föredra PPAs för specifika applikationer, inte för breda systemgrundar, om du inte litar på underhållaren och förstår uppdateringsvägen.

APT-felsökningsbesluts träd

Använd denna mentala modell:

De flesta APT-problem blir hanterbara när du slutar behandla dem som ett stort fel och börjar separera repositoryhälsa, pakettillstånd, beroendelösning och förtroendekonfiguration – besluts trädet ovan är en genväg för den disciplinen.

Rekommenderad bas för utvecklingsmaskiner

För en ren Ubuntu-utvecklingsarbetsstation föredrar jag denna bas:

• Håll Ubuntu-repositoryn standard.
• Använd leverantörens APT-repositoryn endast när de är officiella och underhållna.
• Använd /etc/apt/keyrings och signed-by för tredjepartsrepositoryn.
• Undvik gamla apt-key-instruktioner.
• Undvik att blanda PPAs som ersätter kärn-systembibliotek.
• Använd containrar, uv, pipx, asdf, mise eller språkinhemliga verktyg för snabbt rörliga utvecklingsberoenden.
• Håll APT ansvarig för operativsystem, drivrutiner, tjänster och stabila CLI-verktyg.

För skrivbordsprogramvara, föredra Flatpak eller Snap framför PPAs när ett sandboxat universellt paket passar dina behov. APT är utmärkt när den hanterar basystemet, men den blir smärtsam när den tvingas bete sig som en universell utvecklingsberoendehanterare för snabbt rörliga språkökosystem.

Slutlig APT-felsökningschecklista

När APT är trasigt på Ubuntu, gå igenom denna checklista:

[ ] Kör sudo apt update och läs det första riktiga felet.
[ ] Kontrollera Ubuntu-kodnamn med /etc/os-release.
[ ] Slutför avbrutna installationer med dpkg --configure -a.
[ ] Reparera beroenden med apt --fix-broken install.
[ ] Kontrollera hållna paket med apt-mark showhold.
[ ] Inspektera paketversioner med apt-cache policy.
[ ] Inaktivera trasiga PPAs eller tredjepartsrepositoryn.
[ ] Ersätt apt-key-stil repositoryn med signed-by nyckelringar.
[ ] Simulera riskfyllda operationer med apt -s.
[ ] Läs borttagningar innan du accepterar full-upgrade eller autoremove.

APT är inte skör, men den är strikt, och den strängheten är en funktion: den förhindrar att osignerade repositoryn, omöjliga beroendesätt och accidentella paketbyten tyst ändrar ditt system. Det lugna sättet att laga APT är att bevara den strängheten, hitta det motstridiga tillståndet och reparera den minsta saken som faktiskt är fel.