Uppgradera gammal Ubuntu efter EOL

[anth]

Gör man ingenting med med en Ubuntu-installation kommer den förr eller senare nå End of Life (EOL).
LTS-versionerna, t.ex. 18.04 och 20.04, har support i 5 år.
De mellanliggande versionerna, t.ex. 18.10, 19.04, 19.10, har dock bara support i 9 månader.

Trots att jag är förhållandevis ny i Linux-världen har jag redan lyckats TVÅ gånger att passera 9-månaders gränsen på mina datorer.
Inte helt oväntat har det varit på gamla datorer som inte används så mycket och där jag mest var intresserad av att se om jag kunde installera Linux överhuvudtaget.

Vad som händer är att repositories slutar fungera. Och eftersom det är repositories man använder för att uppdatera datorn kan man liksom inte göra någonting.
Eftersom jag inte kunde Linux så bra då och det inte var några viktiga datorer, ominstallerade jag bara till en nyare version av Ubuntu.

Nu försöker jag faktiskt lära mig Linux/Ubuntu, så jag tänkte låta en Ubuntu 19.10 dator ligga till augusti då dess repos slutat fungera.
Hur gör jag sen?
Hur uppdaterar man en Ubuntu-installation som inte längre har fungerande repos?

Jag hittade följande lösning på nätet, men jag är allergisk mot Linux-tips som är äldre än 2 år (utvecklingen går lite för snabbt för att man ska våga lita på gamla artiklar).
Kort och gott, gäller nedanstående fortfarande?

$ sudo nano /etc/apt/sources.list

ändra

archive.ubuntu.com
security.ubuntu.com

till

old-releases.ubuntu.com

Spara och stäng ner med CTRL+X

Man kan göra samma sak med sed, men jag är för mycket nybörjare för att känna mig bekväm med sed:

$ sudo sed -i -re 's/([a-z]{2}\.)?archive.ubuntu.com|security.ubuntu.com/old-releases.ubuntu.com/g' /etc/apt/sources.list

Sedan ska man kunna uppgradera till senaste Ubuntu-versionen med:

$ sudo apt-get update
$ sudo apt-get dist-upgrade
$ sudo apt-get install ubuntu-release-upgrader-core
$ sudo do-release-upgrade

[serafim]

Det finns bra orsaker till att de speciella recepten inte finns på distributionernas hemsidor. Alla speciella recept på youtube eller annat brukar föra med sig vissa risker. De brukar oftast bara fungera för just författarens egen tweak av sitt system.

Jag har (nästan) alltid /home på en egen partition. Har jag mycket utrymme brukar /opt också få en egen partition. Om inte tar jag kopia på hela hemmamappen och inkluderar då alla dolda mappar.

Sedan noterar jag alla udda grejer, som t.ex. PPA. Sedan brukar jag nyinstallera. Under installationen väljer jag att göra min egen partitionering och låter /home och /opt vara utan att formatera dem.

[Osprey]

Håller med Serafim om att de där speciella recepten för att uppgradera en utgången version inte funkar något vidare. De brukar fungera till viss del och sedan hänger sig allting och man står där med ett halvfärdigt system som inte längre går att starta upp. Dessutom är det oftast helt olika tillvägagångssätt beroende på vad man ska uppgradera ifrån, vilket implicit även innebär vad man ska uppgradera till.

Istället för att försöka med det, så är det som sagt var mycket bättre att ha "/home" (och kanske "/opt") på separata partitioner, så att de inte berörs av en nyinstallation. För den delen så går det också att göra en nyinstallation utan att formatera, så tas åtminstone inte "/home" bort, men jag brukar alltid köra med formatering för att veta att allt är rent, men då har jag alltså "/home" på en egen partition och formaterar alltså inte den!

Sedan har jag lagt upp ett "baspaket" som består av ett litet script som installerar alla de program jag vill ha (med "apt"), förutom det som ingår som standard alltså.

Dessutom har jag sparat undan alla de ikoner, fonter, teman liknande som jag vill ha, så att jag snabbt och enkelt kan kopiera in dem på ett nytt system.

