Nie można uruchomić maszyny wirtualnej platformy Azure z systemem Linux po zastosowaniu zmian jądra

Uwaga

CentOS, do którego odwołuje się ten artykuł, jest dystrybucją systemu Linux i osiągnie koniec życia (EOL). Rozważ użycie i odpowiednio zaplanuj. Aby uzyskać więcej informacji, zobacz Wskazówki dotyczące końca życia systemu CentOS.

Ten artykuł zawiera rozwiązania problemu, w którym maszyna wirtualna z systemem Linux nie może zostać uruchomiona po zastosowaniu zmian jądra.

Wymagania wstępne

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

Jak zidentyfikować problem z rozruchem związanym z jądrem

Aby zidentyfikować problem z rozruchem związanym z jądrem, sprawdź określony ciąg błędu jądra. W tym celu użyj interfejsu wiersza polecenia platformy Azure lub Azure Portal, aby wyświetlić dane wyjściowe dziennika konsoli szeregowej maszyny wirtualnej w okienku diagnostyki rozruchu lub okienku konsoli szeregowej.

Błąd jądra wygląda jak następujące dane wyjściowe 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

Rozwiązywanie problemów online

Porada

Jeśli masz ostatnio utworzoną kopię zapasową maszyny wirtualnej, przywróć maszynę wirtualną z kopii zapasowej , aby rozwiązać problem z rozruchem.

Konsola szeregowa jest najszybszą metodą rozwiązywania problemu z rozruchem. Umożliwia to bezpośrednie rozwiązanie problemu bez konieczności prezentowania dysku systemowego na maszynie wirtualnej odzyskiwania. Upewnij się, że spełniasz wymagania wstępne niezbędne do dystrybucji. Aby uzyskać więcej informacji, zobacz Konsola szeregowa maszyny wirtualnej dla systemu Linux.

1. Zidentyfikuj konkretny problem z rozruchem związanym z jądrem.

2. Użyj konsoli szeregowej platformy Azure , aby przerwać maszynę wirtualną w menu GRUB i wybrać poprzednie jądro, aby ją uruchomić. Aby uzyskać więcej informacji, zobacz System rozruchowy w starszej wersji jądra.

3. Przejdź do odpowiedniej sekcji, aby rozwiązać konkretny problem z rozruchem związanym z jądrem:

   • Błąd jądra — brak synchronizacji: system plików VFS: nie można zainstalować głównych plików fs na nieznanym bloku (0,0)
   • Panika jądra — nie synchronizowanie: Próbowano zabić init!
   • Inne problemy z rozruchem związane z jądrem

4. Po rozwiązaniu problemu z rozruchem związanym z jądrem uruchom ponownie maszynę wirtualną, aby mogła zostać uruchomiona w najnowszej wersji jądra.

Rozwiązywanie problemów w trybie offline

Porada

Jeśli masz ostatnio utworzoną kopię zapasową maszyny wirtualnej, przywróć maszynę wirtualną z kopii zapasowej , aby rozwiązać problem z rozruchem.

Jeśli konsola szeregowa platformy Azure nie działa na określonej maszynie wirtualnej lub nie jest dostępna w twojej subskrypcji, rozwiąż problem z rozruchem przy użyciu maszyny wirtualnej ratowniczej/naprawczej. Aby to zrobić, wykonaj następujące kroki.

1. Użyj poleceń naprawy maszyny wirtualnej , aby utworzyć maszynę wirtualną naprawczą, która ma dołączoną kopię dysku systemu operacyjnego maszyny wirtualnej, którego dotyczy problem. Zainstaluj kopię systemów plików systemu operacyjnego na maszynie wirtualnej naprawy przy użyciu narzędzia chroot.

   Uwaga

   Alternatywnie można ręcznie utworzyć maszynę wirtualną ratunkową przy użyciu Azure Portal. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z maszyną wirtualną z systemem Linux, dołączając dysk systemu operacyjnego do maszyny wirtualnej odzyskiwania przy użyciu Azure Portal.

2. Zidentyfikuj konkretny problem z rozruchem związanym z jądrem.

3. Przejdź do odpowiedniej sekcji, aby rozwiązać konkretny problem z rozruchem związanym z jądrem:

   • Błąd jądra — brak synchronizacji: system plików VFS: nie można zainstalować głównych plików fs na nieznanym bloku (0,0)
   • Panika jądra — nie synchronizowanie: Próbowano zabić init!
   • Inne problemy z rozruchem związane z jądrem

4. Po rozwiązaniu problemu z rozruchem związanym z jądrem wykonaj następujące akcje:

   1. Zamknij chroot.
   2. Odinstaluj kopię systemów plików z maszyny wirtualnej ratowniczej/naprawczej.
   3. Uruchom polecenie , az vm repair restore aby zamienić naprawiony dysk systemu operacyjnego na oryginalny dysk systemu operacyjnego maszyny wirtualnej. Aby uzyskać więcej informacji, zobacz Krok 5 w artykule Naprawianie maszyny wirtualnej z systemem Linux przy użyciu poleceń naprawy maszyny wirtualnej platformy Azure.
   4. Sprawdź, czy maszyna wirtualna jest w stanie uruchomić się, przyglądając się konsoli szeregowej platformy Azure lub próbując nawiązać połączenie z maszyną wirtualną.

