Maszyna wirtualna z systemem Linux uruchamia się w trybie ratunkowym GRUB

Dotyczy: ✔️ maszyny wirtualne z systemem Linux

Uwaga 16.

CentOS, do których odwołuje się ten artykuł, jest dystrybucją systemu Linux i osiągnie koniec życia (EOL). Rozważ odpowiednie użycie i zaplanuj. Aby uzyskać więcej informacji, zobacz CentOS End Of Life guidance (Wskazówki dotyczące zakończenia życia systemu CentOS).

W tym artykule omówiono wiele warunków, które powodują problemy z ratunkami GRUB i zawierają wskazówki dotyczące rozwiązywania problemów.

Podczas procesu rozruchu moduł ładujący rozruchu próbuje zlokalizować jądro systemu Linux i przekazać kontrolkę rozruchu. Jeśli nie można wykonać tego przekazywania, maszyna wirtualna wchodzi w konsolę ratunkową GRUB. Monit konsoli ratowniczej GRUB nie jest wyświetlany w dzienniku konsoli szeregowej platformy Azure, ale można go wyświetlić na zrzucie ekranu diagnostyki rozruchu platformy Azure.

Identyfikowanie problemu z ratowaniem w trybie GRUB

Wyświetl zrzut ekranu przedstawiający diagnostykę rozruchu na stronie Diagnostyka rozruchu maszyny wirtualnej w witrynie Azure Portal. Ten zrzut ekranu pomaga zdiagnozować problem z ratowaniem programu GRUB i ustalić, czy przyczyną problemu jest błąd rozruchu.

Poniższy tekst jest przykładem problemu ratowniczego GRUB:

error: file '/boot/grub2/i386-pc/normal.mod' not found.  
Entering rescue mode...  
grub rescue>

Rozwiązywanie problemu z ratunkiem GRUB w trybie offline

1. Aby rozwiązać problem z ratunkiem GRUB, wymagana jest maszyna wirtualna ratownicza/naprawa. Użyj poleceń naprawy maszyny wirtualnej, aby utworzyć maszynę wirtualną naprawy, która ma kopię dołączonego dysku systemu operacyjnego maszyny wirtualnej, której dotyczy problem. Zainstaluj kopię systemów plików systemu operacyjnego na maszynie wirtualnej naprawy przy użyciu katalogu chroot.

   Uwaga 16.

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

2. Zidentyfikuj problem z ratunkiem GRUB. W przypadku napotkania jednego z następujących problemów ratowniczych GRUB przejdź do odpowiedniej sekcji, aby rozwiązać ten problem:

   • Błąd: nieznany system plików
   • Błąd 15: Nie znaleziono pliku
   • Błąd: nie znaleziono pliku "/boot/grub2/i386-pc/normal.mod"
   • Błąd: brak takiej partycji
   • Błąd: nie znaleziono symbolu "grub_efi_get_secure_boot"
   • Inne błędy ratownictwa GRUB

3. Po rozwiązaniu problemu ratowniczego GRUB wykonaj następujące czynności:

   1. Odinstalowywanie kopii systemów plików z maszyny wirtualnej ratownictwa/naprawy.

   2. 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 temacie Naprawianie maszyny wirtualnej z systemem Linux przy użyciu poleceń naprawy maszyny wirtualnej platformy Azure.

   3. Sprawdź, czy maszyna wirtualna może zacząć od zapoznania się z konsolą szeregową platformy Azure, czy też próbuje nawiązać połączenie z maszyną wirtualną.

4. Jeśli 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 Jak przywrócić dane maszyny wirtualnej platformy Azure w witrynie Azure Portal.

Zapoznaj się z poniższymi sekcjami, aby zapoznać się ze szczegółowymi błędami, możliwymi przyczynami i rozwiązaniami.

Uwaga 16.

W poleceniach wymienionych w poniższych sekcjach zastąp /dev/sdX element odpowiednim urządzeniem dysku systemu operacyjnego .