Sedan har jag också lite extra saker som jag laddat hem sparade så jag snabbt kan installera dem, typ drivrutiner för skrivare och sådant som inte går att installera direkt från förråden.

I detta "baspaket" har jag också en kopia på "/etc/fstab", "/etc/cryttab" och lite andra systeminställningar, så jag snabbt kan kopiera delar av det till ett nytt system.

Det tar ett litet tag att knåpa ihop ett sådant baspaket, men det är väl värt tiden. Som det är nu så gör jag lätt en nyinstallation och får med allt jag hade i det gamla systemet på ungefär 2-3 timmar. Då är det mesta dessutom väntetid som jag kan göra något annat på, eftersom den mesta tiden går åt för att datorn ska köra de script jag gjort...

Detta gör ju också att jag aldrig behöver göra någon backup på själva systemet, det räcker med "/home" och sedan skapar jag istället en exakt kopia av det gamla med de här scripten, om det skulle behövas....

[Gunnar Hjalmarsson]

Jag borde antagligen hålla tyst i den här tråden, då jag vare sig har erfarenhet av att uppgradera från en EOL-version eller av att lägga /home och eventuellt andra saker i särskilda partitioner. Med det sagt har jag ändå några kommentarer.

Det är förvisso hälsosamt att generellt vara skeptisk till råd man hittar slumpmässigt någonstans på nätet. Men i det här fallet förmodar jag att vad du hittade var det här:

https://askubuntu.com/questions/91815/h ... ed-release

Det accepterade svaret har hittills röstats upp av 579 användare (och röstats ned av en). Jag tror faktiskt att just det Ask Ubuntu-svaret är Svaret med stort S på hur man går tillväga om man vill uppgradera från en EOL-version. Jag känner i vart fall inte till någon mer auktoritativ vägledning i ämnet.

serafims och Opreys tips om att lägga t ex /home i en särskild partition är en alternativ approach till att hantera versionsuppgraderingar. Men det går väl knappast att göra i efterhand, utan är något man kan överväga när man gör en nyinstallation för att sedan underlätta för framtiden. Eller har jag missat något här?

[serafim]

...serafims och Opreys tips om att lägga t ex /home i en särskild partition är en alternativ approach till att hantera versionsuppgraderingar. Men det går väl knappast att göra i efterhand, utan är något man kan överväga när man gör en nyinstallation för att sedan underlätta för framtiden. Eller har jag missat något här?

Nej, du har inte missat något men det har uppenbarligen jag. Ett recept på AskUbuntu är väsentligt trovärdigare än de recept jag avsåg i min kommentar.
Dessutom är min totala strategi ganska lik Ospreys och därtill med backuper på mina servrar som kommer av min paranoia från ett långt arbetsliv inom undervisning och IT. Tappa aldrig något, ha alltid backup. Strategin med egen /home- och /opt-partition kommer från 90-talet, då linux var i sin linda och har hängt med sen dess. Det var en rekommendation på den tiden, egen /boot-, /-, /var-, /opt- och /home-partition men delar av det har jag slutat med.

[anth]

Det är förvisso hälsosamt att generellt vara skeptisk till råd man hittar slumpmässigt någonstans på nätet. Men i det här fallet förmodar jag att vad du hittade var det här:

https://askubuntu.com/questions/91815/h ... ed-release

Det accepterade svaret har hittills röstats upp av 579 användare (och röstats ned av en).

Jo, det kan ha varit den lösningen jag hittade - och svaret är 8 år gammalt. Åtta år bakåt i Linuxvärlden motsvarar ungefär att gå tillbaka till medeltiden.
Den länkade även till en Ubuntu-hjälpsida med instruktioner för att uppgradera från Oneiric 11.10 till Precise 12.02
Även om den fått 579 upvotes hjälper det inte mig om uppvotsen också är 8 år gamla.

Läser man hela tråden (show more) finns det faktiskt flera nyare svar från 2020. Bl.a. en uppdaterad sed:

sed -i 's|/archive.canonical|archive.canonical|g;s|http://.*/ubuntu|http://old-releases.ubuntu.com/ubuntu|g;s|archive.canonical|/archive.canonical|g' /etc/apt/sources.list

Om jag förstår rätt ska man redigera /etc/apt/sources.list
och ändra ALLA URL:er till:
http://old-releases.ubuntu.com/ubuntu

Vilket kan ses som ett förtydligande av mitt startinlägg.
(jag är värdelös på att använda sed så någon får rätta mig om jag har fel)

---

Det fanns även en länk till en nyare post:
https://askubuntu.com/questions/1208109 ... 99#1212699

Om jag förstår rätt så börjar de riktiga problemen om man försöker uppgradera två versioner på en gång. Kommandot:

$ sudo do-release-upgrade

uppgraderar en version, sedan får man hoppas det går bra för att sedan uppgradera en version till.

[anth]

Jag har (nästan) alltid /home på en egen partition. Har jag mycket utrymme brukar /opt också få en egen partition.

Sedan har jag lagt upp ett "baspaket" som består av ett litet script som installerar alla de program jag vill ha (med "apt"), förutom det som ingår som standard alltså.

Dessutom har jag sparat undan alla de ikoner, fonter, teman liknande som jag vill ha, så att jag snabbt och enkelt kan kopiera in dem på ett nytt system.

Sedan har jag också lite extra saker som jag laddat hem sparade så jag snabbt kan installera dem, typ drivrutiner för skrivare och sådant som inte går att installera direkt från förråden.

I detta "baspaket" har jag också en kopia på "/etc/fstab", "/etc/cryttab" och lite andra systeminställningar, så jag snabbt kan kopiera delar av det till ett nytt system.

Det tar ett litet tag att knåpa ihop ett sådant baspaket, men det är väl värt tiden. Som det är nu så gör jag lätt en nyinstallation och får med allt jag hade i det gamla systemet på ungefär 2-3 timmar. Då är det mesta dessutom väntetid som jag kan göra något annat på, eftersom den mesta tiden går åt för att datorn ska köra de script jag gjort...

När jag började med Linux var jag så glad att de flesta instruktioner sa att man numera inte behövde flera partitioner längre.
Jag har inga som helst problem att göra flera partitioner, det är mest att jag har superdålig koll på hur stora jag ska göra dem - det är enklare att bara göra en enda stor partition.

Men jag tycker om era argument för att /home och /opt ska ha egna partitioner och ska anamma det.

Jag tycker också om Ospreys idé med ett installationsskript.
Det påminner lite om sajten https://ninite.com/ som man använder till Windows.
Tyvärr är jag fortfarande för dålig på skript så det får vänta ett par månader - jag klarar av att läsa skript, men ber ni mig skriva ett blir det stopp.
Däremot har varje Linux-system jag sätter upp en textfil med vad som är installerat, så jag kan återställa systemet manuellt.

[Gunnar Hjalmarsson]

Ett recept på AskUbuntu är väsentligt trovärdigare än de recept jag avsåg i min kommentar.

Jo. Även om det finns många skräpsvar på Ask Ubuntu också. Men inte i det här fallet, tror jag.

Dessutom är min totala strategi ganska lik Ospreys och därtill med backuper på mina servrar som kommer av min paranoia från ett långt arbetsliv inom undervisning och IT. Tappa aldrig något, ha alltid backup. Strategin med egen /home- och /opt-partition kommer från 90-talet, då linux var i sin linda och har hängt med sen dess. Det var en rekommendation på den tiden, egen /boot-, /-, /var-, /opt- och /home-partition men delar av det har jag slutat med.

Jag, som inte var med på den tiden, har vant mig vid att ha allt i samma partition. Normala versionsuppgraderingar (inte från EOL då) har alltid funkat bra för mig.

Dessutom har jag lärt mig att det inte är särskilt klokt att behålla /home intakt version efter version. Det kan samlas mycket skräp i olika ~/.cache-kataloger t ex som kan leda till subtila buggar. Så jag har funnit det vara motiverat att då och då "städa" /home genom att helt enkelt spara undan, nyinstallera, och sedan plocka dit bara sådant jag vet att jag vill ha kvar.

