Precyzja to podstawa - po update czego???
HA core, OSa czy czegoś innego, każde update daje się cofnąć używając odpowiedniej metody rollbacku.
Jeśli to był HAOS
Nie musisz kombinować - rozwiązanie już jest, tylko jeszcze z niego nie skorzystałeś (i teoretycznie powinno zadziałać, ale jak wiadomo nie ma rozwiązań skutecznych w 100% przypadków).
Jest jeszcze jedno rozwiązanie, o którym nie wspomniałem w podlinkowanym wątku.
Kwestia dotyczy systemu HAOS - ma on zabezpieczenie - po trzykrotnym nieudanym bootowaniu zostaje uruchomiony system z drugiego slotu.
Instalacja HAOS zawiera dwa sloty z systemem (mówiąc prościej są na dysku dwa oddzielne systemy operacyjne w różnych wersjach) w przypadku nieudanej aktualizacji systemu gdy nowa kopia systemu nie startuje należy “na bezczelnego” odłączyć zasilanie na krótki okres (to dotyczy sytuacji, TYLKO gdy masz 200% pewności, że system się nie uruchomił i czekałeś dostatecznie długo), ponawiasz procedurę jeśli znowu się nie uruchomi (odczekując dostatecznie długo - nie wiem ile w twojej konfiguracji całość instalacji startowała przy reboocie ale powiedzmy, że względnie bezpieczne jest odczekanie 10-20 minut między kolejnymi próbami “ruskiego restartu”), nie ma sensu ponawiać tego więcej niż trzy razy (ale gdy sytuacja jest beznadziejna można spróbować i z 5x).
UWAGA 1
Ta procedura dotyczy TYLKO instalacji HAOS-generic i HAOS dla SBC i sytuacji związanych z aktualizacją HAOS
NIE dotyczy wirtualizacji - w przyadku wirtualizacji restartujemy VM a NIE całego hosta!
UWAGA 2
Jeśli procedura trzykrotnego restartu sprzętowego się powiodła, to
- należy zabezpieczyć system przed przypadkowym uruchomieniem się “trefnej wersji” (przykład hipotetyczny trefny jest system 12.2, w wyniku procedury lądujemy na jakiejś poprzedniej wersji, warto wiedzieć na jakiej, ale jeśli aktualizacje były systematyczne, to będzie to 12.1, więc wtedy robimy downgrade do 12.0 a następnie update do 12.1, to zagwarantuje skasowanie systemu w wersji 12.2 z obu slotów).
- należy zgłosić issue do OSa lub dopisać się do pasującego istniejącego
Issues · home-assistant/operating-system · GitHub
UWAGA 3
Wszystko co napisałem powyżej nie dotyczy kwestii związanych z żadnymi INNYMI aktualizacjami oprócz HAOS (nie dotyczy aktualizacji HA core czyli po prostu HA, nie dotyczy aktualizacji Supervisora).
Nie dotyczy tez zmian w konfiguracji wprowadzonych ręcznie.
oraz jak przedmówcy wspomnieli
Aktualizacji systemu nie przeprowadzamy zdalnie jeśli nie zostały one dostatecznie przetestowane przez ogół użytkowników lub sami nie przetestowaliśmy sobie ich na innej instalacji (taki komfort mają tylko posiadacze kilku instalacji HA w tym pracujących w dostatecznie zbliżonym środowisku sieciowym), wprowadzenie MPTCP mogło mieć wpływ na pracę systemu tylko w specyficznych środowiskach LAN (sam robiłem wstępne testy na instalacji testowej jeszcze na wersji beta tego systemu i u mnie jestem w połowie wdrażania 12.2 i jak na razie zaktualizowałem tylko te instalacje gdzie mam łatwy dostęp, w każdym przypadku było to bez problemów, ale instalacje zdalne oczywiście czekają na rozwój sytuacji).
Odniosę się do słów przedmówcy (@opensource4life), który zachwala proxmox’a - taki wybór musi być świadomy, jak i każda inna instalacja niż bare-metal generic (lub SBC dla innych platform niż PC) musi być świadomym wyborem użytkownika.
Moderuję to forum od kilku lat (i w związku z tym być może nie przeczytałem wszystkich postów, ale na pewno ich znakomita większość, więc uważam, że jestem uprawniony do tych wniosków) i po prostu widziałem ile razy proxmox przerósł użytkowników i widzę jaka jest skala migracji proxmox → generic w stosunku do migracji generic → jakikolwiek inny sposób instalacji.