Udostępnij przez

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

  • Artykuł

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

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

Wymagania wstępne

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

Jak zidentyfikować panikę jądra?

Użyj Azure Portal, aby wyświetlić dane wyjściowe dziennika konsoli szeregowej maszyny wirtualnej w bloku diagnostyki rozruchu, bloku konsoli szeregowej lub interfejsie wiersza polecenia AZ, aby zidentyfikować określony ciąg błędu jądra.

Błąd jądra wygląda podobnie do poniższych danych wyjściowych i zostanie wyświetlony 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:

Wiadomość paniki Powodu
Oops: 0000 [#1] SMP " (sprawdź dziennik, aby uzyskać szczegółowe informacje) System wpadł w panikę z powodu wyłudzania nieprawidłowego adresu.
SysRq: Wyzwalanie crashdump Zrzut rdzeni został zainicjowany przez użytkownika za pomocą polecenia sysrq-c lub przez echo c do /proc/sysrq-trigger.
USTERKA jądra pod adresem <pathname/filename>:<line number>! Ten format jest standardem dla sprawdzania błędów zakończonych niepowodzeniem (który jest podobny do ASERCJI, ale logika jest odwrócona). Nazwa pliku i numer wiersza będą wskazywać, które sprawdzanie błędu nie powiodło się.
Panika jądra — brak synchronizacji: softlockup: zadania zawieszające się Wykrywacz blokady nietrwałej znalazł procesor CPU, który nie zaplanował zadania watchdog w ramach progu blokady nietrwałej.
Panika jądra — nie synchronizowanie: Watchdog wykrył twardą blokadę na procesorze 0 Twardy czujnik blokady znalazł procesor, który nie otrzymał żadnych przerwań hrtimer w ramach progu twardej blokady.
Panika jądra — nie synchronizowanie: hung_task: zablokowane zadania Zawieszający się strażnik zadań wykrył co najmniej jedno zadanie, które było w stanie nieinterruptalnym dla więcej niż wartość limitu czasu zablokowanego zadania.
Panika jądra — brak synchronizacji: brak pamięci. panic_on_oom jest zaznaczona W systemie zabrakło pamięci i wymiany i został zmuszony do rozpoczęcia zabijania procesów w celu zwolnienia pamięci (a nie domyślnego zachowania).
Panika jądra — brak synchronizacji: Brak pamięci i brak procesów możliwych do zabicia... System zabrakło pamięci i wymiany i został zabijania procesów, aby zwolnić pamięć, ale zabrakło procesów, aby zabić.
Panika jądra — brak synchronizacji: Wystąpiła usługa 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 kontynuuj System otrzymał usługę NMI sprawdzania operacji we/wy ze sprzętu (nie błąd parzystości pamięci) i kernel.panic_on_io_nmi została ustawiona (nie domyślna).
Panika jądra — brak synchronizacji: NMI: Nie kontynuuj System otrzymał NMI (błąd parzystości sprzętu lub pamięci), a kernel.panic_on_unrecovered_nmi została ustawiona (nie domyślna).
Panika jądra — nie synchronizowanie: nmi watchdog System otrzymał NMI i ustawiono kernel.panic_on_timeout lub kernel.panic_on_oops (nie wartości domyślne).
Panika jądra — nie synchronizowanie: sprawdzanie maszyny ze skutkiem śmiertelnym Dla stanu krytycznego zgłoszono zdarzenie wyjątku sprawdzania maszyny.
Panika jądra — nie synchronizowanie: Próbowano zabić init! Proces init jest pierwszym procesem, który należy uruchomić i nigdy nie powinien kończyć pracy.

Scenariusz 1. Panika jądra występuje w czasie rozruchu

Błąd 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 powiązane, ale nie ogranicza się do:

Rozwiązanie dla scenariusza 1

Aby poradzić sobie z tego rodzaju paniką jądra, można zastosować następujące podejścia:

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ć rozruch, a następnie użyć jednej z następujących metod, aby rozwiązać konkretny problem z jądrem bez rozruchu:

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

Jeśli konsola szeregowa platformy Azure nie jest dostępna lub żadne poprzednie jądro nie jest dostępne, do naprawy w trybie offline potrzebna jest maszyna wirtualna do ratowania/naprawy.

Użyj polecenia Napraw maszynę wirtualną, aby utworzyć maszynę wirtualną naprawczą z dołączoną kopią dysku systemu operacyjnego docelowej maszyny wirtualnej. Następnie użyj narzędzia chroot , aby 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 przestaje odpowiadać, uniemożliwiając jej zalogowanie się. 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 zastosować następujące podejścia:

  • Przejrzyj użycie zasobów i ogólną wydajność systemu. Panika jądra może być związana z możliwym brakiem zasobów, który może 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 takim przypadku zaleca się również rozruch w poprzedniej wersji jądra, jak wyjaśniono w rozwiązaniu dla scenariusza 1.
  • Jeśli powyższe opcje nie mają zastosowania, może być konieczne skonfigurowanie narzędzia kdump i wygenerowanie zrzutu podstawowego w celu udostępnienia go z obsługą dalszej analizy.

Bardziej szczegółowe scenariusze paniki jądra

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

Dokument Scenariusz
Maszyna wirtualna platformy Azure z systemem Linux na jądrze opartym na wersji 3.10 wpada w panikę po uaktualnieniu węzła hosta W tym artykule omówiono problem występujący, gdy maszyna wirtualna platformy Azure z systemem Linux z uruchomionym jądrem opartym na wersji 3.10 ulega awarii po uaktualnieniu węzła hosta na platformie Azure.
Jak odzyskać maszynę wirtualną platformy Azure z systemem Linux z powodu problemów z rozruchem związanym z jądrem Ten artykuł zawiera rozwiązania problemu, w którym maszyna wirtualna z systemem Linux nie może zostać ponownie uruchomiona 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 pytanie w społeczności wsparcia dla platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii platformy Azure.