Aktualizacje jądra: dlaczego najgroźniejsza aktualizacja jest najcichsza
Jądro się instaluje, nic się nie dzieje, wszystko wygląda normalnie. Niebezpieczeństwo przychodzi przy następnym rozruchu, a ten rozruch może być za kilka tygodni. Między przyczyną a skutkiem wchodzą tygodnie.
AtlasPVE ·
Ten wpis odpowiada na
- proxmox aktualizacja jądra
- proxmox nowe jądro nie startuje
- proxmox przypięcie jądra
- proxmox nie wrócił po restarcie
- proxmox uruchomić stare jądro
Aktualizacja jądra się instaluje, instalacja kończy się bez kłopotu i nic nie wygląda na zmienione. System nadal pracuje na starym jądrze, bo nowe jądro wchodzi w życie dopiero przy restarcie.
I dokładnie tam kryje się niebezpieczeństwo.
Między przyczyną a skutkiem wchodzą tygodnie
Większość awarii pakietów ujawnia się, gdy patrzysz. Usługa pada, zgłasza błąd, zauważasz tego samego dnia.
Z jądrem tak nie jest. Problem pojawia się przy następnym rozruchu, a ten rozruch może nie być zaplanowaną nocą serwisową. Znika zasilanie, maszyna sama się restartuje i nie wraca.
W tamtej chwili nikt nie łączy tego z aktualizacją zrobioną miesiąc wcześniej. Zostaje ci niewyjaśniona awaria, która w ogóle nie wygląda na problem z aktualizacją.
Zasada ogólna: nowe nie powinno być domyślne, dopóki się nie sprawdzi
To jest przenośna lekcja tego wpisu i nie dotyczy wyłącznie jąder.
Nowe jądro można zainstalować, ale trwałym ustawieniem domyślnym powinno zostać stare jądro. Nowe powinno być wypróbowane tylko jako wybór na jeden następny rozruch.
Ustawione tak zmienia kształt awarii: jeśli maszyna zawiśnie, przy kolejnym rozruchu sama wraca do starego. Bo wybór jednorazowy jest z definicji ważny raz.
Zyskujesz to, że nazwą awarii staje się nic się nie stało, a nie maszyny nie ma.
Warstwa druga: zainstalowane nie powinno po cichu stawać się domyślnym
W chwili instalacji jądra większość systemów mówi, że od teraz uruchamiam się najnowszym. Jeśli tego nie chcesz, musisz przypiąć działające jądro przed aktualizacją.
Przypięcie nie blokuje nowego jądra, tylko powstrzymuje je przed staniem się domyślnym samo z siebie. Gdy zechcesz je wypróbować, wybierasz sam.
Warstwa trzecia: kto zauważy zawieszenie
Żeby mechanizm powrotu zadziałał, coś musi powiedzieć, że ta maszyna nie wstała. Jeśli na poziomie sprzętu jest układ nadzorujący, to on to robi i restartuje maszynę.
Jeśli go nie ma, powrót wymaga ręcznego resetu. To nie czyni mechanizmu bezużytecznym, ale trzeba o tym wiedzieć: zdanie o automatycznym powrocie jest prawdziwe tylko w połowie, gdy układu nadzorującego nie ma.
Reguła, która broni się nawet bez produktu
Po aktualizacji jądra zrestartuj świadomie i szybko. Gdy patrzysz.
Restart, który sam zaplanowałeś, jest testem. Restart wymuszony zanikiem zasilania trzy tygodnie później jest incydentem. Jedyną różnicą między nimi jest to, czy byłeś przy tym obecny.
Co robi Atlas
Wykonując aktualizację, Atlas domyślnie przypina działające jądro, więc świeżo zainstalowane jądro nie staje się samo domyślnym dla rozruchu. To zachowanie nie jest przymusowe: jest oferowane jako opcja, którą można wyłączyć w interfejsie. Produkt nie decyduje tu za ciebie, tylko czyni bezpieczną stronę domyślną.
Mechanizm zweryfikowanego przejścia też opiera się na powyższej zasadzie: trwałym ustawieniem domyślnym zawsze zostaje stare jądro, nowe próbuje się tylko jednorazowym następnym rozruchem, a jeśli zawiśnie, system sam wraca. Rodzaj menedżera rozruchu wykrywany jest w czasie działania, bo bywa różny na różnych maszynach.
I dwa uczciwe ograniczenia:
Ten mechanizm działa domyślnie w trybie samej obserwacji. Mówi więc, co by zrobił, ale nie dotyka konfiguracji rozruchu. Faktyczna ingerencja to osobny wybór.
Jeśli nie ma sprzętowego układu nadzorującego, mechanizm nie przemilcza tego: wyłącza się z wdziękiem i mówi, że może być potrzebny ręczny reset. Przedstawianie gwarancji, której nie ma, jest gorsze niż niedawanie żadnej.
Źródła
Własna dokumentacja Proxmoksa. Po angielsku i to ona ma ostatnie słowo w tej sprawie.