Hur långlivad blir en Linux installation?

Det tycker jag inte. Den gör det den ska, och inget annat.
Det skulle vara så gott som omöjligt för en pakethanterare att kolla själva funktionaliteten hos det den installerar.

Om man räknar med att man har /home/saab på en egen partition och kopierar över rubbet när man byter hårddisk, då är min Linux kanske över femton år, eftersom jag började med Linux julen 1997.

Vet inte. Har aldrig provat med mer än hemkatalogen...

Det kanske går, eller?

Ja, det går alldeles utmärkt. Boota upp en livemijlö och rsync:a över partitionerna till den nya disken samt gör eventuella konfigurationsändringar. Förmodilgen kommer du även behöva installera om din bootloader också, men sen är det bara att byta disk och tuffa vidare.

Linux är i smidigt när man uppgraderar hårdvaran. Bytte moderkort och processor från Intel core 2 Quad till AMD FX-8350 utan att behöva installera om operativsystemet. Bootade utan problem. Regenererade linux image-filer (sägs man ska göra det för att optimera mot egna hårdvaran) och allt funkar på samma sätt som innan.

Detta brukar inte funka så bra med Windows. Antar det har göra med moduläriteten hos Linux? Det bidrar i alla fall till att förlänga livet på linuxinstallationen.

Har flera Fedora 8 och 10 som rullar ännu (inst. 2008 och 2009 c:a), F8 är installerad på servrar och nät utan Internetåtkomst så de uppdateras väldigt sällan, och aldrig hela systemet som helhet.
Granskar alltid uppdateringar innan installation, och lägger endast in som som behövs, obs. att det är slimmade installationer och inte standardpaket.

Ska kernel bytas/ändras så byggs den separat och den gamla behålls tills den nya är bekräftad som väl fungerande.

Det enda och vanligaste problem att Linux(Ubuntu) i detta fallet går ner efter uppdatering är att,

1, Ubuntu valde att uppdatera Xorg fast inga drivrutiner var färdiga. (ClosedSource)
Detta var ganska känt problem och många hade problem.

2, Kerneln uppdateras men GRUB har inte uppdaterat sin lista.
Update managern i Ubuntu samt andra distros har jag aldrig litat på så mycket. Men oftast när jag kört Ubuntu så märkte jag att exempelvis grub-update failade eller att när den frågade om man ville ändra configs vid en ny version av grub där ibland det kunde sluta med ej fungerande grub.

3, Korrupt initramfs. Detta är bland det vanligaste problemet vad jag stött på. Detta är oftast hårdvaru fel eller användare som inte tittar när han klickar ctrl-c eller cancel.

4, Intel fuckups med deras drivrutiner.
Nästan alltid har det varit Intel som totalt failat med deras re re-reverse reverse re-re-rereverse commit på deras drivrutiner antingen till Wifi eller deras i915. Ta en titt på deras commit lista för att få en total brain fart. Ganska nyligen med 3.10.9 Kerneln där UEFI + i915 slutar med obrukbar drivrutin. (Fick själv ladda ner en patchad kernel som inte har deras re-re-re-re-re reverse av commits).

Det vanligaste problemet med dagens linux är att AMD inte lyckats släppa färdiga drivrutiner till senaste Xorg eller Kernel. Där Arch utvecklarna rent ut slängde ut AMDs drivrutiner från deras repo.

Jag har själv aldrig haft större problem vid uppdateringar förutom just Xorg (på AMD) eller nu med intels fuckup på i915 modulen.

Hade Ubuntu på min server som uppdaterades på en dag från 7.10 till 13.04 med alla versioner emellan utan problem alls. Fick bara städa upp lite program jag inte använde längre efteråt. Min Arch har jag haft på min stationära i snart 5+ år.

Angående att program kräver senaste library är en variant av det. Sedan kan du ha att varje program skall komma med egen variant. Eller skall man använda Windows tänket och ha att alla program kommer med egen version som sedan skriver över systemvarianten?

