Frequently asked questions (Svenska)

Related articles

• Arch terminology
• Arch compared to other distributions
• Arch User Repository#Frequently asked questions
• General troubleshooting

Allmänt

Vad är Arch Linux?

Se artikeln om Arch Linux (Svenska).

Varför skulle jag inte vilja använda Arch?

Du kanske inte vill använda Arch om:

• du inte har förmågan/tiden/lusten för en "gör-det-själv"-GNU/Linux-distribution.
• du behöver stöd för en annan arkitektur än x86_64.
• du har en stark princip om att endast använda en distribution som enbart tillhandahåller fri programvara enligt GNU:s definition.
• du anser att ett operativsystem ska konfigurera sig självt, fungera direkt efter installationen och innehålla en komplett standarduppsättning av programvara och skrivbordsmiljö på installationsmediet.
• du inte vill ha en rolling release-GNU/Linux-distribution.
• du är nöjd med ditt nuvarande operativsystem.

Varför skulle jag vilja använda Arch?

Eftersom Arch is the best.

Vilka arkitekturer har Arch stöd för?

Arch stöder endast arkitekturen x86_64 (ibland kallad amd64). Stödet för i686 slopades i november 2017 [1].

Det finns derivatdistributioner för i686-arkitekturen [2] och ARM-processorer [3], som har sina egna community-kanaler. Dessa stöds inte av Arch Linux.

Om du vill att Arch ska stödja andra arkitekturer kan du hjälpa till med befintliga portningsarbeten eller starta ett eget. Se Getting involved#Help porting Arch Linux to other architectures.

Följer Arch Linux Foundation's Filesystem Hierarchy Standard (FHS)?

Arch Linux följer filsystemshierarkin för operativsystem som använder tjänstehanteraren systemd. Se file-hierarchy(7) för en förklaring av varje katalog och dess syfte. Specifikt är /bin, /sbin och /usr/sbin symboliska länkar till /usr/bin, och /lib samt /lib64 är symboliska länkar till /usr/lib.

Jag är en komplett GNU/Linux-nybörjare. Borde jag använda Arch?

Om du är nybörjare och vill använda Arch måste du vara villig att investera tid i att lära dig ett nytt system, och acceptera att Arch är utformat som en "gör-det-själv"-distribution; det är användaren som sätter ihop systemet.

Innan du ber om hjälp bör du göra din egen oberoende research genom att söka på webben, i forumet och i den utmärkta dokumentationen som tillhandahålls av Arch Wiki. Det finns en anledning till att dessa resurser gjordes tillgängliga för dig från första början. Många tusentals ideella timmar har lagts ner på att sammanställa denna utmärkta information.

Se även Arch terminology#RTFM och Installation guide (Svenska).

Är Arch designat för att användas som server? Skrivbordsdator? Arbetsstation?

Arch är inte designat för någon specifik typ av användning. Snarare är det designat för en viss typ av användare. Arch riktar sig till kompetenta användare som uppskattar dess "gör-det-själv"-natur, och som utnyttjar detta för att forma systemet efter sina unika behov. Därför kan Arch, i händerna på sin målgrupp, användas för praktiskt taget vilket syfte som helst. Många använder Arch på både sina hemmasystem och arbetsstationer. Och självklart körs archlinux.org, aur.archlinux.org och nästan hela Archs infrastruktur på Arch.

Jag gillar verkligen Arch, men utvecklingsteamet måste implementera funktion X

Get involved och bidra med din kod/lösning till communityn. Om den tas emot väl av communityn och utvecklingsteamet kanske den mergas. Arch-communityn bygger på bidrag och delning av kod och verktyg.

När kommer den nya releasen att göras tillgänglig?

Arch Linux-releaser är helt enkelt en live-miljö för installation eller systemräddning, som inkluderar meta package base och några andra paket. Releaserna ges vanligtvis ut under den första halvan av varje månad.

Är Arch Linux en stabil distribution? Kommer mitt system att gå sönder ofta?

Det är användaren som i slutändan är ansvarig för stabiliteten i sitt eget rolling release-system. Användaren bestämmer när uppgraderingar ska ske och mergar nödvändiga ändringar när det krävs. Om användaren vänder sig till communityn erbjuds hjälp ofta skyndsamt. Skillnaden mellan Arch och andra distributioner i detta avseende är att Arch verkligen är en "gör-det-själv"-distribution; klagomål om att saker går sönder är felriktade och oproduktiva, eftersom förändringar från upstream-utvecklare inte är Arch-utvecklarnas ansvar.

