Share via

套用核心變更之後，Azure Linux 虛擬機無法開機

  • 發行項

注意事項

本文中參考的 CentOS 是 Linux 發行版，並會到達生命周期結束 (EOL) 。 請考慮您的使用並據以規劃。 如需詳細資訊，請 參閱 CentOS 生命週期結束指引。

本文提供Linux虛擬機 (VM) 在套用核心變更後無法開機的問題解決方案。

先決條件

請確定 序列主控台 已在Linux VM 中啟用並正常運作。

如何識別核心相關開機問題

若要識別與核心相關的開機問題，請檢查特定的核心異常字串。 若要這樣做，請使用 Azure CLI 或 Azure 入口網站，在開機診斷窗格或序列控制檯窗格中檢視 VM 的序列控制台記錄輸出。

核心異常看起來像下列輸出，並會顯示在序列控制台記錄的結尾：

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

在線疑難解答

提示

如果您有 VM 的最新備份，請 從備份還原 VM 以修正開機問題。

序列主控台是解決開機問題最快的方法。 它可讓您直接修正問題，而不需要將系統磁碟呈現至復原 VM。 請確定您符合散發所需的必要條件。 如需詳細資訊，請參閱 適用於Linux的虛擬機序列主控台。

  1. 識別特定的核心相關開機問題。

  2. 使用 Azure 序列主控台 在 GRUB 功能表中斷您的 VM，並選取任何先前的核心來啟動它。 如需詳細資訊，請參閱 舊版核心版本的開機系統。

  3. 移至對應的區段，以解決特定的核心相關開機問題：

  4. 解決核心相關開機問題之後，請重新啟動 VM，以便透過最新的核心版本開機。

離線疑難解答

提示

如果您有 VM 的最新備份，請 從備份還原 VM 以修正開機問題。

如果 Azure 序列控制台 無法在特定 VM 中運作，或不是您訂用帳戶中的選項，請使用修復/修復 VM 對開機問題進行疑難解答。 如果要執行這項操作，請依照下列步驟執行：

  1. 使用 vm repair 命令 來建立已鏈接受影響 VM OS 磁碟復本的修復 VM。 使用 chroot 在修復 VM 中掛接 OS 檔案系統的複本。

    注意事項

    或者，您可以使用 Azure 入口網站 手動建立救援 VM。 如需詳細資訊，請參閱使用 Azure 入口網站 將 OS 磁碟連結至復原 VM，以針對 Linux VM 進行疑難解答。

  2. 識別特定的核心相關開機問題。

  3. 移至對應的區段，以解決特定的核心相關開機問題：

  4. 解決核心相關開機問題之後，請執行下列動作：

    1. 結束 chroot。
    2. 從修復/修復 VM 卸除文件系統的複本。
    3. az vm repair restore執行 命令，將修復的OS磁碟與VM的原始OS磁碟交換。 如需詳細資訊，請參閱 使用 Azure 虛擬機修復命令修復 Linux VM 中的步驟 5。
    4. 查看 Azure 序列主控台或嘗試連線到 VM，以驗證 VM 是否能夠開機。

  5. 如果有重要的核心相關內容、遺漏整個 /boot 分割區或其他重要內容，而且無法復原，建議您從備份還原 VM。 如需詳細資訊，請參閱如何在 Azure 入口網站 中還原 Azure VM 數據。

舊版核心版本上的開機系統

使用 Azure 序列主控台

  1. 使用 Azure 序列主控台重新啟動 VM。

    1. 選取序列主控台視窗頂端的 [關機 ] 按鈕。
    2. 選取 [ 重新啟動 VM (硬) ] 選項。

  2. 序列主控台連線繼續後，您會在序列控制台視窗的左上角看到倒數計數器。 按 下ESCAPE 鍵，在 GRUB 功能表中中斷您的 VM。

  3. 按下箭號鍵以選取任何先前的核心版本。

    動畫 GIF，顯示在 GRUB 功能表層級中斷開機程式的程式，以選取要開機系統的較舊核心。

  4. GRUB_DEFAULT依照手動變更預設核心版本中的指示，變更 /etc/default/grub 檔案中的變數。 這是持續性的變更。

注意事項

如果 GRUB 功能表中只列出一個核心版本，請遵循 離線疑難解答 方法，從修復 VM 針對此問題進行疑難解答。