Nej. det är inte menat så.
Men det problemet finns inte med stabila distributioner heller.
När det kommer till Linux, har man valfriheten att använda olika typer av distributioner:

• Statisk. En distribution tänkt att installeras och användas. Uppdateras nästan aldrig. I regel är det små kompakta lösningar som kör den här typen av distributioner. Exempelvis elektroniska fotoramar, skyltsystem, service-terminaler med mera. Uppdatering sker bara när det är absolut nödvändigt. Stabiliteten är total. Det finns inte mycket som kan få en sådan här distribution att fallera. Allvarliga hårdvaru-fel möjligen.

• Stabil. Mycket vanligt förr i tiden då Internet fortfarande var dyrt och inte fanns i varje hem. Uppdatering sker när en ny version av distributionen ifråga dyker upp, och då har allt testats minutiöst för att se till att nyinstallationer såväl som uppgradering sker smärtfritt. Kan liknas med Windows. Det är sällsynt att fel uppstår i och med uppgraderingar, men i regel är det exotisk och udda hårdvara som ställer till det.
  Företag, skolor med mera är intresserad av den här typen av distribution eftersom man inte vill lägga ner för mycket tid på buggar och problem. I regel behöver användarna inte ha de senaste uppdateringarna.

• Rullande. Uppdateringarna kommer allt eftersom de görs tillgängliga. För det mesta så testas varje uppdatering gentemot typiska och vanliga hårdvaru-lösningar. Däremot så kan inte allt testas minutiöst. Det är ändå upp till användaren att backa tillbaks till en tidigare version av ett paket om det visar sig uppstå problem. Bra om man också anmäler buggar och problem till distributionens rapporterings-system.
  Fördelen är att man får uppdateringarna tidigt och behöver inte vänta speciellt länge. Nackdelen blir att ansvaret ligger lite på en själv.

• Bleeding Edge. För de som bara MÅSTE ha det senaste av det senaste. Helst innan det ens hunnit testas. Ansvaret ligger helt och totalt hos användaren. De som är intresserade av den här typen av distribution är utvecklarna själva. Man vill se till att ens projekt fungerar med de senaste biblioteken, och man har möjligheter att lösa buggar i god tid innan man låter över sina alster till de stabila distributionerna.

Det låter som om ni har testat en så kallad "Bleeding Edge" distribution, och klagar sedan på att de inte är stabilt nog.
Ni har möjligheten att köra en stabil distribution och slipper därmed bekymren som uppstår med rullande och/eller bleeding edge- distributioner.
Sedan är detta också rätt förvirrande för många att ha dessa valmöjligheter. Många begår också misstaget att köra en typ av distribution som inte passar ens användningsområde.

Jag kan däremot hålla med om att en del distributioner är lite luddiga, och verkar röra sig i en gråzon mellan rullande och bleeding edge. För en del verkar "bleeding Edge och "rullande" vara samma sak.

Om det är Ubuntu som har provats och klagas över. låter det som om ni borde ha satsat på LTS-versionen av Ubuntu istället. LTS är stabilare än de övriga och har inte samma tendens att plötsligt fallera.

EDIT:
Är det något man skall klaga på, så är det distributionen och dess utvecklare. Inte Linux i sig.
Fallerar en distribution på en viktig punkt (I ditt fall uppdaterings-stabilitet), så väljer man en annan som är bättre på den punkten. Du kanske skulle ha provat Ubuntu's LTS-version istället?
Om det inte har framgått redan, så repeterar jag det som andra har skrivit: Linux är en av de stabilare kärnorna, och man skulle inte köra den i kritiska system om så inte vore fallet.
Så.. ja "Hur långlivad blir en Linux installation" går inte att svara på. Det beror både på användaren och distributionen.

Mätpunkt: jag installerade det Debiansystem jag skriver detta på 2005. Började som Stable 3.1 (som startades med en minimal nätverksinstallation på CD), men ändrade paketkällan till Unstable en kort tid därefter vilket uppgraderade saker mjukt, och har körts sedan dess. Det har överlevt två kompletta moderkort/CPU/minne/grafikkortsbyten under denna tid och bor på sin andra eller tredje hårddisk, men installationen har bara speglats vidare. Det finns inga planer på att "börja om på nytt", och om det skulle behövas så finns det backup på `/etc`, `/home` och andra liknande delar som snabbt kan återställas.