Zainstaluj ponownie program GRUB i ponownie wygeneruj plik konfiguracji GRUB przy użyciu funkcji automatycznej naprawy systemu Linux platformy Azure

Skrypty automatycznej naprawy systemu Linux (ALAR) platformy Azure są częścią rozszerzenia naprawy maszyny wirtualnej opisanego w artykule Używanie usługi Azure Linux Auto Repair (ALAR) w celu naprawienia maszyny wirtualnej z systemem Linux. Usługa ALAR obejmuje automatyzację wielu scenariuszy naprawy, w tym problemy ratownicze GRUB.

Skrypty usługi ALAR używają rozszerzenia repair-button naprawy, aby rozwiązać problemy z programem GRUB, określając --button-command grubfix maszyny wirtualne generacji 1 lub --button-command efifix maszyny wirtualne generacji 2. Ten parametr wyzwala automatyczne odzyskiwanie. Zaimplementuj następujące polecenia, aby zautomatyzować poprawkę typowych błędów GRUB przez ponowne zainstalowanie programu GRUB i ponowne wygenerowanie odpowiedniego pliku konfiguracji:

• Maszyny wirtualne z systemem Linux bez interfejsu UEFI (oparte na systemie BIOS — Gen1):

  az extension add -n vm-repair
  az extension update -n vm-repair
  az vm repair repair-button --button-command 'grubfix' --verbose $RGNAME --name $VMNAME
  

• Maszyny wirtualne z systemem Linux z interfejsem UEFI (Gen2):

  az extension add -n vm-repair
  az extension update -n vm-repair
  az vm repair repair-button --button-command 'efifix' --verbose $RGNAME --name $VMNAME
  

Ważne

Zastąp odpowiednio nazwę $RGNAME grupy zasobów i nazwę $VMNAME maszyny wirtualnej.

Skrypt naprawy maszyny wirtualnej w połączeniu ze skryptem ALAR tymczasowo tworzy grupę zasobów, maszynę wirtualną naprawy i kopię dysku systemu operacyjnego maszyny wirtualnej, której dotyczy problem. Ponownie instaluje program GRUB, ponownie generuje odpowiedni plik konfiguracji GRUB, a następnie zamienia uszkodzony dysk systemu operacyjnego maszyny wirtualnej na skopiowany dysk stały. repair-button Na koniec skrypt automatycznie usuwa grupę zasobów zawierającą tymczasową maszynę wirtualną naprawy.

Zainstaluj ponownie program GRUB i ponownie wygeneruj ręcznie plik konfiguracji GRUB

1. Sprawdź, czy utworzono maszynę wirtualną ratownictwa/naprawy. Jeśli nie został utworzony, wykonaj krok 1 w temacie Rozwiązywanie problemów z ratowaniem programu GRUB w trybie offline , aby utworzyć maszynę wirtualną. Zainstaluj wszystkie wymagane systemy plików, w tym / i /boot na maszynie wirtualnej ratownictwa/naprawy, a następnie wprowadź środowisko chroot .

2. Zainstaluj ponownie program GRUB i ponownie wygeneruj odpowiedni plik konfiguracji GRUB przy użyciu jednego z następujących poleceń:

   • RHEL/CentOS/Oracle 7.x/8.x/9.x Maszyny wirtualne z systemem Linux bez interfejsu UEFI (z systemem BIOS — Gen1)

     grub2-install /dev/sdX
     grub2-mkconfig -o /boot/grub2/grub.cfg
     sed -i 's/hd2/hd0/g' /boot/grub2/grub.cfg
     

   • RHEL/CentOS/Oracle 7.x/8.x/9.x Maszyny wirtualne z systemem Linux z interfejsem UEFI (Gen2)

     yum reinstall grub2-efi-x64 shim-x64
     grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
     sed -i 's/hd2/hd0/g' /boot/efi/EFI/redhat/grub.cfg
     

     Jeśli maszyna wirtualna korzysta z systemu CentOS, zastąp ciąg ciągiem centos w ścieżce bezwzględnej pliku grub.cfg /boot/efi/EFI/centos/grub.cfgredhat.

   • SLES 12/15 Gen1 i Gen2

     grub2-install /dev/sdX
     grub2-mkconfig -o /boot/grub2/grub.cfg
     sed -i 's/hd2/hd0/g' /boot/grub2/grub.cfg
     

   • Ubuntu Gen1 i Gen2

     grub-install /dev/sdX
     update-grub
     

