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

Dotyczy: ✔️ maszyny wirtualne z systemem Linux

Uwaga

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

   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 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.

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

Uwaga

W poleceniach wymienionych w poniższych sekcjach zastąp /dev/sdX element odpowiednim urządzeniem dysku 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:

• Uszkodzenie systemu plików /boot.

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

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

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

• 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 z zaleceniami dotyczącymi ponownego utworzenia partycji /boot, jeśli brakuje lub utworzono niepoprawnie.

Naprawianie uszkodzenia systemu plików /boot

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 Linux na platformie Azure, aby rozwiązać problemy z uszkodzeniem w odpowiedniej partycji /boot.

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

Zainstaluj ponownie program GRUB i ponownie wygeneruj 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 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 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 18.04/20.04

     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 15: Nie znaleziono pliku

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

Aby rozwiązać ten problem, wykonaj poniższe 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. Sprawdź zawartość systemu plików /boot i ustal, czego brakuje.

3. Jeśli brakuje pliku konfiguracji GRUB, zainstaluj ponownie plik konfiguracji GRUB i ponownie wygeneruj plik konfiguracji GRUB.

4. Sprawdź, czy uprawnienia do pliku w systemie plików /boot 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ć systemu plików /boot z powodu błędu uszkodzenia, usuń uszkodzenie systemu plików /boot.

3. Jeśli znajdujesz się wewnątrz katalogu chroot, sprawdź zawartość w katalogu /boot/grub2/i386-pc . 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

   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. Utwórz plik grub.cfg:

      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 /boot jest ponownie tworzona przy użyciu nieprawidłowych sektorów startowych i końcowych.

Rozwiązanie: Utwórz ponownie /boot partition

Jeśli brakuje partycji /boot, 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. Możesz wykonać kroki opisane w temacie Ponowne instalowanie pliku konfiguracji GRUB i ponowne generowanie pliku konfiguracji GRUB, aby go zainstalować i skonfigurować.

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 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 tabela partycji /boot 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 partycji /boot sprawdź, czy system plików /boot 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. Jeśli system plików /boot nie jest widoczny blkid po ponownym utworzeniu partycji, oznacza to, że dane /boot już nie istnieją. Należy ponownie utworzyć system plików /boot (przy użyciu tego samego UUID i formatu systemu plików, który znajduje się w /etc/fstab /boot entry), a następnie przywrócić jego zawartość z kopii zapasowej.

Ponowne tworzenie partycji /boot w systemach GPT

1. Utwórz ponownie partycję /boot 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 system plików /boot jest wykrywany przez system przy użyciu następującego polecenia:

   sudo blkid /dev/sdX1
   

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

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

3. Jeśli system plików /boot nie jest widoczny po ponownym utworzeniu partycji, oznacza to, że dane /boot już nie istnieją. Należy ponownie utworzyć system plików /boot (przy użyciu tego samego identyfikatora UUID, który znajduje się w /etc/fstab /boot entry), 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 partycji /boot lub jego zawartości.

Aby rozwiązać ten problem, 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. Upewnij się, że plik konfiguracji /etc/default/grub jest skonfigurowany. Zatwierdzone obrazy systemu Linux platformy Azure mają już wymagane konfiguracje. Aby uzyskać więcej informacji, zobacz następujące artykuły:

   • 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.

   Uwaga

   Jeśli brakujący plik 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 partycji /boot, 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.

Zastrzeżenie dotyczące kontaktu innej firmy

Firma Microsoft udostępnia informacje kontaktowe innych firm, aby uzyskać dodatkowe informacje na temat tego tematu. Te informacje kontaktowe mogą ulec zmianie bez powiadomienia. Firma Microsoft nie gwarantuje dokładności informacji kontaktowych innych firm.

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.