Jag sköter om ett par andra installationer som också bara migrerats framåt utan egentlig "ominstallation"; exempelvis ett Ubuntusystem från 2005 som just nu är 12.04 (och har inte planerat att uppgradera detta eller dess kompismaskiner förrän nästa LTS).

Har även skötsel av en Fedoraserver där tillvägagångssättet är annorlunda: med jämna mellanrum så är deras uppgraderingar "hårda", och kräver en mer omfattande uppgradering än att bara "rulla över". Dock så kunde senaste sådana uppgraderingen faktiskt även den skötas helt över en SSH-uppkoppling, så skiv/USB-uppgraderingar är förhoppningsvis ett minne blott även där.

Som påpekats många gånger i tråden så finns det vanligen inga inneboende anledningar att behöva "installera om", men beroende på distribution och vald gren så kan uppgraderingsprocessen te sig annorlunda, och inte minst kan intervallen mellan "hårda" OS-uppgraderingar skilja sig åt (och det är ju ofta en bra idé att åtminstone följa versioner med någon form av säkerhetsuppdateringar).

Att installera om till samma version bara för att något gått åt pipan ska aldrig behöva göras, och synnerligen inte på grund av att distributionen själv krånglat till något (då är det en grav bugg — så pass grav att jag ännu inte träffat på dess like). Det går att föreställa sig exotiska fall då det kan vara behövligt (jag har rekommenderat ominstallation till personer som kört `chmod 777 -R /*`, då jag känner att det skulle krävas mer arbete att återställa denna gravt icke rekommenderade åtgärd än att bara börja om), men det ska mycket till. Även om man skulle mötas av en "kernel panic" vid uppstart (vilket jag upplevt under experiment med egenkompilerade kärnor) så ska det bara vara att välja en stabil kärna och köra. Har man tagit bort alla fungerande kärnor så är det något som får räknas som ett handhavandefel, för detta ska inte vara något som händer av sig själv. Fortfarande kan situationen räddas med live-CD eller dylikt.

Kul med såna här trådar. Kan inget om Linux men det är ju hur intressant som helst att läsa alla svar.

Jag känner lite att jag skulle vilja installera om Arch Linux eftersom det med tiden blivit lite rörigt och jag inte längre har full kontroll på alla konfigurationsfiler jag moddat under åren (de moddar jag gjort kanske inte längre är relevanta). Vill ha ett rent fräscht system från grunden. Absolut inte så att det inte fungerar det jag har nu men på något sätt har jag inte full kontroll längre. Ska jag skämmas utifall jag installerar om tycker ni?

Hur gör ni andra? Loggar ni alla ändringar ni gjort så ni enkelt kan återställa ursprunget? Själv har jag nog inte ens ersatt alla gamla konfigfiler med de .pacnew som kommit. Hade inte riktigt koll på det där i början. Ibland tas program bort från officiella repositorys men de ligger kvar i min installation i en gammal version som inte längre uppdateras. Jag kanske missar att de ersatts av något annat. Jag installerar saker manuellt från AUR som jag glömmer uppdatera när det kommer nya versioner. Hur har man koll på sådant? För egen del är det först när saker börjar småkrångla man börjar fundera över saken och då kanske man inte längre minns vad man gjort.

Jag vill "göra om och göra rätt" men hur gör man rätt? Behövs det någon särskild underhållsstrategi om man vill få en långlivad linuxinstallation som man fortfarande har full kontroll över? Eller är det normalt att vilja starta om på ny kula sisådär varannat år? En grej jag funderar på är att ha ständig spegling av min installation till filservern som kör ZFS och snapshots så man kan göra rollback (typ köra rsync en gång i kvarten). Eller så gör jag som med min htpc och nätverksbootar direkt från filservern via NFS, men detta är betydligt långsammare än att köra mot SSD-disken. I och för sig skulle jag kunna köra btrfs med snapshots eller ZFS på mitt rootfilsystem. Å andra sidan har jag inte behövt göra några rollbacks utan det är snarare det här vardagsunderhållet som jag saknar strategier för. Kanske lära mig mera om hur pacman fungerar? Tror nog man kan få hygglig kontroll över vad som är installerat, vad som inte längre finns i repositories, vad som man själv installerat manuellt och så vidare om man lär sig mera om sin pakethanterare.