svaret är 8 år gammalt. Åtta år bakåt i Linuxvärlden motsvarar ungefär att gå tillbaka till medeltiden.

Ibland, men inte alltid. Tror du behöver nyansera dina kriterier för att värdera information. I fråga om EOL-versioner har Ubuntu tillämpat metoden att putta undan dem till ett särskilt förråd under lång tid.

Om jag förstår rätt ska man redigera /etc/apt/sources.list
och ändra ALLA URL:er till:
http://old-releases.ubuntu.com/ubuntu

Nja, inte alla. Det gäller t ex inte PPAn och andra externa förråd. De bör man å andra sidan kommentera inför en versionsuppgradering i alla händelser.

Om jag förstår rätt så börjar de riktiga problemen om man försöker uppgradera två versioner på en gång. Kommandot:

$ sudo do-release-upgrade

uppgraderar en version, sedan får man hoppas det går bra för att sedan uppgradera en version till.

Nu är du inne på ett annat ämne. Hoppa över versioner skall man i princip aldrig göra, oavsett om man startar från en EOL-version eller från en version som fortfarande stöds. Gör man det ändå, får man så att säga skylla sig själv. Undantaget är att det går bra att uppgradera från en LTS till nästa LTS, t ex 18.04 -> 20.04.

[serafim]

Dessutom har jag lärt mig att det inte är särskilt klokt att behålla /home intakt version efter version. Det kan samlas mycket skräp i olika ~/.cache-kataloger t ex som kan leda till subtila buggar. Så jag har funnit det vara motiverat att då och då "städa" /home genom att helt enkelt spara undan, nyinstallera, och sedan plocka dit bara sådant jag vet att jag vill ha kvar.

Ja, jag städar ganska regelbundet genom ett skript som städar bort allt dolt utom enstaka saker som t.ex. .mozilla, .thunderbird, + några till.
Jag har ju varit tvungen p.g.a. en del uppdrag att byta dist några gånger på min arbetsstation och det har ställt till både .cache och .config några gånger. Min arbetsstation är nu, efter pensionen, många gånger mer kraftfull än jag har behov av så /home och /opt delar en egen hårddisk.

[Osprey]

Dessutom har jag lärt mig att det inte är särskilt klokt att behålla /home intakt version efter version. Det kan samlas mycket skräp i olika ~/.cache-kataloger t ex som kan leda till subtila buggar. Så jag har funnit det vara motiverat att då och då "städa" /home genom att helt enkelt spara undan, nyinstallera, och sedan plocka dit bara sådant jag vet att jag vill ha kvar.

Givetvis kan det vara bra att städa och skapa ett nytt /home vid varje release (eller något sådant). Men det hänger helt på hur mycket jobb det blir och hur många timmar det skulle ta. Själv har jag massor av script, program, dokument och allt möjligt annat som ligger där och det skulle vara alldeles för mycket jobb...

Det man möjligtvis skulle kunna göra är att rensa ".config", ".local" och ".mozilla". De innehåller inställningar och definitioner för program, som inte nödvändigtvis är gångbara i sin helhet i den nya versionen.

Det vill säga när man uppgraderar till en ny release av operativsystemet, så får man också ofta en ny version av alla möjliga program som man har installerade. Denna version kan ha utvecklats så att en del av de inställningar och definitioner man använde tidigare, inte längre finns kvar. Nu är det som tur är så i Linux och Unix att om de hittar något som de inte förstår sig på, så ignorerar de bara detta istället för att sparka bakut och krasha (på samma sätt som t.ex HTML).

Nackdelen med att ta bort ".config" och ".local" är att man måste göra om alla inställningar man hade innan, så jag låter bli att göra det så länge allt funkar. När det gäller ".mozilla" så påverkar detta Firefox och Thunderbird om man använder dem och där är det ofta en hel del man vill ha kvar. Bokmärken kan man iofs. spara som html och läsa in i den nya versionen, men allt annat försvinner.