使用修復 VM (ALAR 腳本)

  1. 在 Azure Cloud Shell 中執行下列 bash 命令，以建立修復 VM。 如需詳細資訊，請 參閱使用 Azure Linux 自動修復 (ALAR) 來修正 Linux VM - 核心選項。

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

  2. 執行下列命令，以先前安裝的版本取代中斷的核心：

    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

注意事項

如果系統中只安裝一個核心版本，請遵循 脫機疑難解答 方法，從修復 VM 針對此問題進行疑難解答。

手動變更預設核心版本

若要從 chroot) 或執行中 VM 內的修復 VM (修改預設核心版本，請遵循下列步驟：

注意事項

如果核心降級復原已完成，請選取最新的核心版本，而不是較舊的核心版本。

  • RHEL 7、Oracle Linux 7 和 CentOS 7

    1. 執行下列其中一個命令，以驗證 GRUB 組態檔中可用的核心清單：

      • Gen1 VM：

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

      • Gen2 VM：

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

    2. 執行下列命令，設定新的預設核心並指定對應的核心標題：

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

      注意事項

      將取代 Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64 為對應的功能表項標題。

    3. 執行下列命令，以驗證新的預設核心是否為所需的核心：

      grub2-editenv list

    4. 請確定 /etc/default/grub 檔案中的變數值GRUB_DEFAULT已設定為 saved。 若要加以修改，請務必 重新產生 GRUB 組態檔 以套用變更。

  • RHEL 8/9 和 CentOS 8

    1. 執行下列命令來列出可用的核心：

      ls -l /boot/vmlinuz-*

    2. 執行下列命令來設定新的預設核心：

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

      注意事項

      將取代 4.18.0-372.19.1.el8_6.x86_64 為對應的核心版本。

    3. 執行下列命令，以驗證新的預設核心是否為所需的核心：

      grubby --default-kernel

  • SLES 12/15、Ubuntu 18.04/20.04

    1. 執行下列命令，列出 GRUB 組態檔中可用的核心：

      • Gen1 VM：

        • SLES 12/15：

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

        • Ubuntu 18.04/20.04：

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

      • Gen2 VM：

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

    2. 修改 /etc/default/grub 檔案中變數的GRUB_DEFAULT值，以設定新的預設核心。 針對系統中安裝的最新核心版本，預設值為 0。 下一個可用的核心設定為 「1>2」。

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

      注意事項

      如需如何設定變數的 GRUB_DEFAULT 詳細資訊，請參閱 SUSE 開機載入器 GRUB2 和 Ubuntu Grub2/安裝程式。 作為參考：最上層 menuentry 值為 0，第一個最上層子功能表值為 1，而每個巢狀功能表項值的開頭為 0。 例如，“1>2” 是第一個子功能表中的第三個功能表。

    3. 重新產生 GRUB 組態檔以套用變更。 請遵循 重新安裝 GRUB 中的 指示，針對對應的 Linux 發行版和 VM 產生重新產生 GRUB 組態檔。

核心異常 - 未同步：VFS：無法在未知區塊上掛接根 fs (0,0)

此錯誤的發生原因是最近 (核心) 的系統更新。 它最常出現在 RHEL 型散發套件中。 您可以 從 Azure 序列主控台識別此問題。 您會看到下列任一錯誤訊息：

  1. 「核心異常 - 未同步處理：VFS：無法在未知的區塊上掛接根 fs (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”

    錯誤：找不到檔案 '/initramfs-3.10.0-1160.36.2.el7.x86_64.img'。

這種錯誤表示未產生 initramfs 檔案、GRUB 組態檔在修補程式之後遺漏 initrd 專案，或 GRUB 手動設定錯誤。

重新啟動伺服器之前，建議您執行下列其中一個命令，以驗證有核心更新的 GRUB 設定和 /boot 內容。 請務必確保更新已完成，而且不會遺失 initramfs 檔案。

  • BIOS 型 - Gen1 系統

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

  • UEFI 型 - Gen2 系統

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

使用 Azure 修復 VM ALAR 腳本重新產生遺漏的 initramfs

  1. 使用 Azure Cloud Shell 執行下列 Bash 命令行來建立修復 VM。 如需詳細資訊，請 參閱使用 Azure Linux 自動修復 (ALAR) 來修正 Linux VM - initrd 選項。

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

  2. 重新產生 initrd/initramfs 映射，並在遺漏 initrd 專案時重新產生 GRUB 組態檔。 若要執行此動作，請執行下列命令：

    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. 執行還原命令之後，請重新啟動原始 VM，並驗證它是否能夠開機。

手動重新產生遺漏的 initramfs

重要事項

  • 如果您能夠使用先前的核心版本或從修復/修復 VM 的 Chroot 內啟動 VM，請手動重新產生遺失的 initramfs。
  • 若要從修復 VM 手動重新產生遺漏的 initramfs，請確定已遵循 離線疑難解答 中的步驟 1，並在 chroot 內執行這些命令。

  1. 識別有開機問題的特定核心版本。 您可以從對應的核心緊急錯誤擷取版本資訊。

    請參閱下列螢幕快照作為範例。 核心異常錯誤顯示核心版本為 「3.10.0-1160.59.1.el7.x86_64」：

    顯示如何識別具有遺漏 initramfs 影像之特定核心版本的螢幕快照。

  2. 執行下列其中一個命令，重新產生遺失的 initramfs 檔案：

    • 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

      重要事項

      將取代 3.10.0-1160.59.1.el7.x86_64 為對應的核心版本。

    • 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

      重要事項

      將取代 5.3.18-150300.38.53-azure 為對應的核心版本。

    • Ubuntu 18.04

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

      重要事項

      將取代 5.4.0-1077-azure 為對應的核心版本。

  3. 重新產生 GRUB 組態檔。 請遵循 重新安裝 GRUB 中的 指示，針對對應的 Linux 發行版和 VM 產生重新產生 GRUB 組態檔

  4. 如果上述步驟是從修復 VM 執行，請遵循 離線疑難解答中的步驟 3。 如果上述步驟是從 Azure 序列控制台執行，請遵循 在線疑難解答 方法。

  5. 透過最新的核心版本重新啟動您的 VM。

核心異常 - 未同步：嘗試終止 init

從 Azure 序列主控台識別此問題。 您會看到如下的輸出：

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

這種核心異常是因為下列可能原因而發生：

如需原因詳細數據和解決方案，請參閱下列各節。 請確定已依照 離線疑難解答中的指示，從 Chroot 環境中的修復/修復 VM 執行命令。

遺漏重要檔案和目錄

重要 Linux 檔案和目錄因為人為錯誤而遺失。 例如，不小心刪除檔案或文件系統損毀。

  1. 將OS磁碟復本連結至修復 VM，並使用 chroot 掛接對應的文件系統之後，驗證 OS 磁碟內容。 您可以比較輸出與執行相同作業系統版本之工作 VM 的輸出。

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

  2. 從備份還原遺失的檔案。 如需詳細資訊，請參閱 從 Azure 虛擬機備份復原檔案。 根據遺漏的檔案數目，最好是執行完整的 VM 還原。 如需詳細資訊，請參閱如何在 Azure 入口網站 中還原 Azure VM 數據。

遺漏重要的系統核心連結庫和套件

重要系統核心連結庫、檔案或套件會從系統中刪除或損毀。 若要解決此問題，請重新安裝受影響的連結庫、檔案或套件。 此解決方案適用於 RPM 型散發套件，例如 Red Hat/CentOS/SUSE VM。 對於其他 Linux 發行版，建議 您從備份還原 VM。

若要執行重新安裝，請遵循下列步驟：

  1. 使用與受影響 VM 相同 OS 版本和世代的原始映像來建立救援 VM。

  2. 存取救援 VM 中的 Chroot 環境，以針對問題進行疑難解答。

    sudo chroot /rescue

    命令輸出會指出哪個連結庫遺失或損毀，如下所示：

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

  3. 確認所有系統套件及其在救援 VM 中的對應狀態。 將輸出與執行相同 OS 版本的健康情況 VM 進行比較。

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

    以下是命令輸出的範例：

    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

    輸出行 missing /lib64/libc-2.28.so 與步驟 2 中的先前錯誤相關，指出 遺漏 libc-2.28.so 套件。 不過， 可以修改 libc-2.28.so 套件。 在這裡情況下，輸出會顯示 .M..... ，而不是 missing。 下列步驟 會參考 libc-2.28.so 套件作為範例。

  4. 在救援 VM 中，確認哪個套件包含 連結庫 /lib64/libc-2.28.so。

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

    glibc-2.28-127.0.1.el8.x86_64

    注意事項

    輸出會顯示需要重新安裝的套件，包括套件名稱和版本。 套件版本可能與受影響 VM 上安裝的版本不同。

  5. 在受影響的 VM 中，確認已安裝哪個版本的 glibc 套件。

    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. 下載套件 glibc-2.28-211.0.1.el8.x86_64。 您可以使用像是 yumdownloaderzypper install --download-only <packagename> 的套件管理工具，或根據您正在執行的作業系統，從 OS 廠商的官方網站或從救援 VM 下載。

    以下是使用 工具的 yumdownloader 範例：

    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. 在救援 VM 中重新安裝受影響的套件。

    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. 存取救援 VM 中的 Chroot 環境以驗證重新安裝。

    sudo chroot /rescue

  9. 關閉救援 VM，並將 OS 磁碟交換至受影響的 VM。

檔案許可權錯誤

由於人為錯誤 (例如，有人 chmod 777 在或其他重要的 OS 檔案系統上 / 執行) ，因此修改了錯誤的全系統檔案許可權。 若要解決此問題，請還原檔案許可權。 此解決方案適用於 RPM 型散發套件，例如 Red Hat/CentOS/SUSE VM。 對於其他 Linux 發行版，建議 您從備份還原 VM。

若要還原檔案許可權，請在將OS磁碟復本連結至修復VM並使用 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

注意事項

請勿在執行生產系統上執行此命令。

如果在手動復原對應的檔案許可權之後仍有問題，請 從備份執行還原。

遺漏分割區

在 、/opt、/var、/home、 /tmp和 / 檔案系統分散到不同分割區的情況下/usr，數據可能會因為數據分割層級的問題而無法存取，這可能是因為分割區重設大小作業期間的錯誤或其他問題所造成。

在此案例中，如果您記錄原始數據分割數據表配置，且每個原始數據分割都有確切的開始和結束扇區，而且系統上沒有進一步的修改，例如建立新的文件系統，請使用相同的原始版面配置，搭配 MBR 數據分割數據表的 fdisk (等工具重新建立數據分割，) GPT 數據分割數據表的 gdisk (，) 存取遺漏的文件系統。

如果這種方法無法運作，請 從備份執行還原。

SELinux 問題

錯誤的 SELinux 許可權可能會導致系統無法存取重要檔案。 若要解決此問題，請遵循下列步驟：

  1. 若要確認系統是否因為錯誤的 SELinux 許可權而發生問題，請將 selinux=0 核心選項新增至 GRUB linux16 行，以啟動已停用 SELinux 的系統。

  2. 如果系統能夠開機，請執行下列命令以在開機時觸發 SELinux 重新標籤，然後重新啟動系統：

    touch /.autorelabel

  3. 如果 VM 仍然無法開機，請從備份執行完整的 VM 還原。 如需詳細資訊，請參閱如何在 Azure 入口網站 中還原 Azure VM 數據。

其他核心相關開機問題

本文涵蓋 Azure 中最常見的 Linux 核心異常。 如需常見核心異常案例的詳細資訊，請參閱 Azure Linux VM 中的核心異常 - 常見的核心緊急事件。

有一些其他重要的可能核心異常，可能會導致 SSH) 案例 (開機或沒有安全殼層。

請務必從 Chroot 環境內的修復 VM 執行任何命令，如 離線疑難解答中所指示。 如果系統已在先前的核心版本上開機，這些命令也可以使用根許可權或 sudo，從原始 VM 執行，如 在線疑難解答中所指示。

最近的核心升級

如果核心在最近的核心升級之後開始異常，請在先前的核心版本上開機 VM。 如需詳細資訊，請參閱 舊版核心版本的開機系統。

您也可以檢查 Linux 散發廠商是否已發行較新的核心版本，並加以安裝。 如需如何安裝最新核心版本的詳細資訊，請參閱 核心更新程式。

最近的核心降級

如果核心在最近的核心降級之後開始異常，請返回最新安裝的核心。 您也可以檢查 Linux 散發廠商是否已發行較新的核心版本，並加以安裝。 如需如何安裝最新核心版本的詳細資訊，請參閱 核心更新程式。

若要透過最新的核心版本來開機系統，請遵循 手動變更預設核心版本中的指示，但選取 GRUB 功能表中所列的第一個核心。 在手動修改中，您可以將值設定為 GRUB_DEFAULT 0，然後重新產生對應的 GRUB 組態檔。

核心模組變更

您可能會遇到與新核心模組或遺失核心模組相關的核心異常。 若要取得特定核心模組的詳細數據，以在有任何) 時 (問題，請檢查對應的核心異常追蹤。

若要驗證載入的核心模組和 /etc/modprobe.d/*.conf 檔案中已停用的核心模組，請執行下列其中一個命令：

  • 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

    重要事項

    將取代 3.10.0-1160.59.1.el7.x86_64 為對應的核心版本。

  • SLES 12/15

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

    重要事項

    將取代 5.3.18-150300.38.53-azure 為對應的核心版本。

  • Ubuntu 18.04

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

    重要事項

    將取代 5.4.0-1077-azure 為對應的核心版本。

若要移除任何特定的核心模組，請執行下列命令，並視需要 重新產生 initramfs 。

rmmod <kernel_module_name>

如果系統服務使用特定的核心模組，請執行 systemctl disable <serviceName> 或 systemctl stop <serviceName> 命令來停用它。

操作系統最近的組態變更

識別任何可能造成問題的最新核心組態變更。 若要解決問題，請調整這些設定或復原組態變更。

執行下列命令，以尋找下列任何檔案中設定的持續性核心參數：

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

執行下列命令來分析目前的核心參數及其目前的值：

sysctl -a

注意事項

在執行中的系統上執行此命令，而不是從 Chroot 環境執行。

可能遺失的檔案

如需這類問題的詳細資訊，請參閱 遺漏重要的檔案和目錄。

檔案的許可權錯誤

如需這類問題的詳細資訊，請參閱 錯誤的檔案許可權。

遺漏分割區

如需這類問題的詳細資訊，請參閱 遺漏數據分割。

核心錯誤

從 Azure 序列主控台識別此問題。 這類問題看起來會像下列輸出：

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

這種核心異常與核心錯誤或第三方核心錯誤相關聯。

若要修正核心錯誤，請使用核心 BUG 字串來搜尋廠商知識庫，並在系統執行的對應核心版本中尋找已知問題。 以下是一些重要的廠商資源：

建議您讓所有系統保持在最新狀態，以排除任何最近核心版本中已修正的可能錯誤。 如需詳細資訊，請參閱 核心更新程式。

如果廠商需要進一步分析，請設定並啟用 kdump 以產生核心傾印：

核心更新程式

若要安裝最新的可用核心版本，請執行下列其中一個命令：

  • 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

若要重新安裝特定的核心版本，請執行下列其中一個命令。 請確定您未透過您嘗試重新安裝的相同核心版本來開機。 如需詳細資訊，請參閱 舊版核心版本的開機系統。

  • RHEL/CentOS/Oracle Linux

    yum reinstall kernel-3.10.0-1160.59.1.el7.x86_64

    重要事項

    將取代 3.10.0-1160.59.1.el7.x86_64 為對應的核心版本。

  • SLES 12/15

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

    重要事項

    將取代 kernel-azure-5.3.18-150300.38.75.1.x86_64 為對應的核心版本。

    • Ubuntu 18.04/20.04

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

      重要事項

      將取代 5.4.0.1091.68 為對應的核心版本。

若要更新系統並套用最新的可用變更，請執行下列其中一個命令：

  • RHEL/CentOS/Oracle Linux

    yum update

  • SLES 12/15

    zypper refresh
zypper update

  • Ubuntu 18.04/20.04

    apt update
apt upgrade

核心異常可能與下列任何項目相關。 如需詳細資訊，請參閱 運行時間的核心異常。

  • 應用程式工作負載變更。
  • 應用程式開發或應用程式錯誤。
  • 效能相關問題等等。

後續步驟

如果特定開機錯誤不是核心相關的開機問題，請參閱針對 Azure Linux 虛擬機器 開機錯誤進行疑難解答，以取得進一步的疑難解答選項。

與我們連絡，以取得說明

如果您有問題或需要相關協助，請建立支援要求，或詢問 Azure community 支援。 您也可以將產品意見反應提交給 Azure 意應見反社群。