5. Jeśli istnieje ważna zawartość związana z jądrem, brakuje całej /boot partycji lub innej ważnej zawartości i nie można jej odzyskać, zalecamy przywrócenie maszyny wirtualnej z kopii zapasowej. Aby uzyskać więcej informacji, zobacz How to restore Azure VM data in Azure Portal (Jak przywrócić dane maszyny wirtualnej platformy Azure w Azure Portal).

System rozruchowy w starszej wersji jądra

Korzystanie z konsoli szeregowej platformy Azure

1. Uruchom ponownie maszynę wirtualną przy użyciu konsoli szeregowej platformy Azure.

   1. Wybierz przycisk zamykania w górnej części okna konsoli szeregowej.
   2. Wybierz opcję Uruchom ponownie maszynę wirtualną (twardą ).

2. Po wznowieniu połączenia konsoli szeregowej w lewym górnym rogu okna konsoli szeregowej zostanie wyświetlony licznik odliczania. Naciśnij klawisz ESCAPE , aby przerwać maszynę wirtualną w menu GRUB.

3. Naciśnij klawisz strzałki w dół, aby wybrać dowolną poprzednią wersję jądra.

   

4. Zmień zmienną GRUB_DEFAULT w pliku /etc/default/grub zgodnie z instrukcjami w temacie Ręczne zmienianie domyślnej wersji jądra. Jest to trwała zmiana.

Uwaga

Jeśli w menu GRUB znajduje się tylko jedna wersja jądra, postępuj zgodnie z podejściem do rozwiązywania problemów w trybie offline , aby rozwiązać ten problem z naprawy maszyny wirtualnej.

Używanie naprawy maszyny wirtualnej (skrypty ALAR)

1. Uruchom następujące polecenie powłoki bash na platformie Azure Cloud Shell, aby utworzyć maszynę wirtualną do naprawy. Aby uzyskać więcej informacji, zobacz Używanie automatycznej naprawy systemu Azure Linux (ALAR) w celu naprawienia opcji Maszyna wirtualna z systemem Linux — jądro.

   az vm repair create --verbose -g $RGNAME -n $VMNAME --repair-username rescue --repair-password 'password!234' --copy-disk-name repairdiskcopy
   

2. Uruchom następujące polecenie, aby zastąpić uszkodzone jądro poprzednio zainstalowaną wersją:

   az vm repair run --verbose -g $RGNAME -n $VMNAME --run-id linux-alar2 --parameters kernel --run-on-repair
   
   az vm repair restore --verbose -g $RGNAME -n $VMNAME
   

Uwaga

Jeśli w systemie zainstalowano tylko jedną wersję jądra, postępuj zgodnie z podejściem do rozwiązywania problemów w trybie offline , aby rozwiązać ten problem z naprawy maszyny wirtualnej.

Ręczne zmienianie domyślnej wersji jądra

Aby zmodyfikować domyślną wersję jądra z maszyny wirtualnej naprawy (wewnątrz chroot) lub na uruchomionej maszynie wirtualnej, wykonaj następujące kroki:

Uwaga

Jeśli wycofywanie jądra zostało wycofane na starszą wersję, wybierz najnowszą wersję jądra zamiast starszej.

• RHEL 7, Oracle Linux 7 i CentOS 7

  1. Zweryfikuj listę dostępnych jąder w pliku konfiguracji GRUB, uruchamiając jedno z następujących poleceń:

     • Maszyny wirtualne gen1:

       cat /boot/grub2/grub.cfg | grep menuentry
       

     • Maszyny wirtualne gen2:

       cat /boot/efi/EFI/*/grub.cfg | grep menuentry
       

  2. Ustaw nowe domyślne jądro i określ odpowiedni tytuł jądra, uruchamiając następujące polecenie:

     # grub2-set-default 'Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64'
     

     Uwaga

     Zastąp Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64 ciąg odpowiednim tytułem wpisu menu.

  3. Sprawdź, czy nowe domyślne jądro jest żądane, uruchamiając następujące polecenie:

     grub2-editenv list
     

  4. Upewnij się, że wartość zmiennej GRUB_DEFAULT w pliku /etc/default/grub jest ustawiona na saved. Aby go zmodyfikować, należy ponownie wygenerować plik konfiguracji GRUB w celu zastosowania zmian.

• RHEL 8/9 i CentOS 8

  1. Wyświetl listę dostępnych jąder, uruchamiając następujące polecenie:

     ls -l /boot/vmlinuz-*
     

  2. Ustaw nowe domyślne jądro, uruchamiając następujące polecenie:

     grubby --set-default /boot/vmlinuz-4.18.0-372.19.1.el8_6.x86_64
     

     Uwaga

     Zastąp 4.18.0-372.19.1.el8_6.x86_64 element odpowiednią wersją jądra.

  3. Sprawdź, czy nowe domyślne jądro jest żądane, uruchamiając następujące polecenie:

     grubby --default-kernel
     

• SLES 12/15, Ubuntu 18.04/20.04

  1. Wyświetl listę dostępnych jąder w pliku konfiguracji GRUB, uruchamiając następujące polecenie:

     • Maszyny wirtualne gen1:

       • SLES 12/15:

         cat /boot/grub2/grub.cfg | grep menuentry
         

       • Ubuntu 18.04/20.04:

         cat /boot/grub/grub.cfg | grep menuentry
         

     • Maszyny wirtualne gen2:

       cat /boot/efi/EFI/*/grub.cfg | grep menuentry
       

  2. Ustaw nowe domyślne jądro, modyfikując wartość zmiennej GRUB_DEFAULT w pliku /etc/default/grub . W przypadku najnowszej wersji jądra zainstalowanej w systemie wartość domyślna to 0. Następne dostępne jądro ma wartość "1>2".

     vi /etc/default/grub
     GRUB_DEFAULT="1>2"
     

     Uwaga

     Aby uzyskać więcej informacji na temat konfigurowania zmiennej GRUB_DEFAULT , zobacz SUSE Boot Loader GRUB2 i Ubuntu Grub2/Setup. Jako odwołanie: wartość menuentry najwyższego poziomu wynosi 0, pierwsza wartość podmenu najwyższego poziomu to 1, a każda zagnieżdżona wartość menuentry zaczyna się od 0. Na przykład "1>2" to trzecia pozycja menuentry z pierwszego podmenu.

  3. Wygeneruj ponownie plik konfiguracji GRUB, aby zastosować zmiany. Postępuj zgodnie z instrukcjami w temacie Ponowne instalowanie pliku GRUB i ponowne generowanie pliku konfiguracji GRUB dla odpowiedniej dystrybucji systemu Linux i generowania maszyn wirtualnych.

