排查 Azure Linux 虚拟机启动问题，因为 OS 磁盘已满

适用于：✔️ Linux VM

总结

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

现象

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

  • 一台虚拟机意外关闭。
  • 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 配置

注意

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

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

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

  1. 拍摄 OS 磁盘的快照以提供恢复状态。

  2. 使用 az vm repair 命令、手动 恢复 VM 或 单用户模式获取对配置文件的访问权限。

  3. 记下当前配置，因为空间可能无法备份 VM 中的文件。

  4. 将 /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

  • 如果您正在使用恢复虚拟机，请按照卸载并分离原始虚拟硬盘中的说明操作，将 OS 磁盘交换回有问题的虚拟机，然后尝试正常启动该虚拟机。 如果使用单用户模式，请退出，然后 VM 重新启动。

  • VM 完全启动后，使用命令行工具（如 df 和 du）浏览文件系统并释放一些空间。 大约 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 的连接可能会失败。
  • 虚拟机根据应用程序可能显示为脱机状态。

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

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

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

解决方法

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

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

  1. 使用 az vm repair 命令、手动 恢复 VM 或 单用户模式获取对 OS 磁盘和分区的访问权限，因为系统不会正常启动。

  2. 使用标准 Linux 工具和命令识别大型文件和目录：

    • du -ks /* | sort -n - 在某个位置中找到占用空间最多的文件或目录。 重复操作最大报告的目录，直到发现一些大规模数据为止。

    • ls -altSr /var/log - 按大小按升序列出目录的内容。

    • find / -size +500M -exec ls -alFh {} \; - 查找大型单个文件。 根据需要将 500M 值调整为几兆字节或千兆字节，以查找要修剪的最有效文件。

  3. 删除任何可标识为不必要的文件，例如旧日志、忘记的备份和类似的文件。

  4. 清除适当的空间后，确保大约 10% 的磁盘空间是空闲的，然后重新启动系统。

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

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

后续步骤

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

  • Last updated on