3. Przejdź do kroku 3 w temacie Rozwiązywanie problemu z ratowaniem programu GRUB w trybie offline , aby zamienić dysk systemu operacyjnego.

Błąd: nieznany system plików

Poniższy zrzut ekranu przedstawia komunikat o błędzie:

Ten błąd może być skojarzony z jednym z następujących problemów:

• /boot uszkodzenie systemu plików.

  Aby rozwiązać ten problem, wykonaj kroki opisane w temacie Naprawianie uszkodzenia systemu plików /boot.

• Moduł ładujący rozruchu GRUB wskazuje na nieprawidłowy dysk lub partycję.

  Aby rozwiązać ten problem, zainstaluj ponownie program GRUB i ponownie wygeneruj plik konfiguracji GRUB ręcznie.

• Problemy z tabelą partycji dysku systemu operacyjnego spowodowane przez błąd człowieka.

  Aby rozwiązać takie problemy, wykonaj kroki opisane w temacie Błąd: nie ma takiej partycji, aby ponownie utworzyć partycję/boot, jeśli brakuje lub utworzono niepoprawnie.

Naprawianie uszkodzenia systemu plików /boot

Aby naprawić /boot uszkodzenie systemu plików, wykonaj następujące kroki:

1. Sprawdź, czy utworzono maszynę wirtualną ratownictwa/naprawy. Jeśli nie został utworzony, wykonaj krok 1 w temacie Rozwiązywanie problemów z ratowaniem programu GRUB w trybie offline , aby utworzyć maszynę wirtualną.

2. Zapoznaj się z artykułem Rozwiązywanie problemów z uszkodzeniem systemu plików w systemie Azure Linux , aby rozwiązać problemy z uszkodzeniem w odpowiedniej /boot partycji.

3. Przejdź do kroku 3 w temacie Rozwiązywanie problemu z ratowaniem programu GRUB w trybie offline , aby zamienić dysk systemu operacyjnego.

Błąd 15: Nie znaleziono pliku

Poniższy zrzut ekranu przedstawia komunikat o błędzie:

Aby rozwiązać ten problem, wykonaj podane dalej czynności.

1. Sprawdź, czy utworzono maszynę wirtualną ratownictwa/naprawy. Jeśli nie został utworzony, wykonaj krok 1 w temacie Rozwiązywanie problemów z ratowaniem programu GRUB w trybie offline , aby utworzyć maszynę wirtualną. Zainstaluj wszystkie wymagane systemy plików, w tym / i /boot na maszynie wirtualnej ratownictwa/naprawy, a następnie wprowadź środowisko chroot .

2. /boot Sprawdź zawartość systemu plików i ustal, czego brakuje.

3. Jeśli brakuje pliku konfiguracji GRUB, zainstaluj ponownie program GRUB i ponownie wygeneruj plik konfiguracji GRUB ręcznie.

4. Sprawdź, czy uprawnienia do plików w /boot systemie plików są ok. Uprawnienia można porównać przy użyciu innej maszyny wirtualnej z tą samą wersją systemu Linux.

5. Jeśli brakuje całej partycji /boot 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 Jak przywrócić dane maszyny wirtualnej platformy Azure w witrynie Azure Portal.

6. Po rozwiązaniu problemu przejdź do kroku 3 w temacie Rozwiązywanie problemu z ratowaniem programu GRUB w trybie offline , aby zamienić dysk systemu operacyjnego.

