应用内核更改后，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 修复命令 创建一个修复 VM，该 VM 附加了受影响 VM 的 OS 磁盘的副本。 使用 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. 串行控制台连接恢复后，串行控制台窗口的左上角会显示一个倒计时计数器。 在 GRUB 菜单中按 ESCAPE 键中断 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 Boot Loader GRUB2 和 Ubuntu Grub2/Setup。 作为参考：顶级菜单项值为 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： 找不到文件 '/initramfs-*.img'

    错误：找不到文件“/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 并重新生成 GRUB 配置文件 中的说明生成相应的 Linux 分发和 VM

  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 磁盘内容。 可以将输出与运行相同 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。 可以使用包管理工具（例如 yumdownloader 或 zypper install --download-only <packagename> ）从 OS 供应商的官方网站或救援 VM 下载它，具体取决于正在运行的 OS。

    下面是使用 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、、/home/var/tmp、 和 / 文件系统分布在不同的分区中的情况下/usr，由于分区级别的问题，数据可能无法访问，这可能是由分区调整大小操作期间的错误或其他问题引起的。

在此方案中，如果记录了原始分区表布局（每个原始分区的确切开始和结束扇区），并且无需对系统执行进一步修改（例如创建新文件系统），请通过对 MBR 分区表的 fdisk (等工具使用相同的原始布局重新创建分区) 或 gdisk () 以获取对缺少的文件系统的访问权限。

如果此方法不起作用，请 从备份执行还原。

SELinux 问题

错误的 SELinux 权限可能会阻止系统访问重要文件。 若要解决此问题，请按照下列步骤操作：

  1. 若要验证系统是否由于 SELinux 权限错误而出现问题，请在禁用 SELinux 的情况下启动系统，方法是将 selinux=0 内核选项添加到 GRUB linux16 行。

  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 环境中运行此命令。

可能缺少的文件

有关此类问题的详细信息，请参阅 缺少重要文件和目录。

文件权限错误

有关此类问题的详细信息，请参阅 错误的文件权限。

缺少分区

有关此类问题的详细信息，请参阅 缺少分区。

内核 bug

从 Azure 串行控制台中识别此问题。 此类问题将类似于以下输出：

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

这种内核崩溃与内核 bug 或第三方内核 bug 相关联。

若要修复内核 bug，请使用内核 BUG 字符串搜索供应商知识库，并在系统运行的相应内核版本中查找已知问题。 下面是一些重要的供应商资源：

我们建议使所有系统保持最新状态，以排除在最新内核版本中已修复的任何可能 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

内核崩溃可能与以下任何项有关。 有关详细信息，请参阅 运行时的内核崩溃。

  • 应用程序工作负载更改。
  • 应用程序开发或应用程序 bug。
  • 与性能相关的问题等。

后续步骤

如果特定的启动错误不是与内核相关的启动问题，请参阅排查 Azure Linux 虚拟机启动错误以获取进一步的故障排除选项。

联系我们寻求帮助

如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。 还可以向 Azure 反馈社区提交产品反馈。