Se artikeln System maintenance för tips om hur du gör ett Arch Linux-system så stabilt som möjligt.

Arch behöver mer press (dvs. reklam)

Arch får gott om press som det är. Målet med Arch Linux är inte att bli stort; snarare sker en organisk och hållbar tillväxt naturligt inom målgruppen.

Arch behöver fler utvecklare

Det är mycket möjligt. Du är mer än välkommen att donera din tid! Besök forumet, IRC-kanalerna och sändlistorna för och se vad som behöver göras. Se även Getting involved för mer information.

Installation

Arch behöver ett installationsprogram. Kanske ett med GUI?

Ett gudat installationsprogram med ett textbaserat användargränssnitt finns tillgängligt. Se archinstall för detaljer.

Jag har installerat Arch, och nu är jag i ett skal! Vad gör jag nu?

Se General recommendations.

Vilken skrivbordsmiljö eller fönsterhanterare ska jag använda?

Eftersom det finns många tillgängliga bör du använda den som bäst uppfyller dina behov. Ta en titt på artiklarna Desktop environment och Window manager.

Vad gör Arch unikt bland andra "minimala" distributioner?

Se Arch compared to other distributions.

Systemunderhåll

Se även System maintenance.

Varför är mitt internet så långsamt jämfört med andra operativsystem?

Är ditt nätverk korrekt konfigurerat? Ta en titt på artikeln Network configuration. För avancerade konfigurationer kan du även titta på traffic shaping.

En av de mest använda pakteterna för kerneln, linux, tenderar att vara nyare än kerneln i andra, mer stabila Linux-distributioner. På grund av detta kan du i sällsynta fall uppleva en kernel-regression eller en drivrutinsbugg, särskilt om du använder Wi-Fi. Observera att de allra flesta av dessa buggar inte är specifika för Arch Linux, eftersom Arch Linux endast applicerar de mest grundläggande patcharna. Detta måste tas vidare upstream. Se #Jag har hittat ett fel i paket X. Vad ska jag göra?.

Varför använder Arch allt mitt RAM-minne?

Kort sagt: oanvänt RAM-minne är bortkastat RAM-minne.

Många nya användare lägger märke till att Linux-kerneln hanterar minne annorlunda än vad de är vana vid. Eftersom det går mycket snabbare att hämta data från RAM än från en lagringsenhet, cachar kerneln nyligen använd data i minnet. Den cachade datan rensas först när systemet börjar få slut på tillgängligt minne och ny data behöver laddas in.

Vi kan se skillnaden genom kommandot free:

$ free -h

               total        used        free      shared  buff/cache   available
Mem:           377Gi        40Gi       146Gi       1.1Gi       196Gi       337Gi
Swap:          377Gi       1.1Gi       376Gi

Det är viktigt att notera skillnaden mellan "free" (ledigt) och "available" (tillgängligt) minne. I exemplet ovan ser ett system med totalt 377 GiB RAM ut att använda mer än hälften, med endast 146 GiB som ledigt minne. Dock är 196 GiB av detta "buff/cache". Det finns fortfarande 337 GiB tillgängligt för att starta nya applikationer, utan att behöva swappa. Se free(1) för detaljer. Resultatet av allt detta? Prestanda!

Se denna fantastiska artikel om din nyfikenhet har väckts. Det finns också en webbplats dedikerad till att reda ut detta missförstånd: https://www.linuxatemyram.com/.

Vart tog allt mitt lediga diskutrymme vägen?

Svaret på den frågan beror helt på ditt system. Det finns några bra verktyg som kan hjälpa dig att hitta svaret.

Varför kan jag inte logga in?

Har du skrivit fel lösenord eller avbrutit ett sudo-kommando tre gånger inom loppet av femton minuter? I så fall har du utlöst en skyddsmekanism mot brute-force-attacker: se Security#Lock out user after three failed login attempts för mer information.

Skickar Arch telemetri ("ringer hem")?

Kort sagt? Nej.

Mer i detalj:

• Användare av NetworkManager bör känna till att det gör automatiska anslutningstester. Standard-URL:en för anslutningstester tillhandahålls av Arch och är bunden till att inte logga några åtkomster.
• Network Time Protocol-klienter använder i sin standardkonfiguration en leverantörspool av NTP-servrar som tillhandahålls av NTP Pool Project (enligt deras regler).
• Som förklaras i noten i pacman/Package signing#Upgrade system regularly, körs en systemd-timer en gång i veckan för att uppdatera de nya signaturerna för redan betrodda nycklar. Ingen loggning av åtkomst sker där heller.
• Verktyget för att uppdatera spegellistan, Reflector (för de som använder det), laddar ner spegellistan från archlinux.org.