Błąd: nie znaleziono pliku "/boot/grub2/i386-pc/normal.mod"

Poniższy zrzut ekranu przedstawia komunikat o błędzie:

1. Sprawdź, czy utworzono maszynę wirtualną ratownictwa/naprawy. Jeśli nie został utworzony, wykonaj krok 1 w temacie Rozwiązywanie problemu z ratowaniem programu GRUB w trybie offline , aby go utworzyć. Zainstaluj wszystkie wymagane systemy plików, w tym / i /boot na maszynie wirtualnej ratownictwa/naprawy, a następnie wprowadź środowisko chroot .

2. Jeśli nie możesz zainstalować /boot systemu plików z powodu błędu uszkodzenia, usuń uszkodzenie systemu plików /boot.

3. Jeśli znajdujesz się wewnątrz katalogu chroot, sprawdź zawartość w /boot/grub2/i386-pc katalogu. Jeśli brakuje zawartości, skopiuj zawartość z pliku /usr/lib/grub/i386-pc. W tym celu użyj następujących poleceń:

   ls -l /boot/grub2/i386-pc
   cp -rp /usr/lib/grub/i386-pc /boot/grub2
   

4. Jeśli zawartość /boot partycji jest pusta, użyj następujących poleceń, aby go ponownie utworzyć:

   Uwaga 16.

   Poniższe kroki dotyczą maszyn wirtualnych Z systemem Linux RHEL/CentOS/Oracle 7.x/8.x bez interfejsu UEFI (z systemem BIOS — Gen1).

   1. W ramach procesu chroot zainstaluj ponownie plik grub. Zastąp /dev/sd[X] odpowiednio odpowiednią kopią dysku systemu operacyjnego dołączonego do maszyny wirtualnej naprawy/ratownictwa:

      grub2-install /dev/sd[X]
      

   2. Upewnij się, że /etc/resolv.conf istnieje prawidłowy wpis DNS, aby rozpoznać nazwę repozytorium:

      cat /etc/resolv.conf
      

   3. Zainstaluj ponownie jądro:

      yum reinstall $(rpm -qa | grep -i kernel)
      

   4. grub.cfg Utwórz plik:

      grub2-mkconfig -o /boot/grub2/grub.cfg
      sed -i 's/hd2/hd0/g' /boot/grub2/grub.cfg
      

5. Przejdź do kroku 3 w temacie Rozwiązywanie problemów z ratowaniem programu GRUB w trybie offline , aby zamienić dysk systemu operacyjnego.

Błąd: brak takiej partycji

Poniższy zrzut ekranu przedstawia komunikat o błędzie:

Ten błąd występuje na maszynie wirtualnej opartej na systemie RHEL (Red Hat, Oracle Linux, CentOS) w jednym z następujących scenariuszy:

• Partycja /boot jest usuwana przez pomyłkę.
• Partycja zostanie ponownie utworzona /boot przy użyciu nieprawidłowych sektorów początkowych i końcowych.

Rozwiązanie: Utwórz ponownie /boot partition

/boot Jeśli brakuje partycji, utwórz ją ponownie, wykonując następujące kroki:

1. Sprawdź, czy utworzono maszynę wirtualną ratownictwa/naprawy. Jeśli nie został utworzony, wykonaj krok 1 w temacie Rozwiązywanie problemów z ratowaniem programu GRUB w trybie offline , aby utworzyć maszynę wirtualną.

2. Zidentyfikuj, czy tabela partycji jest tworzona jako typ dos lub GPT , używając następującego polecenia:

   sudo fdisk -l /dev/sdX
   

   • Tabela partycji dos

     

   • Tabela partycji GPT

     

3. Jeśli tabela partycji ma wartość dos jako typ tabeli partycji, utwórz ponownie partycję /boot w systemach dos. Jeśli tabela partycji ma GPT jako typ tabeli partycji, utwórz ponownie /boot partition w systemach GPT.