Så ni som lyckats hålla långlivade installationer - hur håller ni kontroll på att systemet är likadant som det hade varit om ni istället hade gjort en ny installation? Alltså hur rensar man bort gammal skit?

Givetvis inte, det finns säkerligen saker att lära sig av att installera om också. Att göra det vid minsta "motgång" är dock klart mindre lärorikt än att lösa de faktiska problemen, men av olika anledningar kan man stå en dag och behöva installera om (hårdvarukrasch, etc.) och definitivt så kommer man behöva göra nyinstallationer ibland. Då är det bra att ha lite vana. Gör man det för att lära sig så är det verkligen inget att "skämmas för" (kan även appliceras på mycket annat i livet ).

Det finns ett ganska drastiskt tillvägagångssätt som jag kan se har intressanta följder: att hålla hela `/etc` i ett versionshanteringssystem med exempelvis etckeeper. Då har man järnkoll på alla ändringar bakåt i tiden, och varför de gjordes. Så långt har jag inte gått än .

I övrigt så skulle jag säga att det är rätt få ändringar som behöver hållas koll på. Kör man servertjänster som t ex Apache så har man troligen mycket däri, men det brukar organiseras tydligt genom distributionen. Om min systemdisk skulle dö och jag skulle behöva installera om så skulle jag behöva återinföra icke-triviala `/etc`-filer för 3–4 program (främst server- och nätverksrelaterade saker: Shorewall, Apache, Pure-FTPd) samt återinstifta några egna `/etc/init.d`-tjänster, men det är egentligen allt. Relevanta konfigurationsfiler jag behöver i övrigt ligger i hemkatalogen, men ändringar där "smutsar inte ner" systemet i sig.

Jag försöker hela tiden hålla mig á jour med distributionens konfigurationsfiler i största möjliga mån. Ifall t ex Aptitude frågar mig om jag vill ersätta en modifierad konfigurationsfil med distributionens nya version så diffar jag alltid skillnaden (vilket görs direkt inifrån gränssnittet) och ser till att min konfigurationsfil är identisk med distributionens, förutom just de medvetna lokala ändringar jag gjort. I praktiken är det sällan som konfigurationsfiler ändras på det sättet, speciellt om man följer en stabil distribution, så det är ingen större arbetsbörda.

En sak jag upptäckte på min installation var att jag av okunskap ibland installerat onödiga paket (vanligen hjälpbibliotek) explicit, i stället för att låta dem dras in av beroenden. För att förtydliga så hade jag kanske kört `aptitude install apache2 apache2-bin apache2.2-common`, istf bara `aptitude install apache2` vilket på egen hand skulle dragit in hjälppaketen automatiskt. När sedan distributionen skulle uppgradera Apache till 2.4 så konfliktade detta naturligen med Apache 2.2, vilket i vanliga fall skulle hanteras automatiskt och ge en mjuk övergång korrekt då jag ju egentligen bara varit intresserad av "Apache 2". Eftersom jag gjort fel så kunde systemet inte veta om paketet `apache2.2-common` var installerat per automatik och kunde tas bort, eller om det var ett paket som jag verkligen ville ha installerat. Jag hade flera sådana möjliga konflikter i systemet när jag tittade efter, men det var fullt lösbart att sitta i Aptitudes gränssnitt och se till att alla hjälppaket var markerade som "automatiskt installerade". Det "korrekta" sättet är att vara generell och låta paketsystemet sköta resten.