Błąd jądra — brak synchronizacji: system plików VFS: nie można zainstalować głównych plików fs na nieznanym bloku (0,0)

Ten błąd występuje z powodu niedawnej aktualizacji systemu (jądra). Jest to najczęściej spotykane w dystrybucjach opartych na systemie RHEL. Ten problem można zidentyfikować z poziomu konsoli szeregowej platformy Azure. Zobaczysz dowolny z następujących komunikatów o błędach:

1. "Panika jądra — nie synchronizowanie: VFS: Nie można zainstalować głównej fs na nieznanym bloku (0,0)"

   [  301.026129] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
   [  301.027122] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G               ------------ T 3.10.0-1160.36.2.el7.x86_64 #1
   [  301.027122] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008  12/07/2018
   [  301.027122] Call Trace:
   [  301.027122]  [<ffffffff82383559>] dump_stack+0x19/0x1b
   [  301.027122]  [<ffffffff8237d261>] panic+0xe8/0x21f
   [  301.027122]  [<ffffffff8298b794>] mount_block_root+0x291/0x2a0
   [  301.027122]  [<ffffffff8298b7f6>] mount_root+0x53/0x56
   [  301.027122]  [<ffffffff8298b935>] prepare_namespace+0x13c/0x174
   [  301.027122]  [<ffffffff8298b412>] kernel_init_freeable+0x222/0x249
   [  301.027122]  [<ffffffff8298ab28>] ? initcall_blcklist+0xb0/0xb0
   [  301.027122]  [<ffffffff82372350>] ? rest_init+0x80/0x80
   [  301.027122]  [<ffffffff8237235e>] kernel_init+0xe/0x100
   [  301.027122]  [<ffffffff82395df7>] ret_from_fork_nospec_begin+0x21/0x21
   [  301.027122]  [<ffffffff82372350>] ? rest_init+0x80/0x80
   [  301.027122] Kernel Offset: 0xc00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
   

2. "error: file '/initramfs-*.img' not found"

   błąd: nie znaleziono pliku "/initramfs-3.10.0-1160.36.2.el7.x86_64.img".

Ten rodzaj błędu wskazuje, że plik initramfs nie jest generowany, plik konfiguracji GRUB ma brakujący wpis initrd po procesie stosowania poprawek lub ręczną błędną konfigurację GRUB.

Przed ponownym uruchomieniem serwera zalecamy zweryfikowanie konfiguracji i /boot zawartości narzędzia GRUB, jeśli istnieje aktualizacja jądra, uruchamiając jedno z następujących poleceń. Ważne jest, aby upewnić się, że aktualizacja została wykonana i nie brakuje plików initramfs.

• System BIOS — systemy Gen1

  # ls -l /boot
  # cat /boot/grub2/grub.cfg
  

• Oparte na interfejsie UEFI — systemy Gen2

  # ls -l /boot
  # cat /boot/efi/EFI/*/grub.cfg
  

Ponowne generowanie brakujących plików initramf przy użyciu skryptów ALAR maszyny wirtualnej naprawy platformy Azure

1. Utwórz naprawczą maszynę wirtualną, uruchamiając następujący wiersz polecenia powłoki Bash z usługą Azure Cloud Shell. Aby uzyskać więcej informacji, zobacz Używanie usługi Azure Linux Auto Repair (ALAR) do naprawy maszyny wirtualnej z systemem Linux — initrd.

   az vm repair create --verbose -g $RGNAME -n $VMNAME --repair-username rescue --repair-password 'password!234' --copy-disk-name repairdiskcopy
   