4. Upewnij się, że moduł ładujący rozruchu GRUB jest zainstalowany przy użyciu odpowiedniego dysku. Aby ręcznie zainstalować i skonfigurować plik konfiguracji GRUB, możesz wykonać kroki opisane w temacie Ponowne instalowanie i ponowne generowanie pliku konfiguracji GRUB.

5. Przejdź do kroku 3 w temacie Rozwiązywanie problemów z ratowaniem programu GRUB w trybie offline , aby zamienić dysk systemu operacyjnego.

Utwórz ponownie partycję /boot w systemach dos

1. Utwórz ponownie partycję /boot na podstawie maszyny wirtualnej ratowniczej/naprawy przy użyciu następującego polecenia:

   sudo fdisk /dev/sdX
   

   Użyj wartości domyślnych w sektorach First i Last oraz typ partycji (83). Upewnij się, że /boot tabela partycji jest oznaczona jako rozruchowa przy użyciu a opcji w narzędziu fdisk , jak pokazano w następujących danych wyjściowych:

   sudo fdisk /dev/sdc
   
   The device presents a logical sector size that is smaller than
   the physical sector size. Aligning to a physical sector (or optimal
   I/O) size boundary is recommended, or performance may be impacted.
   Welcome to fdisk (util-linux 2.23.2).
   
   Changes will remain in memory only, until you decide to write them.
   Be careful before using the write command.
   
   Command (m for help): n
   Partition type:
      p   primary (1 primary, 0 extended, 3 free)
      e   extended
   Select (default p): p
   Partition number (1,3,4, default 1): 1
   First sector (2048-134217727, default 2048):
   Using default value 2048
   Last sector, +sectors or +size{K,M,G} (2048-2099199, default 2099199):
   Using default value 2099199
   Partition 1 of type Linux and of size 1 GiB is set
   
   Command (m for help): t
   Partition number (1,2, default 2): 1
   Hex code (type L to list all codes): 83
   Changed type of partition 'Linux' to 'Linux'
   
   Command (m for help): a
   Partition number (1,2, default 2): 1
   
   Command (m for help): p
   
   Disk /dev/sdc: 68.7 GB, 68719476736 bytes, 134217728 sectors
   Units = sectors of 1 * 512 = 512 bytes
   Sector size (logical/physical): 512 bytes / 4096 bytes
   I/O size (minimum/optimal): 4096 bytes / 4096 bytes
   Disk label type: dos
   Disk identifier: 0x000b7179
   
   Device Boot      Start         End      Blocks   Id  System
   /dev/sdc1   *        2048     2099199     1048576   83  Linux
   /dev/sdc2         2099200   134217727    66059264   8e  Linux LVM
   
   Command (m for help): w
   The partition table has been altered!
   
   Calling ioctl() to re-read partition table.
   

2. Po ponownym utworzeniu brakującej /boot partycji sprawdź, czy /boot system plików został wykryty. Powinien być widoczny wpis dla /dev/sdX1 elementu (brakująca partycja /boot).

   sudo blkid /dev/sdX1
   

   sudo blkid /dev/sdc1
   /dev/sdc1: UUID="<UUID>" TYPE="ext4"
   

3. /boot Jeśli system plików nie jest widoczny blkid po ponownym utworzeniu partycji, oznacza to, że /boot dane już nie istnieją. Należy ponownie utworzyć /boot system plików (przy użyciu tego samego formatu UUID i systemu plików, który znajduje się we wpisie /etc/fstab/boot ), a następnie przywrócić jego zawartość z kopii zapasowej.

Ponowne tworzenie partycji /boot w systemach GPT

