Kerneopdateringer: hvorfor den farligste opdatering er den mest stille
Kernen installeres, der sker ingenting, alt ser normalt ud. Faren kommer ved næste start, og den start kan ligge uger ude i fremtiden. Mellem årsag og virkning lægger der sig uger.
AtlasPVE ·
Denne artikel besvarer
- proxmox kerneopdatering
- proxmox ny kerne starter ikke
- proxmox låse kernen
- proxmox kom ikke tilbage efter genstart
- proxmox starte med gammel kerne
En kerneopdatering installeres, installationen slutter uden besvær, og intet ser ændret ud. Systemet kører stadig på den gamle kerne, for en ny kerne træder først i kraft ved en genstart.
Og netop der gemmer faren sig.
Mellem årsag og virkning lægger der sig uger
De fleste pakkefejl viser sig, mens du kigger. En tjeneste falder, den melder fejl, du bemærker det samme dag.
Kernen er ikke sådan. Problemet dukker op ved næste start, og den start er måske ingen planlagt vedligeholdelsesnat. Strømmen går, maskinen genstarter sig selv, og den kommer ikke tilbage.
I det øjeblik forbinder ingen det med "opdateringen, jeg lavede sidste måned". Det, du har, er en uforklaret fejl, der slet ikke ligner et opdateringsproblem.
Det almene princip: det nye bør ikke være standardvalget, før det har bevist sig
Dette er den overførbare lære i artiklen, og den gælder ikke kun kerner.
En ny kerne må installeres, men det vedvarende standardvalg bør forblive den gamle kerne. Det nye bør kun prøves som "prøv dette én gang ved næste start".
Sat op sådan ændrer fejlens form sig: hænger maskinen, vender den af sig selv tilbage til den gamle ved næste start. For et engangsvalg gælder per definition én gang.
Det, du vinder, er dette: fejlens navn bliver "der skete ingenting", ikke "maskinen er væk".
Det andet lag: det installerede bør ikke stille blive standard
I det øjeblik en kerne er installeret, siger de fleste systemer "fra nu af starter jeg med den nyeste". Vil du ikke det, skal du låse den kørende kerne før opdateringen.
Låsningen forhindrer ikke den nye kerne, den forhindrer den kun i at blive standard af sig selv. Når du vil prøve den, vælger du.
Det tredje lag: hvem bemærker hængningen
For at en tilbagefaldsmekanisme kan virke, skal noget sige "denne maskine kom ikke op". Findes der en vagt på hardwareniveau, gør den det og genstarter maskinen.
Findes den ikke, kræver tilbagefaldet en manuel nulstilling. Det gør ikke mekanismen ubrugelig, men det bør være kendt: sætningen "den falder automatisk tilbage" er uden vagt kun halvt sand.
Reglen, der gælder selv uden produkt
Genstart bevidst og snart efter en kerneopdatering. Mens du kigger.
En genstart, du selv har planlagt, er en prøve. En genstart, der tvinges frem af et strømsvigt tre uger senere, er en hændelse. Den eneste forskel er, om du var til stede i øjeblikket.
Hvad Atlas gør
Når Atlas udfører en opdatering, låser det som standard den kørende kerne, så den netop installerede kerne ikke af sig selv bliver startens standardvalg. Den adfærd er ikke påbudt: den tilbydes som et valg, der kan slås fra i fladen. Produktet beslutter ikke her, det gør den sikre side til standard.
Også mekanismen for bekræftet overgang er bygget på princippet ovenfor: det vedvarende standardvalg er altid den gamle kerne, den nye prøves kun med én engangsstart, og hænger den, falder systemet tilbage af sig selv. Startforvalterens type opdages under kørsel, for den er forskellig fra maskine til maskine.
Og to ærlige grænser:
Denne mekanisme kører som standard i ren observationstilstand. Den siger altså, hvad den ville gøre, men rører ikke ved startopsætningen. At gribe ind i virkeligheden er et særskilt valg.
Findes der ingen hardwarevagt, går mekanismen ikke uden om det i tavshed: den slår sig pænt fra og siger, at en manuel nulstilling kan blive nødvendig. At foregive en garanti, der ikke findes, er værre end slet ikke at give nogen.
Kilder
Proxmox’ egen dokumentation. På engelsk, og den har det sidste ord i dette spørgsmål.