svaret är 8 år gammalt. Åtta år bakåt i Linuxvärlden motsvarar ungefär att gå tillbaka till medeltiden.

Ibland, men inte alltid. Tror du behöver nyansera dina kriterier för att värdera information. I fråga om EOL-versioner har Ubuntu tillämpat metoden att putta undan dem till ett särskilt förråd under lång tid.

Saken är också den att sättet att uppgradera från en version av Linux till nästa, förändras också över tiden om ska göra det manuellt. Det sker en utveckling även där och den metod som funkade från "Raring Ringtail" till "Saucy Salamander", funkar inte nödvändigtvis för "Cosmic Cuttlefish" till "Disco Dingo"...

Dessutom tar det oändligt mycket längre tid att stega upp ett antal releaser, jämfört med att nyinstallera och fixa till lite runt det...

Om jag förstår rätt ska man redigera /etc/apt/sources.list
och ändra ALLA URL:er till:
http://old-releases.ubuntu.com/ubuntu

Nja, inte alla. Det gäller t ex inte PPAn och andra externa förråd. De bör man å andra sidan kommentera inför en versionsuppgradering i alla händelser.

Håller med Gunnar och det är en ganska komplex historia totalt sett. Att gå in och "skruva i det själv" är ungefär som att renovera en automatväxellåda med skiftnyckel och hammare, det vill säga stor risk att det blir fel...

Om jag förstår rätt så börjar de riktiga problemen om man försöker uppgradera två versioner på en gång. Kommandot:

$ sudo do-release-upgrade

uppgraderar en version, sedan får man hoppas det går bra för att sedan uppgradera en version till.

Nu är du inne på ett annat ämne. Hoppa över versioner skall man i princip aldrig göra, oavsett om man startar från en EOL-version eller från en version som fortfarande stöds. Gör man det ändå, får man så att säga skylla sig själv. Undantaget är att det går bra att uppgradera från en LTS till nästa LTS, t ex 18.04 -> 20.04.

Håller med Gunnar igen, hoppa inte över versioner för det finns aldrig någon garanti för att en ny version helt till 100% täcker upp allt som fanns i den föregående och hoppar man då över den föregående, så får man ett hopp där man riskerar att tappa bort något, ofta något som är en förutsättning för att uppgraderingen ska lyckas...

[Osprey]

Jag tycker också om Ospreys idé med ett installationsskript.
Det påminner lite om sajten https://ninite.com/ som man använder till Windows.
Tyvärr är jag fortfarande för dålig på skript så det får vänta ett par månader - jag klarar av att läsa skript, men ber ni mig skriva ett blir det stopp.
Däremot har varje Linux-system jag sätter upp en textfil med vad som är installerat, så jag kan återställa systemet manuellt.

Du kan få kopior på de script jag skrivit och info om hur jag lagt upp hela "baspaketet" om du vill.

Och....

Det påminner lite om sajten https://ninite.com/ som man använder till Windows.

Ja mycket är ungefär samma i Linux och Windows, skillnaden är bara att det är mycket bättre och vackrare i Linux....

[Gunnar Hjalmarsson]

svaret är 8 år gammalt. Åtta år bakåt i Linuxvärlden motsvarar ungefär att gå tillbaka till medeltiden.

Ibland, men inte alltid. Tror du behöver nyansera dina kriterier för att värdera information. I fråga om EOL-versioner har Ubuntu tillämpat metoden att putta undan dem till ett särskilt förråd under lång tid.

Saken är också den att sättet att uppgradera från en version av Linux till nästa, förändras också över tiden om ska göra det manuellt. Det sker en utveckling även där och den metod som funkade från "Raring Ringtail" till "Saucy Salamander", funkar inte nödvändigtvis för "Cosmic Cuttlefish" till "Disco Dingo"...

Så är det förstås. Men sådana metodförändringar tar sig rimligen uttryck i att kommandot do-release-upgrade inte gör exakt samma saker i cosmic som i raring.