1. Utwórz ponownie partycję /boot na podstawie maszyny wirtualnej ratowniczej/naprawy przy użyciu następującego polecenia:

   sudo gdisk /dev/sdX
   

   Użyj wartości domyślnych w sektorach First i Last oraz typ partycji (8300), jak pokazano w następujących danych wyjściowych:

   sudo gdisk /dev/sdc
   GPT fdisk (gdisk) version 1.0.3
   
   Partition table scan:
     MBR: protective
     BSD: not present
     APM: not present
     GPT: present
   
   Found valid GPT with protective MBR; using GPT.
   
   Command (? for help): n
   Partition number (1-128, default 1): 1
   First sector (34-134217694, default = 1026048) or {+-}size{KMGTP}:
   Last sector (1026048-2050047, default = 2050047) or {+-}size{KMGTP}:
   Current type is 'Linux filesystem'
   Hex code or GUID (L to show codes, Enter = 8300):
   Changed type of partition to 'Linux filesystem'
   
   Command (? for help): p
   Disk /dev/sdc: 134217728 sectors, 64.0 GiB
   Model: Virtual Disk
   Sector size (logical/physical): 512/4096 bytes
   Disk identifier (GUID): 6D915856-445A-4513-97E4-C55F2E1AD6C0
   Partition table holds up to 128 entries
   Main partition table begins at sector 2 and ends at sector 33
   First usable sector is 34, last usable sector is 134217694
   Partitions will be aligned on 2048-sector boundaries
   Total free space is 6076 sectors (3.0 MiB)
   
   Number  Start (sector)    End (sector)  Size       Code  Name
      1         1026048         2050047   500.0 MiB   8300  Linux filesystem
      2         2050048       134215679   63.0 GiB    8E00
     14            2048           10239   4.0 MiB     EF02
     15           10240         1024000   495.0 MiB   EF00  EFI System Partition
   
   Command (? for help): w
   
   Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
   PARTITIONS!!
   
   Do you want to proceed? (Y/N): Y
   OK; writing new GUID partition table (GPT) to /dev/sdc.
   Warning: The kernel is still using the old partition table.
   The new table will be used at the next reboot or after you
   run partprobe(8) or kpartx(8)
   The operation has completed successfully.
   

2. Sprawdź, czy /boot system plików jest wykrywany przez system, używając następującego polecenia:

   sudo blkid /dev/sdX1
   

   Powinien być widoczny wpis ( /dev/sdX1 brakująca /boot partycja).

   sudo blkid /dev/sdc1
   /dev/sdc1: UUID="<UUID>" BLOCK_SIZE="4096" TYPE="xfs" PARTLABEL="Linux filesystem" PARTUUID="<PARTUUID>"
   

3. /boot Jeśli system plików nie jest widoczny po ponownym utworzeniu partycji, oznacza to, że /boot dane już nie istnieją. Musisz ponownie utworzyć /boot system plików (przy użyciu tego samego identyfikatora UUID, który znajduje się we wpisie /etc/fstab/boot ), a następnie przywrócić jego zawartość z kopii zapasowej.

Błąd: nie znaleziono symbolu "grub_efi_get_secure_boot"

Poniższy zrzut ekranu przedstawia komunikat o błędzie:

Jądra systemu Linux w wersji 4.12.14 (używanej w systemie SLES 12 SP5) nie obsługuje opcji Bezpiecznego rozruchu . W związku z tym jeśli bezpieczny rozruch jest włączony podczas wdrażania maszyny wirtualnej (czyli pole Typ zabezpieczeń jest ustawione na zaufane maszyny wirtualne uruchamiania), maszyna wirtualna generuje błąd bezpiecznego rozruchu za pośrednictwem konsoli podczas próby uruchomienia przy użyciu tej wersji jądra SUSE na obrazie maszyny wirtualnej Gen2.

Rozwiązanie

Aby rozwiązać problem z błędem rozruchu, wykonaj następujące kroki:

1. Sprawdź, czy utworzono maszynę wirtualną ratownictwa/naprawy. Jeśli nie został utworzony, wykonaj krok 1 w temacie Rozwiązywanie problemów z ratowaniem programu GRUB w trybie offline , aby utworzyć maszynę wirtualną. Zainstaluj wszystkie wymagane systemy plików, w tym / i /boot, a następnie wprowadź środowisko chroot .