Du kan frivilligt välja att bidra till projektet pkgstats, som samlar in anonym data om pakets popularitet för att hjälpa Arch-utvecklarna att prioritera sina insatser.

Pakethantering

Se sidorna pacman, pacman/Tips and tricks och Official repositories för fler svar.

Jag har hittat ett fel i paket X. Vad ska jag göra?

Först måste du ta reda på om detta fel är något som Arch-teamet faktiskt kan åtgärda. Ofta är det inte det (t.ex. om Firefox kraschar kan det vara Mozilla-teamets fel); detta kallas för ett upstream-fel, se Bug reporting guidelines#Upstream or Arch?. Om det är ett Arch-problem finns det en serie steg du kan ta:

1. Sök i forumet efter information. Se om någon annan har lagt märke till det.
2. Skicka in en felrapport med detaljerad information på Arch Linux buggtracker i GitLab.
3. Om du vill kan du skriva ett foruminlägg som beskriver problemet och nämna att du redan har rapporterat det. Detta hjälper till att förhindra att många människor rapporterar samma fel.

Arch-paket borde använda en unik namnkonvention. ".pkg.tar.zst" är för långt och/eller förvirrande

Detta har diskuterats på Archs sändlista. Vissa föreslog filändelsen .pac, och det finns inga planer på att ändra paketändelsen. Som Tobias Kieslich, en av Arch-utvecklarna, uttryckte det: "Ett paket är ett [komprimerat] tar-arkiv! Och det kan öppnas, undersökas och manipuleras av vilket tar-kompatibelt program som helst. Dessutom detekteras mime-typen automatiskt korrekt av de flesta program."

Pacman behöver ett bibliotek så att andra applikationer enkelt kan komma åt paketinformation

Pacman är ett gränssnitt till libalpm(3) — "Arch Linux Package Management"-biblioteket — vilket gör det möjligt att skriva alternativa gränssnitt, exempelvis ett GUI-gränssnitt.

Pacman behöver funktion X!

Om du tycker att en idé har potential kan du välja att diskutera den på pacman-dev. Kontrollera även https://gitlab.archlinux.org/pacman/pacman/-/issues för befintliga funktionsförfrågningar.

Det bästa sättet att få en funktion tillagd i pacman eller Arch Linux är dock att implementera den själv. Patchen eller koden kanske inte accepteras officiellt, men andra kommer säkert att uppskatta, testa och bidra till ditt arbete.

Jag har just installerat Paket X. Hur startar jag det?

Om du använder en skrivbordsmiljö som KDE eller GNOME bör programmet automatiskt dyka upp i din meny om det levereras med en desktop entry. Om du försöker köra programmet från en terminal och inte vet namnet på den binära filen, använd:

$ pacman -Qlq package_name | grep /usr/bin/

Varför finns det bara en enda version av varje delat bibliotek (shared library) i de officiella repositorierna?

Flera distributioner, som till exempel Debian, har olika versioner av delade bibliotek paketerade som olika paket: libfoo1, libfoo2, libfoo3 och så vidare. På så sätt är det möjligt att ha applikationer installerade på samma system som är kompilerade mot olika versioner av libfoo.

När det gäller en distribution som Arch stöds endast de senaste paketerade versionerna officiellt. Genom att slopa stödet för föråldrad programvara kan paketansvariga lägga mer tid på att se till att de nyaste versionerna fungerar som förväntat. Så snart en ny version av ett delat bibliotek blir tillgänglig från upstream läggs den till i repositorierna, och berörda paket byggs om för att använda den nya versionen.

Vad händer om jag gör en fullständig systemuppgradering och det kommer en uppdatering för ett delat bibliotek, men inte för de applikationer som beror på det?

Detta scenario ska inte inträffa överhuvudtaget. Förutsatt att en applikation som heter foobaz finns i ett av de officiella repositorierna och kan byggas framgångsivt mot en ny version av ett delat bibliotek som heter libbaz, kommer den att uppdateras tillsammans med libbaz. Om den däremot inte kan byggas, kommer paketet foobaz att få ett versionsberoende (t.ex. libbaz 1.5) och tas bort av pacman under uppgraderingen av libbaz på grund av en konflikt.

Om foobaz är ett paket som du byggt själv och installerat från AUR, bör du bygga om foobaz mot den nya versionen av libbaz. Om bygget misslyckas, rapportera buggen till utvecklarna av foobaz.

Är det möjligt att det kommer en stor kernel-uppdatering i repositoriet utan att vissa av drivrutinspaketen har uppdaterats?

