Kernelfrissítések: miért a legcsendesebb frissítés a legveszélyesebb
A kernel települ, nem történik semmi, minden normálisnak látszik. A veszély a következő indításkor érkezik, és az az indítás hetekre lehet. Ok és okozat közé hetek kerülnek.
AtlasPVE ·
A bejegyzés ezekre válaszol
- proxmox kernel frissítés
- proxmox új kernel nem indul
- proxmox kernel rögzítés
- proxmox újraindítás után nem jön vissza
- proxmox indítás régi kernellel
A kernelfrissítés települ, a telepítés gond nélkül lefut, és semmi nem látszik másnak. A rendszer továbbra is a régi kernellel fut, mert az új kernel csak újraindításkor lép érvénybe.
Pontosan itt rejtőzik a veszély.
Ok és okozat közé hetek kerülnek
A csomaghibák nagy része akkor jelentkezik, amikor még figyel rá valaki. Egy szolgáltatás elszáll, hibát ír, és még aznap kiderül.
A kernel nem ilyen. A hiba a következő indításkor jelenik meg, és az az indítás nem feltétlenül egy tervezett karbantartási éjszaka. Elmegy az áram, a gép magától újraindul, és nem jön vissza.
Abban a pillanatban senki nem köti össze a "múlt havi frissítéssel". Ami marad, az egy megmagyarázhatatlan hiba, ami egyáltalán nem néz ki frissítési problémának.
Az általános elv: ami új, addig ne legyen alapértelmezett, amíg nem bizonyított
Ez a cikk átvihető tanulsága, és nem csak a kernelekre igaz.
Új kernel telepíthető, de a tartós alapértelmezés maradjon a régi kernel. Az újat csak egyszeri választásként érdemes kipróbálni: "a következő indításnál egyszer ez fusson".
Így beállítva a hiba alakja megváltozik: ha a gép megáll, a következő indításnál magától visszatér a régihez. Egy egyszeri választás ugyanis a definíció szerint egyszer érvényes.
A nyereség ez: a hiba neve "nem történt semmi" lesz, nem pedig "a gép odavan".
A második réteg: ami települ, ne váljon csendben alapértelmezetté
Amint egy kernel települ, a legtöbb rendszer azt mondja: "mostantól a legújabbal indulok". Ha ez nem kívánatos, akkor frissítés előtt rögzíteni kell a futó kernelt.
A rögzítés nem tiltja le az új kernelt, csak azt akadályozza meg, hogy magától váljon alapértelmezetté. A kipróbálás továbbra is szabad választás kérdése.
A harmadik réteg: ki veszi észre a megállást
Ahhoz, hogy a visszaesési mechanizmus működjön, valaminek ki kell mondania: "ez a gép nem jött fel". Ha van watchdog hardveres szinten, ezt megteszi, és újraindítja a gépet.
Ha nincs, a visszaeséshez kézi újraindítás kell. Ettől a mechanizmus még nem haszontalan, de tudni kell róla: az "automatikusan visszaáll" mondat watchdog nélkül csak félig igaz.
A szabály, ami termék nélkül is érvényes
Kernelfrissítés után szándékosan és hamar kell újraindítani. Amíg még van, aki figyeli.
A magunk által ütemezett újraindítás teszt. Az az újraindítás, amit három héttel később egy áramszünet kényszerít ki, incidens. A kettő között csak annyi a különbség, hogy volt-e ott valaki abban a pillanatban.
Mit csinál az Atlas
Amikor az Atlas frissítést hajt végre, alapértelmezetten rögzíti a futó kernelt, így az újonnan telepített kernel nem válik magától indítási alapértelmezéssé. Ez a viselkedés nem kötelező: a felületen kikapcsolható lehetőségként jelenik meg. A termék itt nem dönt, csak a biztonságos oldalt teszi alapértelmezetté.
Az ellenőrzött átállás mechanizmusa is a fenti elvre épül: a tartós alapértelmezés mindig a régi kernel, az újat csak egyetlen következő indítás próbálja ki, és ha megáll, a rendszer magától visszaesik. A rendszerbetöltő típusát futásidőben állapítja meg, mert gépenként eltér.
És két őszinte korlát:
Ez a mechanizmus alapértelmezetten csak megfigyelő módban fut. Vagyis megmondja, mit tenne, de nem nyúl az indítási beállításokhoz. A tényleges beavatkozás külön döntés.
Ha nincs hardveres watchdog, a mechanizmus ezt nem hallgatja el: szabályosan kikapcsolja magát, és jelzi, hogy kézi újraindításra lehet szükség. Nem létező garanciát mutatni rosszabb, mint semmilyen garanciát nem adni.
Források
A Proxmox saját dokumentációja. Angol nyelvű, és ebben a kérdésben az övé az utolsó szó.