iPXE在ESXi虚拟机中EFI模式下的本地磁盘启动问题分析与解决

问题背景

在使用iPXE的EFI版本（如snponly.efi、ipxe.efi等）时，用户报告在VMware ESXi虚拟环境中遇到了一个间歇性的启动问题。具体表现为：当尝试通过sanboot --drive 0 --filename \EFI\debian\grubx64.efi命令从本地磁盘启动时，iPXE有时无法定位到EFI文件系统。

问题现象

在失败情况下，iPXE会输出以下错误信息：

EFIBLK 0x00 cannot locate block I/O: Error 0x7f22208e
Boot from SAN device 0x00 failed: Error 0x7f22208e

而在成功情况下，iPXE能够正确识别并遍历所有可用的块设备，最终找到并加载指定的EFI文件。

问题分析

经过深入调查，发现这个问题与UEFI固件的设备连接行为有关。具体表现为：

1. 启动顺序影响：当网络启动选项不是第一个启动项时，问题更容易出现。如果手动从启动菜单中选择网络启动，则通常能成功。

2. 固件优化行为：某些UEFI固件（特别是VMware ESXi的虚拟UEFI固件）会尝试优化启动速度，仅连接它认为必要的设备驱动。如果固件认为只需要网络启动，就可能不会连接文件系统和块设备驱动。

3. GRUB影响：虽然在本案例中不是主要原因，但值得注意的是，如果GRUB在iPXE之前执行，它可能会断开所有UEFI文件系统驱动，转而使用自己的内部驱动。

解决方案

iPXE开发团队提出了一个修复方案，即在执行块设备启动前强制重新连接所有驱动。这个修改通过调用efi_driver_reconnect_all()函数实现，确保所有本地驱动器都被正确连接。

核心修复代码如下：

static int efi_block_boot ( unsigned int drive,
                           const char *filename ) {
    EFI_STATUS efirc;
    int rc;

    /* 确保所有本地驱动器都已连接 */
    efi_driver_reconnect_all();

    /* 释放SNP设备 */
    efi_snp_release();

验证结果

用户应用此补丁后，经过多次测试，问题不再复现。这表明该修复确实解决了UEFI固件未正确连接所有设备驱动的问题。

技术启示

1. UEFI启动复杂性：UEFI启动过程涉及多个驱动层和固件优化策略，这可能导致看似随机的问题。

2. 环境依赖性：虚拟环境中的UEFI实现可能与物理硬件有所不同，需要特别注意。

3. 防御性编程：在编写启动加载程序时，应该假设固件行为可能不符合预期，主动确保所需资源可用。

最佳实践建议

对于需要在虚拟环境中使用iPXE进行EFI启动的用户，建议：

1. 使用包含此修复的最新版iPXE
2. 确保虚拟机有足够的内存分配（至少16GB）
3. 禁用安全启动功能
4. 在可能的情况下，将网络启动设为第一启动选项

这个问题及其解决方案展示了在复杂启动环境中，理解各组件交互方式的重要性，也为处理类似问题提供了有价值的参考。