Noe gikk i stykker etter oppdateringen: "etter" og "på grunn av" er ikke det samme
En omstart er den første ærlige prøven på alt som er gjort siden forrige omstart. En del av det som ryker kom ikke med oppdateringen, det lå der allerede og hadde aldri blitt prøvd.
AtlasPVE ·
Denne artikkelen svarer på
- proxmox starter ikke etter oppdatering
- proxmox starte med forrige kjerne
- proxmox angre oppdatering
- proxmox pveproxy starter ikke
- proxmox ingen panel etter oppdatering
Du oppdaterte, startet på nytt, noe virker ikke. Den første refleksen er "oppdateringen ødela det", og noen ganger stemmer det. Men først må det gjøres et skille, for det endrer arbeidet fra starten.
"Etter" og "på grunn av"
En omstart er den første ærlige prøven på alt som er gjort siden forrige omstart. En tjeneste startet for hånd og aldri lagt til i oppstarten, en montering som aldri ble skrevet inn i oppsettet, en innstilling endret i drift og aldri lagret til fil: alt dette har ligget der i månedsvis, og ingenting av det var prøvd fram til det øyeblikket. Omstarten bringer det fram, den forårsaker det ikke.
Å vite dette lønner seg, for "angre oppdateringen" løser ikke den typen problem, og nettopp derfor sender det deg i feil retning i timevis.
Først symptomet, så avgjørelsen
Det egentlige spørsmålet er ikke "hvordan kommer jeg tilbake", men hva er nøyaktig i stykker. Det finnes tre symptomfamilier, og de peker i tre ulike retninger.
Maskinen kommer ikke opp i det hele tatt. Saken gjelder kjernen eller oppstartslaget. Veien tilbake er den forrige kjernen, og den ligger som regel der ennå, for oppdateringer sletter ikke gamle kjerner.
Maskinen kommer opp, men panelet mangler. En tjeneste startet ikke. Se på hvilken og hvorfor; dette er nesten alltid en enkelt oppsettssak og ikke hele oppdateringen.
Alt kommer opp, men noe oppfører seg annerledes. En komponent har virkelig endret seg. Her er instinktet om å gå tilbake mest feil: det riktige arbeidet er å lese hva som er endret.
Å gå tilbake er ikke gratis
Å spole tilbake rotfilsystemet angrer ikke bare oppdateringen, det angrer alt siden det øyeblikket. Innstillinger endret i mellomtiden, tilføyde tilgangsnøkler, annet som er installert, alt går tilbake. Å gå tilbake er en avgjørelse, ikke en knapp.
En stige som begynner med det billigste
Prøv det smaleste først, og virker det, rør ikke mer:
Start med den forrige kjernen. Det rører bare kjernen og lar resten være som det er.
Sett ett enkelt pakke tilbake til den forrige versjonen. Virkningen blir værende i den pakken.
Spol systemtilstanden tilbake som helhet. Det kraftigste og dyreste, spart til sist.
Skriv ned før du reparerer
Noter hva du så: feillinjen, hvilken tjeneste, hvilket klokkeslett. Den dagen det virker igjen forsvinner grunnen, og skjer det samme tre måneder senere, har du ingenting igjen i hånden.
Hva Atlas gjør
Atlas fester den kjørende kjernen før oppdateringen. Selv om en ny kjerne installeres, tar omstarten deg altså opp på den gamle; å gå over til den nye er et eget og bevisst steg. Når du går over til den nye kjernen, tar oppstartsvakten over: den bekrefter at systemet virkelig kom opp friskt, og faller av seg selv tilbake til den gamle kjernen hvis det ikke gjorde det.
Før oppdateringen tas et øyeblikksbilde av rotfilsystemet. På ZFS er det billig, og å gå tilbake tar minutter; på systemer uten ZFS lagres pakketilstanden for seg, altså ikke hele systemet, men installasjonstilstanden kan angres. De fem siste øyeblikksbildene før oppdateringer beholdes, eldre ryddes bort.
Etter at installasjonen er ferdig, kjøres enda en kontroll: er de kritiske tjenestene oppe, holdes klyngeenigheten fortsatt. Spørsmålet "gikk noe i stykker" stilles altså før du merker det.
⚠️ Advarselen over gjelder likevel: å spole rotfilsystemet tilbake som helhet angrer mer enn oppdateringen. Atlas holder øyeblikksbildet klart, men avgjørelsen om å gå tilbake er din.
Kilder
Proxmox sin egen dokumentasjon. På engelsk, og den har siste ord i denne saken.