2. Wygeneruj ponownie obraz initrd/initramfs i ponownie wygeneruj plik konfiguracji GRUB, jeśli brakuje wpisu initrd. Aby to zrobić, uruchom następujące polecenie:

   az vm repair run --verbose -g $RGNAME -n $VMNAME --run-id linux-alar2 --parameters initrd --run-on-repair
   
   az vm repair restore --verbose -g $RGNAME -n $VMNAME
   

3. Po wykonaniu polecenia przywracania uruchom ponownie oryginalną maszynę wirtualną i sprawdź, czy można ją uruchomić.

Ręczne ponowne generowanie brakujących plików initramf

Ważna

• Jeśli możesz uruchomić maszynę wirtualną przy użyciu poprzedniej wersji jądra lub wewnątrz chroot z maszyny wirtualnej naprawy/ratowania, ponownie zregeneruj brakujące pliki initramfs ręcznie.
• Aby ponownie wygenerować brakujące pliki initramfs ręcznie z maszyny wirtualnej naprawy, upewnij się, że krok 1 w rozwiązywaniu problemów w trybie offline został już wykonany, a te polecenia są wykonywane wewnątrz chroot.

1. Zidentyfikuj konkretną wersję jądra, która ma problemy z rozruchem. Informacje o wersji można wyodrębnić z odpowiedniego błędu paniki jądra.

   Skorzystaj z poniższego zrzutu ekranu jako przykładu. Błąd błędu paniki jądra pokazuje, że wersja jądra to "3.10.0-1160.59.1.el7.x86_64":

   

2. Wygeneruj ponownie brakujący plik initramfs, uruchamiając jedno z następujących poleceń:

   • RHEL/CentOS/Oracle Linux 7/8

     sudo depmod -a 3.10.0-1160.59.1.el7.x86_64
     sudo dracut -f /boot/initramfs-3.10.0-1160.59.1.el7.x86_64.img 3.10.0-1160.59.1.el7.x86_64
     

     Ważna

     Zastąp 3.10.0-1160.59.1.el7.x86_64 element odpowiednią wersją jądra.

   • SLES 12/15

     sudo depmod -a 5.3.18-150300.38.53-azure
     sudo dracut -f /boot/initrd-5.3.18-150300.38.53-azure 5.3.18-150300.38.53-azure
     

     Ważna

     Zastąp 5.3.18-150300.38.53-azure element odpowiednią wersją jądra.

   • Ubuntu 18.04

     sudo depmod -a 5.4.0-1077-azure
     sudo mkinitramfs -k -o /boot/initrd.img-5.4.0-1077-azure
     

     Ważna

     Zastąp 5.4.0-1077-azure element odpowiednią wersją jądra.

3. Wygeneruj ponownie plik konfiguracji NARZĘDZIA GRUB. Postępuj zgodnie z instrukcjami w temacie Reinstall GRUB and regenerate GRUB configuration file for the corresponding Linux distribution and VM generation (Ponowne instalowanie pliku GRUB i ponowne generowanie pliku konfiguracji GRUB dla odpowiedniej dystrybucji systemu Linux i generacji maszyny wirtualnej)

4. Jeśli powyższe kroki są wykonywane z naprawy maszyny wirtualnej, wykonaj krok 3 w rozwiązywaniu problemów w trybie offline. Jeśli powyższe kroki są wykonywane z poziomu konsoli szeregowej platformy Azure, postępuj zgodnie z metodą rozwiązywania problemów online .

5. Uruchom ponownie maszynę wirtualną w najnowszej wersji jądra.

Panika jądra — nie synchronizowanie: Próbowano zabić init

Zidentyfikuj ten problem z poziomu konsoli szeregowej platformy Azure. Zobaczysz dane wyjściowe podobne do następujących:

dracut Warning: Boot has failed. To debug this issue add "rdshell" to the kernel command line.
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: init Not tainted 2.6.32-754.17.1.el6.x86_64 #1
Call Trace:
 [<ffffffff81558bfa>] ? panic+0xa7/0x18b
 [<ffffffff81130370>] ? perf_event_exit_task+0xc0/0x340
 [<ffffffff81086433>] ? do_exit+0x853/0x860
 [<ffffffff811a33b5>] ? fput+0x25/0x30
 [<ffffffff81564272>] ? system_call_after_swapgs+0xa2/0x152
 [<ffffffff81086498>] ? do_group_exit+0x58/0xd0
 [<ffffffff81086527>] ? sys_exit_group+0x17/0x20
 [<ffffffff81564357>] ? system_call_fastpath+0x35/0x3a
 [<ffffffff8156427e>] ? system_call_after_swapgs+0xae/0x152

Ten rodzaj paniki jądra występuje z następujących możliwych przyczyn:

• Brak ważnych plików i katalogów.

• Brak ważnych bibliotek i pakietów podstawowych systemu

• Nieprawidłowe uprawnienia do pliku

• Brak partycji

• Problemy z programem SELinux