Som jag uppfattar utgångspunkten i den här tråden handlar det om de extra åtgärder man behöver vidta när man väntar med versionsuppgradering tills den installerade versionen blir EOL. Något som anth planerar att testa som ett experiment.

Och på den punkten har såvitt jag vet inget särskilt hänt.

Dessutom tar det oändligt mycket längre tid att stega upp ett antal releaser, jämfört med att nyinstallera och fixa till lite runt det...

Ja, absolut. Men det är en diskussion om vad som är det förnuftigaste sättet att förfara, vilket är utanför ämnet. Det är aldrig förnuftigt att låta sin installerade version passera EOL.

[Osprey]

svaret är 8 år gammalt. Åtta år bakåt i Linuxvärlden motsvarar ungefär att gå tillbaka till medeltiden.

Ibland, men inte alltid. Tror du behöver nyansera dina kriterier för att värdera information. I fråga om EOL-versioner har Ubuntu tillämpat metoden att putta undan dem till ett särskilt förråd under lång tid.

Saken är också den att sättet att uppgradera från en version av Linux till nästa, förändras också över tiden om ska göra det manuellt. Det sker en utveckling även där och den metod som funkade från "Raring Ringtail" till "Saucy Salamander", funkar inte nödvändigtvis för "Cosmic Cuttlefish" till "Disco Dingo"...

Så är det förstås. Men sådana metodförändringar tar sig rimligen uttryck i att kommandot do-release-upgrade inte gör exakt samma saker i cosmic som i raring.

Som jag uppfattar utgångspunkten i den här tråden handlar det om de extra åtgärder man behöver vidta när man väntar med versionsuppgradering tills den installerade versionen blir EOL. Något som anth planerar att testa som ett experiment.

Och på den punkten har såvitt jag vet inget särskilt hänt.

Även "do-release-upgrade" utvecklas givetvis, men nu tänkte jag på det med att gå in och skruva själv i "/etc/apt/sources.list" eller något sådant...

[Gunnar Hjalmarsson]

Även "do-release-upgrade" utvecklas givetvis, men nu tänkte jag på det med att gå in och skruva själv i "/etc/apt/sources.list" eller något sådant...

Ok. Och "skruva" i /etc/apt/sources.list är precis vad man behöver göra inför en uppgradering från en installation som har passerat EOL. Och på den punkten har vad jag vet (rätta mig gärna om jag har fel) inget hänt i modern tid. Vilket betyder att det något mogna Ask Ubuntu-svaret torde vara lika giltigt idag som när det skrevs.

[serafim]

Även "do-release-upgrade" utvecklas givetvis, men nu tänkte jag på det med att gå in och skruva själv i "/etc/apt/sources.list" eller något sådant...

Ok. Och "skruva" i /etc/apt/sources.list är precis vad man behöver göra inför en uppgradering från en installation som har passerat EOL. Och på den punkten har vad jag vet (rätta mig gärna om jag har fel) inget hänt i modern tid. Vilket betyder att det något mogna Ask Ubuntu-svaret torde vara lika giltigt idag som när det skrevs.

Det enda som hänt är att uppgraderingskommandona och pakethanterarna har blivit mer sofistikerade med åren men officiellt har man tydligen fortfarande åsikten att för mycket kan ha hänt mellan en versions EOL-tidpunkt och en annan versions tillkomst för att en uppgradering skall kunna anses vara säker. Det fungerar säkert i de flesta fall men jag vågar inte chansa. Det skulle kunna bli mycket "efterpillande" och förr, då datorer var mitt jobb, hade jag oftast inte tid med pillandet. Och sedan dess sitter det fortfarande i ryggmärgen.
Däremot skulle jag kunna tänka mig ett kommando som uppgraderar stegvis från versionen som nått EOL, via alla versioner emellan den och den version man vill nå. Men det kan ju ta rejält med tid.

[Osprey]

Däremot skulle jag kunna tänka mig ett kommando som uppgraderar stegvis från versionen som nått EOL, via alla versioner emellan den och den version man vill nå. Men det kan ju ta rejält med tid.

