Udostępnij za pośrednictwem

Panika jądra na maszynach wirtualnych z systemem Linux platformy Azure

  • Artykuł

Dotyczy: ✔️ maszyny wirtualne z systemem Linux

W tym artykule omówiono wiele warunków, które mogą prowadzić do paniki jądra i zawiera wskazówki dotyczące rozwiązywania problemów.

Ogólnie rzecz biorąc, panika jądra jest sytuacją, gdy jądro nie może załadować poprawnie, a zatem system nie może uruchomić. Inna forma paniki jądra występuje, gdy jądro napotka sytuację, w jakiej nie wie, jak obsługiwać i chronić się przez zatrzymanie.

Wymagania wstępne

Upewnij się, że konsola szeregowa jest włączona i funkcjonalna na maszynie wirtualnej z systemem Linux.

Jak zidentyfikować panikę jądra?

Użyj witryny Azure Portal, aby wyświetlić dane wyjściowe dziennika konsoli szeregowej maszyny wirtualnej w bloku diagnostyki rozruchu, bloku konsoli szeregowej lub interfejsu wiersza polecenia az w celu zidentyfikowania określonego ciągu paniki jądra.

Panika jądra wygląda podobnie do poniższych danych wyjściowych i zostanie wyświetlona na końcu dziennika konsoli szeregowej:

Probing EDD (edd=off to disable)... ok
Memory KASLR using RDRAND RDTSC...
[  300.206297] Kernel panic - xxxxxxxx
[  300.207216] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G               ------------ T 3.xxx.x86_64 #1

Niektóre z najczęstszych zdarzeń paniki jądra:

Komunikat o paniki Przyczyna
Ops: 0000 [#1] SMP " (sprawdź dziennik, aby uzyskać szczegółowe informacje) System spanikował z powodu wyłudzonego złego adresu.
SysRq: Wyzwalanie zrzutu awaryjnego Zrzut podstawowy został zainicjowany przez użytkownika za pomocą polecenia sysrq-c lub przez echo c do /proc/sysrq-trigger.
kernel BUG at <pathname/filename>:<line number>! Ten format jest standardem dla nieudanego sprawdzania błędów (co jest podobne do asertywnej, ale logika jest odwrócona). Nazwa pliku i numer wiersza będą wskazywać, które sprawdzanie błędów nie powiodło się.
Panika jądra — brak synchronizacji: softlockup: zawieszające się zadania Wykrywacz blokady miękkiej znalazł procesor CPU, który nie zaplanować zadania watchdog w ramach miękkiego progu blokady.
Panika jądra — brak synchronizacji: Watchdog wykrył blokadę twardą na procesorze CPU 0 Twardy detektor blokady znalazł procesor, który nie otrzymał żadnych przerwań hrtimer w ramach twardego progu blokady.
Panika jądra — brak synchronizacji: hung_task: zablokowane zadania Zawieszony element watchdog zadania wykrył co najmniej jedno zadanie, które było w stanie nierozpoznanym dla więcej niż wartość limitu czasu zablokowanego zadania.
Panika jądra — brak synchronizacji: brak pamięci. wybrano panic_on_oom System zabrakło pamięci i zamiany i został zmuszony do rozpoczęcia zabijania procesów zwalniania pamięci (nie domyślnego zachowania).
Panika jądra — brak synchronizacji: brak pamięci i brak procesów, które można zabić... System zabrakło pamięci i zamiany i zabija procesy zwalniania pamięci, ale zabrakło procesów do zabicia.
Panika jądra — brak synchronizacji: Wystąpiła NMI, zobacz zintegrowany dziennik zarządzania, aby uzyskać szczegółowe informacje. Watchdog przechwycił NMI (niemaskowalne przerwanie).
Panika jądra — brak synchronizacji: błąd NMI IOCK: Nie kontynuowano System otrzymał kontrolę operacji we/wy ze sprzętu (nie błąd parzystości pamięci) i kernel.panic_on_io_nmi został ustawiony (a nie domyślny).
Panika jądra — brak synchronizacji: NMI: Nie kontynuowano System otrzymał NMI (błąd parzystości sprzętu lub pamięci), a kernel.panic_on_unrecovered_nmi został ustawiony (a nie domyślny).
Panika jądra — brak synchronizacji: nmi watchdog System otrzymał NMI, a kernel.panic_on_timeout lub kernel.panic_on_oops został ustawiony (a nie wartości domyślne).
Panika jądra — nie jest synchronizowana: sprawdzanie maszyny krytycznej Zdarzenie wyjątku sprawdzania maszyny zostało zgłoszone dla stanu krytycznego.
Panika jądra — brak synchronizacji: podjęto próbę zabicia init! Proces inicjowania jest pierwszym procesem, który należy uruchomić i nigdy nie powinien wyjść.

Scenariusz 1. W czasie rozruchu występuje panika jądra

Panika jądra w czasie rozruchu uniemożliwia maszynie wirtualnej zakończenie procesu uruchamiania systemu operacyjnego. Dzieje się tak za każdym razem, gdy maszyna wirtualna jest uruchamiana i nie zezwala na logowanie.

Tego rodzaju zdarzenie jest często związane, ale nie tylko:

Rozwiązanie dla scenariusza 1

Aby poradzić sobie z tego rodzaju paniką jądra, można użyć następujących podejść:

Metoda 1. Korzystanie z konsoli szeregowej platformy Azure

Użyj konsoli szeregowej platformy Azure, aby przerwać proces rozruchu i wybrać poprzednią wersję jądra, jeśli jest dostępna. W ten sposób maszyna wirtualna będzie mogła ponownie uruchomić się, a następnie użyć jednej z następujących metod, aby rozwiązać konkretny problem z jądrem, który nie uruchamia się:

Metoda 2. Naprawa offline przy użyciu ratowniczej maszyny wirtualnej

Jeśli konsola szeregowa platformy Azure nie jest dostępna lub nie jest dostępne żadne poprzednie jądro, potrzebujesz maszyny wirtualnej ratownictwa/naprawy, aby przeprowadzić naprawę w trybie offline.

Użyj polecenia Napraw maszynę wirtualną, aby utworzyć maszynę wirtualną naprawy, która ma kopię dołączonego dysku systemu operacyjnego docelowej maszyny wirtualnej. Następnie użyj narzędzia chroot zainstalować kopię systemów plików systemu operacyjnego na maszynie wirtualnej naprawy. Następnie spróbuj wykonać następujące metody, aby rozwiązać problemy z jądrem:

Scenariusz 2. Panika jądra w czasie wykonywania

Ten rodzaj paniki jądra jest często wyzwalany w nieprzewidywalnym czasie po zakończeniu procesu uruchamiania systemu operacyjnego i powoduje, że maszyna wirtualna przestanie odpowiadać, uniemożliwiając jej zalogowanie. Jest to często związane, ale nie tylko:

Rozwiązanie dla scenariusza 2

Aby poradzić sobie z tego rodzaju paniką jądra, można użyć następujących podejść:

  • Przejrzyj użycie zasobów i ogólną wydajność systemu. Panika jądra może być związana z możliwym niedoborem zasobów, które mogą prowadzić do zmiany rozmiaru maszyny wirtualnej.
  • Jeśli to możliwe, zainstaluj najnowsze aktualizacje dostępne w odpowiednich repozytoriach dystrybucji systemu Linux. Panika jądra może być związana ze znanymi usterkami w jądrze lub innym oprogramowaniu.
  • Istnieje możliwość, że panika jądra jest związana z niedawną zmianą jądra, w tym przypadku zaleca się również rozruch w poprzedniej wersji jądra, jak wyjaśniono w temacie Rozwiązanie dla scenariusza 1.
  • Jeśli powyższe opcje nie mają zastosowania, może być konieczne skonfigurowanie kdump i wygenerowanie zrzutu podstawowego w celu udostępnienia go w celu dalszej analizy.

Bardziej szczegółowe scenariusze paniki jądra

Typowe scenariusze paniki jądra z określonymi instrukcjami rozwiązywania problemów/odzyskiwania:

Dokument Scenariusz
Na maszynie wirtualnej platformy Azure z systemem Linux na bazie jądra opartego na wersji 3.10 występują błędy po uaktualnieniu węzła hosta W tym artykule omówiono problem, który występuje, gdy maszyna wirtualna z systemem Linux platformy Azure z uruchomionym jądrom opartym na wersji 3.10 ulega awarii po uaktualnieniu węzła hosta na platformie Azure.
Jak odzyskać maszynę wirtualną z systemem Linux platformy Azure z problemów z rozruchem powiązanym z jądrem Ten artykuł zawiera rozwiązania problemu, w którym maszyna wirtualna z systemem Linux nie może ponownie uruchomić się po zastosowaniu zmian jądra.

Skontaktuj się z nami, aby uzyskać pomoc

Jeśli masz pytania lub potrzebujesz pomocy, utwórz wniosek o pomoc techniczną lub zadaj pomoc techniczną społeczności platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii na temat platformy Azure.