Aby uzyskać szczegółowe informacje o przyczynach i rozwiązaniach, zobacz poniższe sekcje. Upewnij się, że polecenia są wykonywane z maszyny wirtualnej naprawy/ratowania wewnątrz środowiska chroot zgodnie z instrukcjami w rozwiązywaniu problemów w trybie offline.

Brak ważnych plików i katalogów

Brak ważnych plików i katalogów systemu Linux z powodu błędu ludzkiego. Na przykład pliki są przypadkowo usuwane lub uszkodzenie systemu plików.

1. Zweryfikuj zawartość dysku systemu operacyjnego po dołączeniu kopii dysku systemu operacyjnego do maszyny wirtualnej do naprawy i zainstalowaniu odpowiednich systemów plików przy użyciu narzędzia chroot. Dane wyjściowe można porównać z danymi z działającej maszyny wirtualnej z tą samą wersją systemu operacyjnego.

   ls -l /
   ls -l /usr/lib
   ls -l /usr/lib64
   ls -lR / | more
   

2. Przywróć brakujące pliki z kopii zapasowej. Aby uzyskać więcej informacji, zobacz Odzyskiwanie plików z kopii zapasowej maszyny wirtualnej platformy Azure. W zależności od liczby brakujących plików lepszym rozwiązaniem może być przeprowadzenie pełnego przywracania maszyny wirtualnej. Aby uzyskać więcej informacji, zobacz How to restore Azure VM data in Azure Portal (Jak przywrócić dane maszyny wirtualnej platformy Azure w Azure Portal).

Brak ważnych bibliotek i pakietów podstawowych systemu

Ważne biblioteki, pliki lub pakiety podstawowe systemu są usuwane z systemu lub uszkodzone. Aby rozwiązać ten problem, zainstaluj ponownie biblioteki, pliki lub pakiety, których dotyczy problem. To rozwiązanie działa na dystrybucjach opartych na programie RPM, takich jak maszyny wirtualne Red Hat/CentOS/SUSE. W przypadku innych dystrybucji systemu Linux zalecamy przywrócenie maszyny wirtualnej z kopii zapasowej.

Aby przeprowadzić ponowną instalację, wykonaj następujące kroki:

1. Utwórz maszynę wirtualną ratunkową przy użyciu nieprzetworzonego obrazu z tą samą wersją systemu operacyjnego i generacją co maszyna wirtualna, która ma problem.

2. Aby rozwiązać ten problem, uzyskaj dostęp do środowiska chroot na maszynie wirtualnej ratowniczej.

   sudo chroot /rescue
   

   Dane wyjściowe polecenia wskażą, której biblioteki brakuje lub która jest uszkodzona, jak pokazano poniżej:

   /bin/bash: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
   

3. Sprawdź wszystkie pakiety systemowe i ich odpowiedni stan na maszynie wirtualnej ratowniczej. Porównaj dane wyjściowe z maszyną wirtualną w dobrej kondycji z tą samą wersją systemu operacyjnego.

   sudo rpm --verify --all --root=/rescue 
   

   Oto przykład danych wyjściowych polecenia:

   error: Failed to dlopen /usr/lib64/rpm-plugins/systemd_inhibit.so /lib64/librt.so.1: undefined symbol: __pthread_attr_copy, version GLIBC_PRIVATE
   S.5....T.  c /etc/dnf/dnf.conf
   S.5....T.  c /etc/ssh/sshd_config
   .M.......    /boot/efi/EFI/BOOT/BOOTX64.EFI
   .M.......    /boot/efi/EFI/BOOT/fbx64.efi
   .M.......    /boot/efi/EFI/redhat/BOOTX64.CSV
   .M.......    /boot/efi/EFI/redhat/mmx64.efi
   .M.......    /boot/efi/EFI/redhat/shimx64-redhat.efi
   .M.......    /boot/efi/EFI/redhat/shimx64.efi
   missing     /run/motd.d
   .M.......  g /var/spool/anacron/cron.daily
   .M.......  g /var/spool/anacron/cron.monthly
   .M.......  g /var/spool/anacron/cron.weekly
   missing     /lib64/libc-2.28.so     <-------
   .M.......    /boot/efi/EFI/redhat
   S.5....T.  c /etc/security/pwquality.conf
   

   Wiersz missing /lib64/libc-2.28.so wyjściowy jest powiązany z poprzednim błędem w kroku 2 i wskazuje, że brakuje pakietu libc-2.28.so . Można jednak zmodyfikować pakiet libc-2.28.so . W takim przypadku dane wyjściowe będą wyświetlane .M..... zamiast missing. Do pakietu libc-2.28.so odwołuje się przykład w poniższych krokach.

4. Na maszynie wirtualnej ratunkowej sprawdź, który pakiet zawiera bibliotekę /lib64/libc-2.28.so.

   sudo rpm -qf /lib64/libc-2.28.so
   

   glibc-2.28-127.0.1.el8.x86_64
   

   Uwaga

   W danych wyjściowych zostanie wyświetlony pakiet, który należy ponownie zainstalować, w tym nazwę i wersję pakietu. Wersja pakietu może różnić się od wersji zainstalowanej na maszynie wirtualnej, która ma problem.