Nej, det är inte möjligt. Stora kernel-uppdateringar (t.ex. linux 3.5.0-1 till linux 3.6.0-1) åtföljs alltid av ombyggnader av alla drivrutinspaket för kerneln som stöds. Å andra sidan, om du har ett drivrutinspaket som inte stöds (t.ex. från AUR) installerat på ditt system, kan en kernel-uppdatering göra att saker slutar fungera om du inte bygger om det för den nya kerneln. Användarna är själva ansvariga för att uppdatera eventuella drivrutinspaket som inte stöds som de har installerat.

Vad ska man göra före en uppgradering?

Följ instruktionerna i avsnittet System maintenance#Upgrading the system.

En paketuppdatering släpptes, men pacman säger att systemet är uppdaterat

pacman-speglar synkroniseras inte omedelbart. Det kan ta över 24 timmar innan en uppdatering blir tillgänglig för dig. De enda alternativen är att ha tålamod eller att använda en annan spegel. MirrorStatus kan hjälpa dig att identifiera en spegel som är uppdaterad.

Upstream-projekt X har släppt en ny version. Hur lång tid tar det innan Arch-paketet uppdateras till den nya versionen?

Paketuppdateringar släpps när de är klara. Den specifika tiden kan variera från så kort tid som några timmar efter att upstream släppt en mindre buggfix, till så lång tid som flera veckor efter en stor uppdatering av en stor paketgrupp. Tiden det tar från en ny upstream-version till att Arch släpper ett nytt paket beror på de specifika paketen och tillgängligheten hos de paketansvariga. Dessutom ligger vissa paket en tid i repositoriet testing, vilket kan förlänga tiden innan ett paket uppdateras. Paketansvariga försöker arbeta snabbt för att få ut stabila uppdateringar till repositorierna. Om du hittar ett paket i de officiella repositorierna som är föråldrat, bör bumpbuddy automatiskt ha uppmärksammat den ansvariga tack vare nvchecker-filerna i varje enskilt repository (se detta exempel i paketet chromium).

Om jag behöver en äldre version av ett installerat bibliotek, kan jag då inte bara skapa en symlänk till den nyare versionen?

Om du har tur kan det fungera en tid. Oavsett vilket är det inte en korrekt lösning, eftersom:

• Bibliotek ändrar inte versioner slumpmässigt – API/ABI har troligtvis ändrats (kanske med borttagna delar), och om dessa ändringar påverkar användningen är bara en fråga om tur.
• Symlänken skulle inte spåras av pakethanteraren. Nybörjare som omedelbart försöker hacka på systemets biblioteksfiler löper störst risk att göra en oönskad ändring som de inte kan diagnostisera/åtgärda, vilket en pakethanterare annars hjälper till att skydda mot.
• Ett alternativ som innebär att man dumpar den gamla biblioteksfilen i filsystemet utan att den spåras, skulle glömmas bort och eventuella säkerhetsbuggar skulle inte upptäckas eller patchas.

Använd eller skriv istället ett kompatibilitetspaket (compat-paket) som tillhandahåller den biblioteksversion som krävs.

64-bit

Hur avgör jag om min processor är x86_64-kompatibel?

Om din processor är x86_64-kompatibel kommer du att ha flaggan lm (long mode) i /proc/cpuinfo. Till exempel:

$ grep -w lm /proc/cpuinfo

Under Windows kan du använda gratisprogrammet CPU-Z för att avgöra om din processor är 64-bitars kompatibel. Processorer med AMD:s instruktionsuppsättning "AMD64" eller Intels lösning "EM64T" bör vara kompatibla med x86_64-releaser och binärpaket.

Varför 64-bitars?

Det är snabbare under de flesta omständigheter och som en extra bonus också inneboende säkrare tack vare strukturen hos Address space layout randomization (ASLR) i kombination med Position-independent code (PIC) och NX Bit, vilket inte är tillgängligt i i686-standardkerneln på grund av inaktiverat Physical Address Extension (PAE). Om din dator har mer än 4 GiB RAM-minne kommer endast ett 64-bitars operativsystem att kunna utnyttja det fullt ut.

Programmerare tenderar också i allt högre grad att bry sig mindre om 32-bitars ("legacy") eftersom "nya" x86-processorer vanligtvis stöder 64-bitarsinstruktionerna.

Det finns många fler anledningar vi skulle kunna lista här för att råda dig att undvika 32-bitars, men mellan kerneln, userspace och enskilda program är det helt enkelt inte lönt att lista varenda sak som 64-bitars gör så mycket bättre nuförtiden.