Har liksom du en bakgrund från datadrift och infrastruktur och är väl förtrogen med den problematik som kan uppstå.

Men ett kommando som uppgraderar stegvis ser jag som omöjligt, då det inte kan ha någon heltäckande historia att utgå ifrån. Allt för mycket med självinstallerade program och egna anpassningar kan ha skett. Dessutom så kan det ena bygga på det andra och "a" bygger på att "b" redan skett.

Så själv anser jag att sådana uppgraderingar är helt omöjliga, eller åtminstone ger dåligt resultat. Det är därför jag som gammal System Manager (från OpenVMS) och Sysadmin (root) från Unix/Linux skapat ett "baspaket" istället, det är lite jobb att göra, men man sparar så mycket tid i slutändan ändå.....

[serafim]

Däremot skulle jag kunna tänka mig ett kommando som uppgraderar stegvis från versionen som nått EOL, via alla versioner emellan den och den version man vill nå. Men det kan ju ta rejält med tid.

Har liksom du en bakgrund från datadrift och infrastruktur och är väl förtrogen med den problematik som kan uppstå.

Men ett kommando som uppgraderar stegvis ser jag som omöjligt, då det inte kan ha någon heltäckande historia att utgå ifrån. Allt för mycket med självinstallerade program och egna anpassningar kan ha skett. Dessutom så kan det ena bygga på det andra och "a" bygger på att "b" redan skett.

Så själv anser jag att sådana uppgraderingar är helt omöjliga, eller åtminstone ger dåligt resultat. Det är därför jag som gammal System Manager (från OpenVMS) och Sysadmin (root) från Unix/Linux skapat ett "baspaket" istället, det är lite jobb att göra, men man sparar så mycket tid i slutändan ändå.....

Vi (jag och ett par kollegor) gjorde ett jobb för länge sedan med program som analyserade programförändringar, inklusive bibliotek (lib...), skapade uppgraderingsstrategier utifrån aktuell konfiguration men analysen tog flera timmar och uppgraderingen ännu längre tid så vi lade ner projektet eftersom servrar mm inte kunde vara offline den tid det tog. Så jag är medveten om att det är en dröm. Men drömmar har en tendens att hålla sig kvar.

[Osprey]

Vi (jag och ett par kollegor) gjorde ett jobb för länge sedan med program som analyserade programförändringar, inklusive bibliotek (lib...), skapade uppgraderingsstrategier utifrån aktuell konfiguration men analysen tog flera timmar och uppgraderingen ännu längre tid så vi lade ner projektet eftersom servrar mm inte kunde vara offline den tid det tog. Så jag är medveten om att det är en dröm. Men drömmar har en tendens att hålla sig kvar.

En del av det där får man på köpet genom "apt" och liknande uppgraderingsverktyg, med deras "kunskap" om beroenden och sådant. Detta gör ju att om man ska installera typ 10 program, så blir själva installationsprocessen helt olika beroende på i vilken ordning man installerar dem, även om slutresultatet blir detsamma...

Jag kommer ihåg hur det var innan de verktygen fanns och man fick packa upp en tar-fil, anpassa make-filen och köra ett antal gånger med olika sidoinstallationer av beroenden mellan, tills den slutade gnälla över att något saknades. Det var tider det, men herrejösses vad mycket tid man sparar med de verktyg som finns nu...

En sak som dock är lite synd med "apt" och "dpkg" är att man kan se vad som är installerat, men man kan inte se när det installerades eller om det har uppgraderats. Det finns iofs i loggarna, men då ska man sammanställa info därifrån också och loggar rensas ibland bort...

Ett program som analyserar programförändringar låter väldigt intressant, men det blir ju en väldigt komplex och komplicerad sak. Så jag kan tänka mig att det tog ett bra tag att köra det. Dessutom är det ju otroligt stor risk att någon "liten obetydlig detalj" gör att allt hänger sig eller kraschar...

Så i det sammanhanget med servrar så är det betydligt enklare och smidigare med en Raid-array...