5. Na maszynie wirtualnej, której dotyczy problem, sprawdź, która wersja pakietu glibc jest zainstalowana.

   sudo rpm -qa --all --root=/rescue | grep -i glibc
   

   glibc-common-2.28-211.0.1.el8.x86_64
   glibc-gconv-extra-2.28-211.0.1.el8.x86_64
   glibc-2.28-211.0.1.el8.x86_64     <----  
   glibc-langpack-en-2.28-211.0.1.el8.x86_64
   

6. Pobierz pakiet glibc-2.28-211.0.1.el8.x86_64. Możesz pobrać go z oficjalnej witryny internetowej dostawcy systemu operacyjnego lub z maszyny wirtualnej ratunkowej przy użyciu narzędzia do zarządzania pakietami, takiego jak yumdownloader lub zypper install --download-only <packagename> w zależności od używanego systemu operacyjnego.

   Oto przykład użycia yumdownloader narzędzia:

   cd /tmp
   sudo yumdownloader glibc-2.28-211.0.1.el8.x86_64
   

   Last metadata expiration check: 0:03:24 ago on Thu 25 May 2023 02:36:25 PM UTC.
   glibc-2.28-211.0.1.el8.x86_64.rpm               8.7 MB/s | 2.2 MB     00:00    
   

7. Zainstaluj ponownie pakiet, którego dotyczy problem, na maszynie wirtualnej ratowniczej.

   sudo rpm -ivh --root=/rescue /tmp/glibc-*.rpm --replacepkgs --replacefiles
   

   warning: /tmp/glibc-2.28-211.0.1.el8.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID ad986da3: NOKEY
   Verifying...                          ################################# [100%]
   Preparing...                          ################################# [100%]
   Updating / installing...
      1:glibc-2.28-211.0.1.el8           ################################# [100%]
   

8. Uzyskaj dostęp do środowiska chroot na maszynie wirtualnej ratowniczej, aby zweryfikować ponowną instalację.

   sudo chroot /rescue
   

9. Wyłącz maszynę wirtualną ratunkową i zamień dysk systemu operacyjnego na maszynę wirtualną, która ma problem.

Nieprawidłowe uprawnienia do pliku

Nieprawidłowe uprawnienia do plików w całym systemie są modyfikowane z powodu błędu ludzkiego (na przykład ktoś działa chmod 777 w systemie / lub innych ważnych systemach plików systemu operacyjnego). Aby rozwiązać ten problem, przywróć uprawnienia do pliku. To rozwiązanie działa na dystrybucjach opartych na programie RPM, takich jak maszyny wirtualne Red Hat/CentOS/SUSE. W przypadku innych dystrybucji systemu Linux zalecamy przywrócenie maszyny wirtualnej z kopii zapasowej.

Aby przywrócić uprawnienia do pliku, uruchom następujące polecenie po dołączeniu kopii dysku systemu operacyjnego do naprawy maszyny wirtualnej i zainstalowaniu odpowiednich systemów plików przy użyciu narzędzia chroot:

rpm -a --setperms
rpm --setugids --all
chmod u+s /bin/sudo
chmod 660 /etc/sudoers.d/*
chmod 644 /etc/ssh/*.pub
chmod 640 /etc/ssh/*.key

Uwaga

Nie uruchamiaj tego polecenia w systemach produkcyjnych.

Jeśli problem nadal występuje po ręcznym odzyskaniu odpowiednich uprawnień do pliku, wykonaj przywracanie z kopii zapasowej.

Brak partycji

W przypadkach, gdy /usrsystemy plików , /opt, /var/home, /tmpi / są rozłożone na różne partycje, dane mogą być niedostępne z powodu problemów na poziomie partycji, które mogą być spowodowane błędami podczas operacji zmiany rozmiaru partycji lub innych.

W tym scenariuszu, jeśli udokumentowasz oryginalny układ tabeli partycji z dokładnymi sektorami początkowymi i końcowymi dla każdej z oryginalnych partycji, a w systemie nie są wykonywane żadne dalsze modyfikacje, takie jak tworzenie nowych systemów plików, utwórz ponownie partycje przy użyciu tego samego oryginalnego układu z narzędziami takimi jak fdisk (dla tabel partycji MBR) lub gdisk (w przypadku tabel partycji GPT), aby uzyskać dostęp do brakującego systemu plików.

Jeśli to podejście nie zadziała, wykonaj przywracanie z kopii zapasowej.

Problemy z programem SELinux

Nieprawidłowe uprawnienia SELinux mogą uniemożliwić systemowi dostęp do ważnych plików. Aby rozwiązać ten problem, wykonaj następujące kroki:

1. Aby sprawdzić, czy system ma problemy z powodu nieprawidłowych uprawnień SELinux, uruchom system z wyłączoną funkcją SELinux, dodając opcję jądra selinux=0 do wiersza GRUB linux16.

2. Jeśli system jest w stanie uruchomić rozruch, uruchom następujące polecenie, aby wyzwolić ponowne oznaczenie SELinux w czasie rozruchu i ponownie uruchomić system:

   touch /.autorelabel
   

3. Jeśli maszyna wirtualna nadal nie może przeprowadzić rozruchu, wykonaj pełne przywracanie maszyny wirtualnej z kopii zapasowej. Aby uzyskać więcej informacji, zobacz How to restore Azure VM data in Azure Portal (Jak przywrócić dane maszyny wirtualnej platformy Azure w Azure Portal).

Inne problemy z rozruchem związane z jądrem

W tym artykule opisano najczęstsze błędy jądra systemu Linux zidentyfikowane na platformie Azure. Aby uzyskać więcej informacji na temat typowych scenariuszy paniki jądra, zobacz Panika jądra na maszynach wirtualnych z systemem Linux platformy Azure — typowe zdarzenia paniki jądra.

Istnieje kilka innych ważnych możliwych błędów jądra, które mogą powodować brak rozruchu lub brak scenariuszy bezpiecznej powłoki (SSH).

Upewnij się, że wykonujesz wszystkie polecenia z naprawy maszyny wirtualnej w środowisku chroot zgodnie z instrukcjami w temacie Rozwiązywanie problemów w trybie offline. Jeśli system jest już uruchomiony w poprzedniej wersji jądra, te polecenia mogą być również wykonywane z oryginalnej maszyny wirtualnej przy użyciu uprawnień głównych lub sudo, zgodnie z instrukcjami w temacie Rozwiązywanie problemów online.

Ostatnie uaktualnienie jądra

Jeśli jądro nie zostanie uruchomione po ostatnim uaktualnieniu jądra, uruchom maszynę wirtualną w poprzedniej wersji jądra. Aby uzyskać więcej informacji, zobacz System rozruchowy w starszej wersji jądra.

Możesz również sprawdzić, czy istnieje już nowsza wersja jądra wydana przez dostawcę dystrybucji systemu Linux i zainstalować ją. Aby uzyskać więcej informacji na temat sposobu instalowania najnowszej wersji jądra, zobacz Proces aktualizacji jądra.

Ostatnia zmiana na starszą wersję jądra

Jeśli jądro zaczyna się po ostatniej wersji jądra, wróć do najnowszego zainstalowanego jądra. Możesz również sprawdzić, czy istnieje już nowsza wersja jądra wydana przez dostawcę dystrybucji systemu Linux i zainstalować ją. Aby uzyskać więcej informacji na temat sposobu instalowania najnowszej wersji jądra, zobacz Proces aktualizacji jądra.

Aby uruchomić system w najnowszej wersji jądra, postępuj zgodnie z instrukcjami w temacie Ręczne zmienianie domyślnej wersji jądra, ale wybierz pierwsze jądro wymienione w menu GRUB. W przypadku ręcznej modyfikacji można ustawić GRUB_DEFAULT wartość na 0 i ponownie wygenerować odpowiedni plik konfiguracji GRUB.

Zmiany modułu jądra

Może wystąpić panika jądra związana z nowym modułem jądra lub brakującym modułem jądra. Aby uzyskać szczegółowe informacje o konkretnym module jądra, który powoduje problemy (jeśli istnieją), sprawdź odpowiedni ślad paniki jądra.

Aby zweryfikować załadowane moduły jądra i wyłączone w plikach /etc/modprobe.d/*.conf , uruchom jedno z następujących poleceń:

• RHEL/CentOS/Oracle Linux 7/8

  lsinitrd /boot/initramfs-3.10.0-1160.59.1.el7.x86_64.img
  lsmod
  cat /etc/modprobe.d/*.conf
  

  Ważna

  Zastąp 3.10.0-1160.59.1.el7.x86_64 element odpowiednią wersją jądra.

• SLES 12/15

  lsinitrd /boot/initrd-5.3.18-150300.38.53-azure
  lsmod
  cat /etc/modprobe.d/*.conf
  

  Ważna

  Zastąp 5.3.18-150300.38.53-azure element odpowiednią wersją jądra.

• Ubuntu 18.04

  lsinitramfs /boot/initrd.img-5.4.0-1077-azure
  lsmod
  cat /etc/modprobe.d/*.conf
  

  Ważna

  Zastąp 5.4.0-1077-azure element odpowiednią wersją jądra.

Aby usunąć dowolny konkretny moduł jądra, uruchom następujące polecenie i w razie potrzeby ponownie wygeneruj plik initramfs .

rmmod <kernel_module_name>

Jeśli usługa systemowa używa określonego modułu jądra, wyłącz go, uruchamiając systemctl disable <serviceName> polecenie lub systemctl stop <serviceName> .

Ostatnie zmiany konfiguracji systemu operacyjnego

Zidentyfikuj wszelkie ostatnie zmiany konfiguracji jądra, które mogą powodować problemy. Aby rozwiązać problemy, dostosuj te ustawienia lub wycofaj zmiany konfiguracji.

Uruchom następujące polecenie, aby znaleźć trwałe parametry jądra skonfigurowane w dowolnym z następujących plików:

cat /etc/systctl.conf
cat /etc/sysctl.d/*

Uruchom następujące polecenie, aby przeanalizować bieżące parametry jądra i ich bieżące wartości:

sysctl -a

Uwaga

Uruchom to polecenie w uruchomionym systemie, a nie ze środowiska chroot.

Możliwe brakujące pliki

Aby uzyskać więcej informacji na temat tego rodzaju problemu, zobacz Brak ważnych plików i katalogów.

Nieprawidłowe uprawnienia do plików

Aby uzyskać więcej informacji na temat tego rodzaju problemu, zobacz Nieprawidłowe uprawnienia do pliku.

Brak partycji

Aby uzyskać więcej informacji na temat tego rodzaju problemu, zobacz Brakujące partycje.

Usterki jądra

Zidentyfikuj ten problem z poziomu konsoli szeregowej platformy Azure. Ten rodzaj problemu będzie wyglądać podobnie do następujących danych wyjściowych:

[5275698.017004] kernel BUG at XXX/YYY.c:72!
[5275698.017004] invalid opcode: 0000 [#1] SMP

Tego rodzaju panika jądra jest skojarzona z usterkami jądra lub usterkami jądra innych firm.

Aby naprawić błędy jądra, przeszukaj bazę wiedzy dostawcy przy użyciu ciągu BUG jądra i wyszukaj znane problemy w odpowiedniej wersji jądra uruchomionej przez system. Oto kilka ważnych zasobów dostawcy:

• Red Hat Kernel Oops Analyzer

  To narzędzie jest przeznaczone do diagnozowania awarii jądra. Po wprowadzeniu tekstu, vmcore-dmesg.txtlub pliku zawierającego co najmniej jeden komunikat oops jądra przeprowadzi Cię przez diagnozowanie problemu z awarią jądra.

• Red Hat baza wiedzy

  Aby uzyskać dostęp do zasobów usługi Red Hat, połącz konta platformy Microsoft Azure i usługi Red Hat. Aby uzyskać więcej informacji, zobacz How Microsoft Azure Customers Can Access the Red Hat Customer Portal (Jak klienci platformy Microsoft Azure mogą uzyskać dostęp do portalu klienta Red Hat).

• SUSE baza wiedzy

• Ubuntu baza wiedzy

Zalecamy aktualizowanie wszystkich systemów w celu wykluczenia wszelkich możliwych usterek już naprawionych w najnowszych wersjach jądra. Aby uzyskać więcej informacji, zobacz Proces aktualizacji jądra.

Jeśli wymagana jest dalsza analiza od dostawcy, skonfiguruj i włącz narzędzie kdump w celu wygenerowania zrzutu podstawowego:

• Konfiguracja Kdump na maszynach wirtualnych opartych na usłudze Red Hat.
• Konfiguracja zrzutu awaryjnego jądra na maszynach wirtualnych z systemem Ubuntu.
• Konfiguracja zrzutu rdzenia jądra na maszynach wirtualnych SLES

Proces aktualizacji jądra

Aby zainstalować najnowszą dostępną wersję jądra, uruchom jedno z następujących poleceń:

• RHEL/CentOS/Oracle Linux

  yum update kernel
  

• SLES 12/15

  zypper refresh
  zypper update kernel*
  

• Ubuntu 18.04/20.04

  apt update
  apt install linux-azure
  

Aby ponownie zainstalować określoną wersję jądra, uruchom jedno z następujących poleceń. Upewnij się, że nie masz rozruchu w tej samej wersji jądra, którą próbujesz ponownie zainstalować. Aby uzyskać więcej informacji, zobacz System rozruchowy w starszej wersji jądra.

• RHEL/CentOS/Oracle Linux

  yum reinstall kernel-3.10.0-1160.59.1.el7.x86_64
  

  Ważna

  Zastąp 3.10.0-1160.59.1.el7.x86_64 element odpowiednią wersją jądra.

• SLES 12/15

  zypper refresh
  zypper install -f kernel-azure-5.3.18-150300.38.75.1.x86_64
  

  Ważna

  Zastąp kernel-azure-5.3.18-150300.38.75.1.x86_64 element odpowiednią wersją jądra.

  • Ubuntu 18.04/20.04

    apt update
    apt install --reinstall linux-azure=5.4.0.1091.68
    

    Ważna

    Zastąp 5.4.0.1091.68 element odpowiednią wersją jądra.

Aby zaktualizować system i zastosować najnowsze dostępne zmiany, uruchom jedno z następujących poleceń:

• RHEL/CentOS/Oracle Linux

  yum update
  

• SLES 12/15

  zypper refresh
  zypper update
  

• Ubuntu 18.04/20.04

  apt update
  apt upgrade
  

Błędy jądra mogą być związane z dowolnym z następujących elementów. Aby uzyskać więcej informacji, zobacz Panika jądra w czasie wykonywania.

• Zmiany obciążenia aplikacji.
• Błędy tworzenia aplikacji lub aplikacji.
• Problemy związane z wydajnością itd.

Następne kroki

Jeśli określony błąd rozruchu nie jest problemem z rozruchem związanym z jądrem, zobacz Rozwiązywanie problemów z błędami rozruchu usługi Azure Linux Virtual Machines, aby uzyskać dalsze opcje rozwiązywania problemów.

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.