Närbesläktat så hade jag explicit installerat bibliotek som jag använde till egna programmeringsprojekt. Dessa bibliotek kunde inte dras in automatiskt av pakethanteringssystemet eftersom det inte kan veta vad mina personliga projekt kräver, men det korrekta sättet när jag vill att de ska interagera med APT vore att skapa ett dummypaket med `equivs` som berättar detta.

Kontentan av ovanstående är att det alltid finns saker som man lär sig med tiden, men att det åtminstone i ovanstående situation gick att lösa med lite extraarbete (vilket är lätt att lägga ner när det känns lärorikt).

Jag har inte använt Pacman, men det har säkert Aptitude-liknande möjligheter att presentera och modifiera denna paketinformation.

Just det ja. Jag har precis bytt moderkort och processor och det nya har Giabyte "Hybrid EFI" någonting. Den gamla installationen med en BIOS boot partition och GPT funkade ändå (Hybrid EFI står inställt på Auto i BIOS). Men man kanske skulle passa på och lära sig det här med EFI, om det nu är relevant på mitt nya moderkort GA-970A-UD3.

Byter också grafikkort från nvidia till AMD så det blir också skoj att labba med.

Intressant sport att hålla liv i gamla installationer, de flesta normala Linux är stabila "forever" så länge man inte drabbas av uppgraderings-djävulen.

Skall man köra en rullande release, särskilt en rullande med bleeding edge-paket, så får man räkna med att man ibland drabbas av att det inte ens går att hinna in till en kommandorad innan det hänger sig. Även på de gamla kärnor man sparat i Grub. Det går att rädda en sådan installation mha en livedist, men om man inte har TID att hålla på att pyssla så:

Är den bästa Linuxen den som går snabbast att återställa till fullt fungerande skick. I alla fall för desktop. Och bäst där är fortfarande Ubuntu imho, eftersom nästan allt är färdigkonffat så är det bara att köra igång direkt och dra igång allt man såklart alltid har gjort backup på igen. Snabbt, fort och smidigt till ett komplett desktop, hur bra som helst

Snapshots är bra, det kräver dock fortfarande en hel del pysslande för att få det att fungera och om man som jag sa ovan inte ens hinner komma in till en kommandorad hjälper snapshots föga. Om man kommer så långt som till just en kommandorad brukar man kunna rädda det mesta, även utan snapshots, eftersom man i allmänhet vet ungefär vad man uppgraderat och det finns sätt att kolla det på också. Visst kan det vara värt besväret att sätta upp en smidig snaphot-mekanism om man har sitt älskade "perfekta" skrivbord superkonfigurerat, vilket säkert tar veckor att återställa från scratch, men som sagt där har Ubuntu sin poäng i just att nästan ingenting behöver konffas. Det är bara att köra, mycket som Windows och OSX ja.

Angående Fedora, det är en utmärkt workstation-dist som har tagit säkerhet och stabilitet på allvar, Ubuntu är rena sållet i jämförelse. Men på ett konsument-dekstop är "rena sållet" otroligt mycket smidigare att använda. Det är mycket som är oerhört krångligt att få igång att fungera på Fedora, även om det går, på Ubuntu fungerar i stort sett allt som finns till Linux och det på en gång.

Man lär sig mycket på att fixa problemen och hålla installationen levande istället för att installera om. Jag har nu bytt grafikkort från nvidia med proprietära drivrutiner till AMD med öppna drivrutiner. Visserligen har jag tänkt installera om men ville först testa utan ominstallation och det gick ju bra. Kanske väntar lite med att installera om, känns inte så akut egentligen.

En av fördelarna med Linux är att man inte behöver installera om systemet för att man bytt hårdvara.

*** tråd modererad ***

Jag har tagit bort ett onödigt inlägg som bröt mot forumets § 1.5.

/KimTjik

virtual void: Lär dig att redigera dina inlägg är du snäll.

De installationerna jag har haft att göra med har hållt sig ett par år, detta beror mest på att jag provar lite nya distributioner titt som tätt. Detta är nog väldigt individuellt från person till person. Svårt att dra alla över en kam.