确保
串行控制台
在 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 的虚拟机串行控制台。
确定与内核相关的特定启动问题。
使用 Azure 串行控制台 在 GRUB 菜单中中断 VM，并选择任何以前的内核来启动它。 有关详细信息，请参阅 在较旧内核版本上启动系统。
转到相应的部分以解决与内核相关的特定启动问题：
内核崩溃 - 未同步：VFS：无法在未知块上装载根 fs (0，0)
内核崩溃 - 未同步：试图终止 init！
其他与内核相关的启动问题
解决与内核相关的启动问题后，重启 VM，使其可以通过最新的内核版本启动。
脱机故障排除
如果有 VM 的最新备份，请 从备份还原 VM 以修复启动问题。
如果 Azure 串行控制台 在特定 VM 中不起作用或订阅中不是选项，请使用救援/修复 VM 排查启动问题。 为此，请按照下列步骤操作：
使用 vm 修复命令 创建一个修复 VM，该 VM 附加了受影响 VM 的 OS 磁盘的副本。 使用 chroot 在修复 VM 中装载 OS 文件系统的副本。
或者，可以使用 Azure 门户手动创建救援 VM。 有关详细信息，请参阅使用 Azure 门户将 OS 磁盘附加到恢复 VM，对 Linux VM 进行故障排除。
确定与内核相关的特定启动问题。
转到相应的部分以解决与内核相关的特定启动问题：
内核崩溃 - 未同步：VFS：无法在未知块上装载根 fs (0，0)
内核崩溃 - 未同步：试图终止 init！
其他与内核相关的启动问题
解决与内核相关的启动问题后，执行以下操作：
退出 chroot。
从救援/修复 VM 卸载文件系统的副本。
az vm repair restore运行 命令，将修复的 OS 磁盘与 VM 的原始 OS 磁盘交换。 有关详细信息，请参阅 使用 Azure 虚拟机修复命令修复 Linux VM 中的步骤 5。
通过查看 Azure 串行控制台或尝试连接到 VM 来验证 VM 是否能够启动。
如果存在与内核相关的重要内容、整个 /boot 分区或其他重要内容缺失，并且无法恢复这些内容，我们建议从备份还原 VM。 有关详细信息，请参阅如何在 Azure 门户 中还原 Azure VM 数据。
在较旧内核版本上启动系统
使用 Azure 串行控制台
使用 Azure 串行控制台重启 VM。
选择串行控制台窗口顶部的 “关闭 ”按钮。
选择“ 重启 VM (硬) ”选项。
串行控制台连接恢复后，你将在串行控制台窗口的左上角看到一个倒计时计数器。 在 GRUB 菜单中按 ESCAPE 键中断 VM。
按向下键选择任何以前的内核版本。
GRUB_DEFAULT按照手动更改默认内核版本中的说明更改 /etc/default/grub 文件中的变量。 这是一项永久性更改。
如果 GRUB 菜单中仅列出了一个内核版本，请按照 脱机故障排除 方法从修复 VM 排查此问题。
) 使用修复 VM (ALAR 脚本
在 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
运行以下命令，将损坏的内核替换为以前安装的版本：
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
通过运行以下命令设置新的默认内核并指定相应的内核标题：
# 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 相应的菜单项标题。
通过运行以下命令验证新的默认内核是否为所需内核：
grub2-editenv list
确保 /etc/default/grub 文件中变量的值GRUB_DEFAULT设置为 saved。 若要修改它，请确保 重新生成 GRUB 配置文件 以应用更改。
RHEL 8/9 和 CentOS 8
通过运行以下命令列出可用的内核：
ls -l /boot/vmlinuz-*
通过运行以下命令设置新的默认内核：
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 相应的内核版本。
通过运行以下命令验证新的默认内核是否为所需内核：
grubby --default-kernel
通过修改 /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”是第一个子菜单的第三个菜单项。
重新生成 GRUB 配置文件以应用更改。 按照重新安装 GRUB 中的说明为相应的 Linux 分发和 VM 生成 重新生成 GRUB 配置文件 。
内核崩溃 - 未同步：VFS：无法在未知块上装载根 fs (0，0)
发生此错误的原因是最近的系统更新 (内核) 。 它最常出现在基于 RHEL 的发行版中。
可以从 Azure 串行控制台中识别此问题。 你将看到以下任一错误消息：
“内核崩溃 - 未同步：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)
“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
使用 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
重新生成 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
执行还原命令后，重启原始 VM 并验证它是否能够启动。
手动重新生成缺少的 initramfs
如果能够使用以前的内核版本或从修复/救援 VM 中的 chroot 启动 VM，请手动重新生成缺少的 initramfs。
若要从修复 VM 手动重新生成缺少的 initramfs，请确保已遵循 脱机故障排除 中的步骤 1，并在 chroot 中执行这些命令。
确定与启动相关的问题的特定内核版本。 可以从相应的内核死机错误中提取版本信息。
请参阅以下屏幕截图作为示例。 内核崩溃错误显示内核版本为“3.10.0-1160.59.1.el7.x86_64”：
通过运行以下命令之一重新生成缺少的 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 相应的内核版本。
重新生成 GRUB 配置文件。 按照 重新安装 GRUB 并重新生成 GRUB 配置文件 中的说明生成相应的 Linux 分发和 VM
如果上述步骤是从修复 VM 执行的，请按照 脱机故障排除中的步骤 3 进行操作。 如果上述步骤是从 Azure 串行控制台执行的，请按照 联机故障排除方法进行操作 。
通过最新的内核版本重启 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
出现此类内核崩溃的原因是以下可能的原因：
缺少重要文件和目录。
缺少重要的系统核心库和包
文件权限错误
SELinux 问题
有关原因的详细信息和解决方案，请参阅以下部分。 确保按照 脱机故障排除中的说明，从 chroot 环境中的修复/救援 VM 执行命令。
缺少重要文件和目录
由于人为错误，缺少重要的 Linux 文件和目录。 例如，文件被意外删除或文件系统损坏。
将 OS 磁盘的副本附加到修复 VM 并使用 chroot 装载相应的文件系统后，验证 OS 磁盘内容。 可以将输出与运行相同 OS 版本的工作 VM 中的输出进行比较。
ls -l /
ls -l /usr/lib
ls -l /usr/lib64
ls -lR / | more
从备份还原缺少的文件。 有关详细信息，请参阅 从 Azure 虚拟机备份恢复文件。 根据缺少的文件数，执行完整的 VM 还原可能更好。 有关详细信息，请参阅如何在 Azure 门户 中还原 Azure VM 数据。
缺少重要的系统核心库和包
重要的系统核心库、文件或包将从系统中删除或损坏。 若要解决此问题，请按照下列步骤操作：
通过运行以下命令查找 glibc 包。 请确保它已安装，并且其所有文件仍存在于系统中。
rpm -qa | grep glibc
运行以下命令，验证所有系统包及其相应状态。 将输出与运行相同 OS 版本的正常 VM 进行比较。 从修复 VM 重新安装损坏的包。
rpm --verify --all
文件权限错误
系统范围的文件权限因人为错误而修改， (例如，某人 chmod 777 在 / 或其他重要的 OS 文件系统上运行) 。 若要解决此问题，请还原文件权限。 该解决方案适用于 Red Hat/CentOS 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
不要在运行生产系统时运行此命令。
如果在手动恢复相应的文件权限后仍然存在此问题，请 从备份执行还原。
/usr如果 、、/opt、/var/home、 /tmp和 / 文件系统分布在不同的分区中，则数据可能无法访问，因为分区级别存在问题，这可能是由分区大小调整操作期间的错误或其他原因造成的。
在此方案中，如果记录了原始分区表布局（每个原始分区的确切开始和结束扇区），并且对系统没有进一步的修改（例如创建新文件系统），则使用相同的原始布局（如 fdisk (）工具重新创建分区，) GPT 分区表的 gdisk () 获取对缺少的文件系统的访问权限。
如果此方法不起作用，请 从备份执行还原。
SELinux 问题
错误的 SELinux 权限可能会阻止系统访问重要文件。 若要解决此问题，请按照下列步骤操作：
若要验证系统是否由于 SELinux 权限错误而出现问题，请在禁用 SELinux 的情况下启动系统，方法是将 selinux=0 内核选项添加到 GRUB linux16 行。
如果系统能够启动，请运行以下命令，在启动时触发 SELinux 重新标记并重新启动系统：
touch /.autorelabel
如果 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 字符串搜索供应商知识库，并在系统运行的相应内核版本中查找已知问题。 下面是一些重要的供应商资源：
Red Hat 内核 Oops 分析器
此工具旨在帮助诊断内核崩溃。 当你输入文本、 vmcore-dmesg.txt或包含一个或多个内核 oops 消息的文件时，它将指导你诊断内核崩溃问题。
Red Hat 知识库
若要获取对 Red Hat 资源的访问权限，请链接Microsoft Azure 和 Red Hat 帐户。 有关详细信息，请参阅 Microsoft Azure 客户如何访问 Red Hat 客户门户。
SUSE 知识库
Ubuntu 知识库
我们建议使所有系统保持最新状态，以排除在最新内核版本中已修复的任何可能 bug。 有关详细信息，请参阅 内核更新过程。
如果需要供应商进行进一步分析，请配置并启用 kdump 以生成核心转储：
基于 Red Hat 的 VM 中的 Kdump 配置。
Ubuntu VM 中的内核故障转储配置。
SLES VM 中的内核核心转储配置
内核更新过程
若要安装最新的可用内核版本，请运行以下命令之一：
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 相应的内核版本。
