syzkaller项目中ARM64实例启动失败问题分析与解决

问题背景

在syzkaller项目的持续集成环境中，ARM64架构的GCE实例自2024年8月30日起突然出现启动失败的情况。系统启动时报告无法找到根设备/dev/vda，导致无法挂载根文件系统。这一问题影响了ci-upstream-gce-arm64实例的正常运行。

错误现象分析

从系统启动日志中可以看到以下关键错误信息：

VFS: Cannot open root device "/dev/vda" or unknown-block(0,0): error -6

系统尝试从/dev/vda设备挂载根文件系统失败，随后列出了当前系统中可用的所有块设备，包括RAM磁盘、null块设备和NVMe设备。值得注意的是，系统中确实存在一个NVMe设备nvme0n1及其分区，但没有预期的virtio块设备vda。

根本原因调查

经过深入分析，发现问题源于内核配置的变更。具体来说，以下因素导致了这一故障：

1. 内核配置变更：在问题出现的时间点前后，内核配置中启用了CONFIG_CMDLINE_FROM_BOOTLOADER选项，这改变了内核获取启动参数的行为。

2. 启动参数来源冲突：原本系统通过两种方式获取启动参数：

   • 通过CONFIG_CMDLINE内核配置中的硬编码参数
   • 通过构建的rootfs镜像中指定的参数

3. 设备命名差异：在GCE环境中，ARM64实例实际使用的是NVMe设备(nvme0n1)，而非传统的virtio设备(vda)。当启动参数来源发生变化时，系统无法正确识别根设备。

解决方案

针对这一问题，采取了以下解决措施：

1. 恢复内核配置：将CONFIG_CMDLINE_FROM_BOOTLOADER选项恢复为禁用状态，确保内核继续使用CONFIG_CMDLINE中指定的启动参数。

2. 启动参数一致性检查：验证所有构建镜像和内核配置中的启动参数是否一致，特别是root=参数。

3. 设备驱动兼容性：确保内核配置中包含对NVMe设备的完整支持，以应对GCE环境中可能出现的不同存储设备类型。

经验总结

这一事件为我们提供了以下重要经验：

1. 内核配置变更需谨慎：即使是看似无害的内核配置选项变更，也可能导致系统无法启动，特别是在跨架构环境中。

2. 云环境设备差异：不同云平台、不同架构可能使用不同类型的存储设备，系统配置需要具备足够的灵活性来适应这些差异。

3. 启动参数管理：需要统一管理启动参数的来源，避免多个来源之间的冲突，特别是在使用initramfs或复杂启动流程的环境中。

通过这次问题的解决，我们不仅恢复了ARM64实例的正常运行，也进一步完善了syzkaller项目的持续集成环境的稳定性。未来，我们将加强对内核配置变更的审查，并建立更完善的测试流程来预防类似问题的发生。