Något gick sönder efter uppdateringen: "efter" och "på grund av" är inte samma sak
En omstart är det första ärliga provet på allt som gjorts sedan förra omstarten. En del av det som går sönder kom inte med uppdateringen, det fanns redan där och hade aldrig prövats.
AtlasPVE ·
Den här artikeln svarar på
- proxmox startar inte efter uppdatering
- proxmox starta med föregående kärna
- proxmox ångra uppdatering
- proxmox pveproxy startar inte
- proxmox ingen panel efter uppdatering
Du uppdaterade, startade om, något fungerar inte. Första reflexen är "uppdateringen förstörde det", och ibland stämmer det. Men först måste en åtskillnad göras, för den ändrar arbetet från början.
"Efter" och "på grund av"
En omstart är det första ärliga provet på allt som gjorts sedan förra omstarten. En tjänst som startats för hand och aldrig lagts till i uppstarten, en montering som aldrig skrevs in i konfigurationen, en inställning som ändrats i drift och aldrig sparats till fil: allt detta har funnits i månader och inget av det hade prövats fram till det ögonblicket. Omstarten avslöjar det, den orsakar det inte.
Att veta det lönar sig, för "ångra uppdateringen" löser inte den sortens problem, och just därför skickar det iväg dig åt fel håll i timmar.
Först symtomet, sedan beslutet
Den verkliga frågan är inte "hur tar jag mig tillbaka", utan vad exakt är sönder. Det finns tre symtomfamiljer och de pekar åt tre olika håll.
Maskinen kommer inte upp alls. Saken gäller kärnan eller uppstartslagret. Vägen tillbaka är den föregående kärnan, och den finns oftast kvar, för uppdateringar raderar inte gamla kärnor.
Maskinen kommer upp men panelen saknas. En tjänst startade inte. Titta på vilken och varför; det här är nästan alltid en enskild konfigurationsfråga och inte hela uppdateringen.
Allt kommer upp men något beter sig annorlunda. En komponent har verkligen ändrats. Här är instinkten att gå tillbaka som mest fel: det rätta arbetet är att läsa vad som ändrats.
Att gå tillbaka är inte gratis
Att spola tillbaka rotfilsystemet ångrar inte bara uppdateringen, det ångrar allt sedan det ögonblicket. Inställningar som ändrats under tiden, tillagda åtkomstnycklar, annat som installerats, allt går tillbaka. Att gå tillbaka är ett beslut, inte en knapp.
En stege som börjar med det billigaste
Pröva det smalaste först, och fungerar det, rör inget mer:
Starta med den föregående kärnan. Det rör bara kärnan och lämnar resten som det är.
Sätt tillbaka ett enda paket till dess tidigare version. Verkan stannar vid det paketet.
Spola tillbaka systemtillståndet som helhet. Det kraftfullaste och dyraste, sparat till sist.
Skriv ner innan du lagar
Anteckna vad du såg: felraden, vilken tjänst, vilken tid. Den dag det fungerar igen försvinner orsaken, och händer samma sak tre månader senare har du ingenting kvar i handen.
Vad Atlas gör
Atlas fäster den körande kärnan före uppdateringen. Även om en ny kärna installeras tar omstarten dig alltså upp på den gamla; att gå över till den nya är ett eget och medvetet steg. När du går över till den nya kärnan tar uppstartsvakten vid: den kontrollerar att systemet verkligen kom upp friskt och faller av sig själv tillbaka till den gamla kärnan om det inte gjorde det.
Före uppdateringen tas en ögonblicksbild av rotfilsystemet. På ZFS är det billigt och att gå tillbaka tar minuter; på system utan ZFS sparas pakettillståndet separat, alltså inte hela systemet men installationstillståndet går att ångra. De fem senaste ögonblicksbilderna före uppdateringar behålls, äldre städas bort.
När installationen är klar körs ännu en kontroll: är de kritiska tjänsterna uppe, hålls klusterförståelsen fortfarande. Frågan "gick något sönder" ställs alltså innan du märker det.
⚠️ Varningen ovan gäller ändå: att spola tillbaka rotfilsystemet som helhet ångrar mer än uppdateringen. Atlas håller ögonblicksbilden redo, men beslutet att gå tillbaka är ditt.
Källor
Proxmox egen dokumentation. På engelska, och den har sista ordet i den här frågan.