Kvifor apt-cache viser installert (ingen) for VPN-pakken din
Installert (ingen) tyder at VPN-pakken ikkje er installert, ikkje at han manglar. Les linjene for kandidat, pinning og arkitektur før du endrar kjeldene.
Ein VPN-pakke som rapporterer Installed: (none) manglar ikkje; han er rett og slett ikkje installert. Linja som avgjer om du kan installere han, er Candidate, som APT leier ut frå indeksane, suite-namnet, arkitekturen og eventuelle pin-reglar som gjeld. Dei fleste rapportane om ein forsvunnen VPN-pakke viser seg å vere eit kandidatproblem og ikkje eit pakkeproblem. Les begge linjene før du rører ei einaste kjeldeoppføring.
Eg sjekkar kandidaten først fordi det kostar éin kommando og utelukkar halvparten av dei vanlege gjettingane.
Kva policy-utskrifta fortel deg
apt-cache policy les den lokale pakkebufferen, ikkje nettet. Han skriv ut den installerte versjonen, kandidatversjonen og ein tabell over kvar indeks som tilbyr pakken, med prioriteten som er knytt til han.
apt-cache policy openvpn
apt-cache madison openvpn
apt list -a network-manager-openvpnKandidaten er versjonen APT ville valt akkurat no. madison listar opp kva kvar kjelde tilbyr med sin prioritet, og det er slik du oppdagar ein pakke som finst i ein indeks, men taper pin-konkurransen. apt-cache-handboka dokumenterer begge som bufferlesingar, så ingen av dei beviser at spegelen er tilgjengeleg akkurat no.
Viss kandidatlinja er tom eller viser (none), er ingenting i dei konfigurerte kjeldene kvalifisert for dette systemet slik det er konfigurert.
Fire grunnar til at ein kandidat forsvinn
I praksis er årsaka nesten alltid éin av fire ting, og kvar har ei anna løysing.
Suite-namnet i kjeldene dine må samsvare med distribusjonen pakken vart bygd for. Eit Debian bookworm-system peika mot ein trixie-spegel, eller ein Ubuntu-utgåve som vart omdøypt i ei sources.list.d-fil under ei oppgradering, løyser ingenting for pakkar som berre finst i den andre suiten. Samanlikn lsb_release -cs med suite-feltet i kvar oppføring.
APT ser berre pakkar bygde for arkitekturene dpkg kjenner. Ein 32-bits container, eit arm64-avtrykk eller ein Raspberry Pi-installasjon som ber om ein pakke som berre vert levert for amd64, får ein tom kandidat i staden for ei feilmelding. dpkg --print-architecture og dpkg --print-foreign-architectures fortel deg kva sett du faktisk er i.
Komponentar tel også. Ein pakke i contrib eller non-free er usynleg når berre main er slått på, og universen til Ubuntu oppfører seg på same måte. Indeksen finst, og pakken er i han; lista di over påslåtte komponentar inneheld han berre ikkje.
Pinning er den stille. Ei fil i /etc/apt/preferences.d kan avgrense ein pakke under installasjonsterskelen, og då forsvinn ein heilt grei kandidat frå utskrifta medan indeksen framleis viser han. Fordi policy skriv ut prioritetane ved sida av kvar kjelde, er ein pakke der kvar kjelde har eit lågt pin-nummer det avslørande teiknet.
Utdaterte indeksar ser ut som manglande pakkar
Bufferen er eit augneblinksbilete. Viss den siste apt update feila på éin indeks, held førespurnadene fram med å svare frå den eldre kopien, og pakken du ventar på er kanskje ikkje i den kopien.
apt update skriv ut feil per indeks, så les dei i staden for å rulle rett til den siste linja.
Ei oppdatering som feilar på ein signaturfeil, ei utløpt release-fil eller ein utilgjengeleg spegel, lèt den førre indeksen stå. Det er ein fornuftig konstruksjon, fordi han held på ein fungerande buffer når ein spegel er kort nede. Biverknaden er at eit søk kan lukkast medan depotet er fråkopla. Det tyder også at fråværet av ein pakke ikkje beviser noko før du veit når indeksen sist vart henta. Sjekk fildatoane under /var/lib/apt/lists før du skuldar på pakkenamnet.
Namngje pakken du faktisk treng
OpenVPN er ein daemon, og delane folk vanlegvis vil ha, er separate pakkar.
Motoren, NetworkManager-pluginen og skrivebordseditoren er tre pakkar med tre namn, og pluginen har ein GTK-variant der namnet varierer mellom distribusjonar. apt-cache search --names-only openvpn matchar namn og oppgjevne namn i staden for skildringar, og det er det du vil når du omtrent veit kva tingen heiter.
Viss namnet verkeleg er ukjent, søk i skildringar éin gong, og gå deretter tilbake til eksakte namn. Ikkje legg til eit -gui-suffiks lånt frå ein annan distribusjon og konkluder med at pakken ikkje finst lenger.
Endre kjelder sist, og verifiser deretter transaksjonen
Å leggje til eit depot endrar kven som leverer oppdateringane dine, så det høyrer heime på slutten av undersøkinga, ikkje i byrjinga.
Før det, stadfest utgåve, arkitektur, komponent og pin-status. Skriv ned kva av dei fire du sjekka, slik at neste person ikkje gjer gjennomgangen på nytt. Viss alle fire er riktige og kandidaten framleis manglar, er den ærlege konklusjonen at denne utgåva ikkje leverer den pakken. Dei attverande høva er ein backport, ein leverandørpakke eller ei anna støtta utgåve, og kvart av dei er eit medvite val og ikkje ei gjetting.
Når kandidaten dukkar opp, simuler før du stadfester: apt-get install --simulate med pakkenamnet viser kva som ville blitt trekt inn og kva som ville blitt fjerna. Pakketilgjenge, installasjon og ein fungerande tunnel er framleis tre separate trinn, og tunnelen treng framleis profilen sin, påloggingsinformasjonen, rutene og DNS før han ber trafikk.