排查由于完整 OS 磁盘而导致的 Azure Linux 虚拟机启动问题

2024-07-30

适用于：✔️ Linux VM

在某些情况下和配置下，完整的操作系统（OS）磁盘可能会导致 Azure Linux 虚拟机（VM）启动问题。本文提供了启动问题的一些原因和解决方案。

现象

在正常系统操作期间，如果 OS 磁盘或关键系统分区已满，则可能会出现以下问题：

VM 意外关闭。
VM 无法成功启动。

先决条件

若要排查启动问题并完成系统修复，应满足以下要求：

创建磁盘快照或操作某些备份和还原工具的权限。

在本文中，数据或磁盘已更改，因此能够将 VM 还原到以前的状态是安全系统管理的关键组件。
已启用和配置的启动诊断。

建立此配置后，可以将来查看控制台日志的存储，并与 VM 的串行控制台接互。
每当需要救援 VM 时，创建 VM 的权限。
需要交换磁盘时创建、分离和附加磁盘的权限。

注意

并非所有要求都适用于以下方案。

方案 1：VM 意外关闭，无法启动

许多安全强化做法可能会导致维护系统出现困难。如果在写入审核日志时发生错误，则一个常见配置要求系统立即关闭。若要检查此方案是否是系统关闭的原因，请执行以下操作：

检查串行控制台日志中的系统关闭消息。

如果系统已启动，则为“正在启动安全审核服务...”将显示消息。此消息不指示服务已启动。相反，VM 会立即转换为关闭，并显示“关闭”消息。如果系统正在运行并意外关闭，串行控制台可能会显示有序关闭进程，以“关闭”消息结束。请参阅以下屏幕截图作为示例：
使用 az vm repair 命令、手动恢复 VM 或单用户模式装载 OS 磁盘。然后，使用df命令行工具检查磁盘利用率，并检查包含 /var/log/audit 目录的磁盘是否使用率接近 100%。
使用 az vm repair 命令、手动恢复 VM 或单用户模式访问 OS 文件系统，并验证 /etc/audit/auditd.conf 文件是否包含以下配置：
```
[root@linux /]# grep action /etc/audit/auditd.conf
admin_space_left_action = HALT
disk_full_action = HALT
disk_error_action = HALT
```

解决方法：暂时禁用 HALT 配置

注意

如果此解决方法不起作用或不适合你的环境，请转到“ 解决方案 ”部分。

如果审核的配置导致审核日志故障时系统关闭，暂时禁用 HALT 配置可让 VM 启动到完整的 OS 进行修正。

若要修复此常见的审核问题和其他几个常见问题，请使用 Azure Linux 自动修复（ALAR）工具中的审核操作在 Azure CLI 中自动运行az vm repair扩展。若要手动执行相同的过程，请执行以下步骤：

拍摄 OS 磁盘的快照以提供恢复状态。
使用 az vm repair 命令、手动恢复 VM 或单用户模式获取对配置文件的访问权限。
记下当前配置，因为空间可能无法备份 VM 中的文件。
将 /etc/audit/auditd.conf 文件中以前的配置从HALT任何其他有效值更改为除其他任何有效值之外SINGLE。在此方案中，这些值可以是 IGNORESUSPENDauditd.conf 文件的 Linux man 页中列出的任何其他值，它为 VM 中使用的软件版本提供适当的参数。
```
[root@linux /]# grep action /etc/audit/auditd.conf
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND
```

如果使用恢复 VM，请按照卸载中的说明操作，分离原始虚拟硬盘，将 OS 磁盘交换回有问题的 VM，并尝试正常启动 VM。如果使用单用户模式，请退出，然后 VM 重新启动。
VM 完全启动后，使用命令行工具（如和du）df浏览文件系统并释放一些空间。大约 10% 的包含 /var/log/audit 目录的文件系统应该是一个很好的初始目标。

解决问题后，将 /etc/audit/auditd.conf 文件中的内容还原为其原始值并重新启动 VM。

方案 2：VM 磁盘在 Azure 中调整大小，但 OS 无法调整大小，VM 无法完全启动

标识完整磁盘并关闭 VM 以调整 OS 磁盘的大小后，VM 可能无法成功启动。在某些分发版中，OS 尝试在重新启动时自动调整根文件系统的大小/时，这种情况可能会令人困惑。如果磁盘已满，则调整大小操作可能会失败，因为该过程需要一些可用空间来扩展文件系统。没有可用空间可能会导致 cloud-init 失败，然后 VM 无法完成启动。

若要识别此问题，请查看串行控制台中的启动日志，并检查是否存在类似于以下文本的行：

[   15.384699] cloud-init[1142]: OSError: [Errno 28] No space left on device
[   15.384742] cloud-init[1142]: Original exception was:
[   15.384784] cloud-init[1142]: OSError: [Errno 28] No space left on device

由于特定的 cloud-init 消息可能不是返回的最可见消息，因此查找包含“[Errno 28] 设备上没有剩余空间”文本或类似“无空间”消息的其他行。

若要解决此问题，请清除不需要的数据以释放少量磁盘空间，然后展开文件系统。

方案 3：VM 启动，但由于服务故障而无法访问

似乎完全启动的 VM 可能存在以下问题：

启动期间发生服务问题。
Azure 代理可能不可用。
与 VM 的连接可能会失败。
VM 可能根据应用程序处于脱机状态。

在启动期间，多个消息（如“[Errno 28] 设备上没有剩余空间”或其他类型的消息表示根文件系统已满。

如果 VM 启动但出现不可用，请检查启动诊断中的串行日志以查看启动消息，或使用串行控制台与 VM 交互。如果空间不足，请清除不需要的数据来释放空间或扩展磁盘。

如果控制台日志包含许多消息，指出“ERROR ExtHandler /proc/net/route 不包含路由”，则完整的 OS 磁盘也可能是原因，因为网络服务无法完全启动。

解决方法

以下解决方法适用于上述任何方案。

解决方法 1：清除不需要的数据

使用 az vm repair 命令、手动恢复 VM 或单用户模式获取对 OS 磁盘和分区的访问权限，因为系统不会正常启动。
使用标准 Linux 工具和命令识别大型文件和目录：
- du -ks /* | sort -n - 在某个位置中找到占用空间最多的文件或目录。对最大的报告目录重复，直到发现一些大型数据。
- ls -altSr /var/log - 按大小按升序列出目录的内容。
- find / -size +500M -exec ls -alFh {} \; - 查找大型单个文件。根据需要将 500M 值调整为几兆字节或千兆字节，以查找要修剪的最有效文件。
删除任何可标识为不必要的文件，例如旧日志、忘记的备份和类似的文件。
清除适当的空间量后，目标大约为 10% 的可用磁盘，然后重新启动系统。

解决方法 2：扩展 OS 文件系统

如果 OS 文件系统中无法清除任何数据，建议扩展包含关键 OS 卷的磁盘。有关详细信息，请参阅扩展 Linux VM 上的虚拟硬盘。

后续步骤

如果特定的启动错误不是由于完整的 OS 磁盘而导致的 Linux 启动问题，请参阅排查 Azure Linux 虚拟机启动错误，以便进一步进行故障排除。

联系我们寻求帮助

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

通过