2. Uruchom następujące polecenie YaST w środowisku chroot:

   yast2 bootloader
   

3. Wyczyść opcję "x" z opcji Włącz obsługę bezpiecznego rozruchu, a następnie wybierz F10 , aby zapisać zmianę.

   

4. Wykonaj krok 3 w temacie Rozwiązywanie problemów z ratowaniem programu GRUB w trybie offline , aby zamienić dysk systemu operacyjnego.

Inne błędy ratownictwa GRUB

Poniższy zrzut ekranu przedstawia komunikat o błędzie:

Ten rodzaj błędu jest wyzwalany w jednym z następujących scenariuszy:

• Brak pliku konfiguracji GRUB.
• Użyto nieprawidłowej konfiguracji GRUB.
• Brak /boot partycji lub jej zawartości.

Aby rozwiązać ten problem, wykonaj następujące czynności:

1. Sprawdź, czy utworzono maszynę wirtualną ratownictwa/naprawy. Jeśli nie został utworzony, wykonaj krok 1 w temacie Rozwiązywanie problemów z ratowaniem programu GRUB w trybie offline , aby utworzyć maszynę wirtualną. Zainstaluj wszystkie wymagane systemy plików, w tym / i /boot, a następnie wprowadź środowisko chroot .

2. Upewnij się, że /etc/default/grub plik konfiguracji został skonfigurowany. Zatwierdzone obrazy systemu Linux platformy Azure mają już wymagane konfiguracje. Aby uzyskać więcej informacji, zapoznaj się z następującymi artykułami:

   • Dostęp GRUB w systemie RHEL
   • Dostęp GRUB w systemie CentOS
   • Dostęp GRUB w systemie Ubuntu
   • Dostęp GRUB w systemie SUSE SLES
   • Dostęp GRUB w systemie Oracle Linux

3. Zainstaluj ponownie program GRUB i ponownie wygeneruj plik konfiguracji GRUB ręcznie.

   Uwaga 16.

   Jeśli brakuje pliku to /boot/grub/menu.lst, ten błąd dotyczy starszych wersji systemu operacyjnego (RHEL 6.x, Centos 6.x i Ubuntu 14.04). Polecenia będą się różnić, ponieważ w tych systemach jest używana wersja GRUB 1. W tym artykule nie opisano wersji GRUB 1.

4. Jeśli brakuje całej /boot partycji, wykonaj kroki opisane w temacie Błąd: brak takiej partycji.

5. Po rozwiązaniu problemu przejdź do kroku 3 w temacie Rozwiązywanie problemu z ratowaniem programu GRUB w trybie offline , aby zamienić dysk systemu operacyjnego.

Następne kroki

Jeśli konkretny błąd rozruchu nie jest problemem ratunkowym GRUB, zapoznaj się z artykułem Rozwiązywanie problemów z błędami rozruchu maszyn wirtualnych z systemem Linux na platformie Azure, aby uzyskać dalsze opcje rozwiązywania problemów.

Zastrzeżenie dotyczące innych firm

Produkty innych firm omówione w tym artykule są wytwarzane przez producentów niezależnych od firmy Microsoft. Firma Microsoft nie udziela żadnych gwarancji, dorozumianych ani żadnego innego rodzaju, w odniesieniu do wydajności lub niezawodności tych produktów.

Wyłączenie odpowiedzialności za kontakty z osobami trzecimi

Firma Microsoft udostępnia informacje dotyczące sposobu kontaktowania się z innymi firmami, aby ułatwić uzyskanie dodatkowych informacji w tym temacie. Informacje te mogą zostać zmienione bez powiadomienia. Firma Microsoft nie gwarantuje, że informacje dotyczące innych firm są prawidłowe.

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 na temat platformy Azure.