vSphere中Ubuntu24.04虚拟机从BIOS迁移至EFI的完整实践指南

1. 为什么你需要从BIOS迁移到EFI？不只是为了直通显卡

最近在折腾vSphere上的Ubuntu服务器，特别是那些要跑AI应用或者需要直通特定硬件的机器，我发现一个挺普遍但又容易被忽略的问题：启动模式。很多朋友，包括我自己以前，在vSphere里新建Ubuntu 24.04虚拟机时，可能图省事或者没注意，直接就用了默认的BIOS（也叫Legacy）启动模式。这模式用了很多年，确实稳定，但当你需要用到一些现代硬件的特性时，比如给虚拟机直通一张高性能的NVIDIA显卡来跑大模型训练，麻烦就来了。

ESXi在配置PCIe设备直通时，尤其是对显卡这类设备，经常会要求虚拟机采用EFI（UEFI）启动模式。如果你坚持用BIOS模式，很可能在尝试添加直通设备时，vSphere会直接报错，或者设备添加了但虚拟机根本启动不了，提示一些关于“安全启动”或“固件”不兼容的错误信息。我上次就踩了这个坑，新建了一台准备做深度学习开发的Ubuntu 24.04服务器，一切就绪后，在vSphere里给虚拟机添加直通显卡，结果死活启动失败，排查了半天才发现根源是启动模式冲突。

所以，这篇指南就是来解决这个具体问题的：如何把一台已经在vSphere里运行着、采用传统BIOS启动的Ubuntu 24.04虚拟机，安全、完整地转换成EFI启动模式。 这不仅仅是改一个虚拟机设置那么简单，它涉及到磁盘分区表、引导程序、系统内核配置等一系列底层操作。别担心，听起来复杂，但跟着步骤一步步来，其实是个“体力活”多于“脑力活”的过程。整个过程的核心思路是：先把硬盘分区表从MBR升级到GPT（这是EFI的基础），然后创建一个专用的EFI系统分区（ESP），最后重新安装和配置GRUB引导程序到EFI环境。我会把每个步骤的细节、可能遇到的坑以及怎么填坑都讲清楚，确保你操作一次就能成功。

2. 动手前的必备功课：环境检查与风险规避

在开始任何“手术”之前，充分的术前检查是避免“医疗事故”的关键。迁移启动模式虽然不常做，但一旦出错可能导致系统无法启动，所以准备工作必须做足。这里我强烈建议你拿出至少30分钟，完成下面这几项检查，这能帮你省下未来几个小时甚至几天数据恢复的时间。

首先，也是最重要的：备份你的虚拟机。 这不是一句空话。在vSphere环境中，最稳妥的备份方式就是给虚拟机创建一个完整的快照。登录到你的vSphere Client，找到目标Ubuntu虚拟机，右键选择“快照” -> “生成快照”。给快照起个明白的名字，比如“Before_BIOS_to_EFI_Migration”，描述里可以写上当前日期和操作目的。这个快照是你的“后悔药”，如果迁移过程中出现任何不可预知的问题，你可以瞬间回滚到操作前的状态，数据无损。我自己的习惯是，在进行任何可能影响系统启动的底层操作前，一定会打快照，这个习惯让我避免了好几次深夜加班救火的悲剧。

其次，搞清楚你当前的系统“底细”。 你需要登录到Ubuntu虚拟机内部，用几个简单的命令看看现状。打开终端，我们依次检查：

1. 确认当前启动模式： 运行 ls /sys/firmware/efi。如果这个目录不存在，或者命令报错“No such file or directory”，那么恭喜你（或者说，确认了问题），你的系统当前正运行在BIOS模式下。这正是我们要改变的状况。
2. 检查磁盘分区表类型： 运行 sudo fdisk -l /dev/sda（假设你的系统盘是sda）。在输出的开头部分，仔细找“Disklabel type”这一行。如果显示的是 dos，那说明你的磁盘使用的是MBR分区表，这是传统BIOS模式的标配。如果显示 gpt，那说明分区表已经是GPT格式，这是一个好消息，你可以跳过后面转换分区表的步骤。根据我的经验，大部分从默认模板创建的Ubuntu虚拟机，只要没特意选，分区表基本都是MBR的。
3. 查看现有分区布局： 同样在 fdisk -l 的输出里，看看你的 / 根分区和 /boot 分区（如果有的话）的大小和位置。记下它们对应的设备名，比如 /dev/sda1、/dev/sda2 等。这能让你心里有张地图，知道你的数据都在哪儿。

最后，准备一个“救生圈”：虚拟机的控制台访问权限。 确保你拥有通过vSphere Web Client或HTML5 Console直接访问该虚拟机控制台的能力。因为一旦引导程序配置出错，系统可能无法通过网络SSH连接，这时候控制台就是你唯一的操作入口。同时，手边最好准备好Ubuntu 24.04的安装ISO镜像文件，并知道如何在vSphere中将其挂载到虚拟机的CD/DVD驱动器上。万一最坏的情况发生，系统无法引导，我们可以挂载安装镜像，进入“救援模式”（Rescue Mode）来进行修复操作。把这些“逃生通道”提前准备好，你的操作心态会稳很多。

3. 第一步：为磁盘换上“新地基”——转换分区表为GPT

如果你的上一步检查确认磁盘是MBR分区表，那么迁移之旅的第一步就是把它转换成GPT（GUID分区表）。你可以把MBR想象成一个老旧的、地址空间有限的旧城区规划图，而GPT则是一张为现代大都市设计的、支持更多分区、容量更大的新规划图。EFI启动模式强烈依赖于GPT这张“新地图”。

这里有个非常重要的前提：转换分区表操作本身不会抹掉磁盘上的数据，但它是一个高风险操作，任何意外断电或中断都可能导致数据丢失。 所以，快照备份做了吗？如果没做，请立刻回头去做。

转换工具我们选用 gdisk，它比传统的 fdisk 对GPT支持更好。首先安装它：

sudo apt update
sudo apt install gdisk -y

安装完成后，就可以开始转换了。执行：

sudo gdisk /dev/sda

请再次确认 /dev/sda 是你的系统盘设备名。进入 gdisk 的交互式界面后，它会先检测当前的分区表。这时，千万不要直接进行任何写入操作。我们首先输入 p 命令，打印出当前的分区表信息，仔细核对一遍，确保你操作的是正确的磁盘，并且分区信息和你之前 fdisk -l 看到的是一致的。

核对无误后，输入 r 进入恢复和转换菜单。这个菜单里有很多高级选项，我们只需要其中一个。接着输入 g，这个命令就是将MBR转换为GPT的核心指令。输入后，gdisk 会告诉你，它将在内存中创建一张新的GPT分区表，这张新表会尽可能忠实地反映原有MBR分区的位置和大小。

关键一步来了： 输入 w 来将内存中的新分区表写入磁盘并退出。这时 gdisk 会再次严肃地警告你，询问是否确认。输入 Y 确认。整个过程很快，你会看到“The operation has completed successfully”之类的提示。退出后，强烈建议你立即重启一次虚拟机。这不是必须的，但能让内核重新读取新的分区表信息，避免后续步骤出现一些玄学问题。重启后，再次用 sudo fdisk -l /dev/sda 检查，确认“Disklabel type”已经变成了 gpt。到这一步，你的磁盘就已经成功换上了支持EFI的“新地基”。

4. 第二步：打造EFI的“专用房间”——创建并挂载EFI系统分区

有了GPT分区表，接下来就需要为EFI引导程序准备一个“家”，这就是EFI系统分区（ESP）。这个分区有点特殊：它必须是FAT32格式，大小通常建议在100MB到512MB之间，并且需要被挂载到系统的 /boot/efi 目录下。

在vSphere环境中，我推荐一个更清晰、风险更低的做法：为ESP单独添加一块新的虚拟硬盘，而不是在原有的系统盘上调整分区。调整原有分区涉及到缩小文件系统等复杂操作，容易出错。而添加一块新盘，就像给房子扩建一个专门的小房间，简单又安全。

操作步骤如下：

1. 在vSphere中关闭目标Ubuntu虚拟机。
2. 编辑虚拟机设置，添加一块新的硬盘。大小设置为512MB（精简置备即可），其他保持默认。
3. 启动虚拟机。系统启动后，使用 lsblk 或 sudo fdisk -l 命令找到这块新硬盘。它通常会被识别为 /dev/sdb 或 /dev/sdc，具体取决于你原有磁盘的数量。我们假设新盘是 /dev/sdb。
4. 在新硬盘上创建分区。使用 fdisk 或更简单的 parted 工具。这里用 fdisk 演示：

   sudo fdisk /dev/sdb
   

   进入后，输入 n 新建分区，分区类型选默认的 p（主分区），分区号选 1，起始扇区和结束扇区都直接回车用默认值（这样会使用整个磁盘）。然后，至关重要的一步：输入 t 来更改分区类型。将分区类型设置为 EFI System，在 fdisk 里对应的类型代码是 1。输入 w 保存并退出。
5. 格式化这个分区为FAT32：

   sudo mkfs.fat -F 32 /dev/sdb1
   

   注意，这里的设备名是分区名 /dev/sdb1，而不是磁盘名 /dev/sdb。
6. 创建挂载点目录：

   sudo mkdir -p /boot/efi
   

7. 编辑 /etc/fstab 文件，实现开机自动挂载：

   sudo nano /etc/fstab
   

   在文件末尾添加一行：

   /dev/sdb1 /boot/efi vfat defaults 0 2
   

   注意：最后一个字段是 2，而不是根分区常见的 1。这表示该文件系统在非根文件系统之后被检查。
8. 执行挂载，并检查是否成功：

   sudo mount -a
   ls /boot/efi
   

   如果 ls 命令没有报错，显示一个空目录（或者已经有了一些EFI相关的文件），那么恭喜你，EFI分区的“房间”已经建好并且交付使用了。

5. 第三步：安装新的“导航系统”——配置GRUB for EFI

现在，“地基”（GPT）和“房间”（ESP）都准备好了，我们需要安装一个能在EFI环境下工作的引导程序，也就是GRUB的EFI版本。Ubuntu系统自带的GRUB是BIOS版本的，它不认识EFI这个“新环境”。

首先，我们尝试安装EFI版的GRUB。这个命令会告诉系统，把GRUB安装到我们刚刚创建的 /boot/efi 分区里：

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu

十有八九，你会在这里遇到第一个坑。 命令很可能会报错，提示类似于 grub-install: error: /usr/lib/grub/x86_64-efi/modinfo.sh doesn‘t exist. 这样的信息。别慌，这个错误非常典型。它并不是说你的命令错了，而是系统里压根还没安装 grub-efi-amd64 这个软件包。BIOS模式下默认安装的是 grub-pc 包。

解决办法很简单，安装缺失的包即可：

sudo apt update
sudo apt install grub-efi-amd64 -y

安装过程中，你可能会看到一个提示，问你是否要将GRUB安装到“可移动媒体的主引导记录”？这里一定要保持警惕！ 如果你是在转换一台物理机，可能需要仔细选择。但在vSphere虚拟机这个场景下，我们是通过vCenter层面去修改虚拟机的固件为EFI，GRUB会被安装到我们指定的ESP分区（/boot/efi）里，而不是磁盘的MBR。所以，在安装 grub-efi-amd64 时弹出的这个对话框，我通常选择“否”，避免不必要的写入。

安装完EFI版的GRUB包后，再次运行之前的 grub-install 命令。这次你应该能看到成功的提示，比如“Installation finished. No error reported.”

最后，我们需要让GRUB重新扫描你的系统，生成新的引导菜单配置文件。这个配置文件会列出你所有可启动的内核。运行：

sudo update-grub

这个命令会探测到你所有的操作系统（目前就一个Ubuntu）和可用的内核，并在 /boot/grub/grub.cfg 中生成配置。看到它成功识别出你的Linux镜像文件就对了。

6. 第四步：切换“启动开关”并验证成果

所有系统内部的改造都已经完成，现在是时候告诉vSphere：“嘿，这台虚拟机以后请用EFI方式启动它”。这个操作必须在虚拟机关机的状态下进行。

1. 在Ubuntu系统内，执行安全关机：

   sudo shutdown -h now
   

2. 等待虚拟机完全关闭后，在vSphere Client中，右键点击该虚拟机，选择“编辑设置”。
3. 找到“虚拟机选项” -> “引导选项”。你会看到“固件”这一项，当前应该是“BIOS”。把它下拉改为 “EFI”。
4. 保存设置。

接下来，就是激动人心的开机验证时刻。启动虚拟机。如果一切顺利，你会看到略微不同的启动画面（可能是一个GRUB的紫色背景菜单，而不是以前简单的黑白文字），然后系统正常进入登录界面。

如何确认真的成功切换到了EFI模式？ 我们有几种方法可以交叉验证，确保万无一失：

方法一：检查标志性目录（最直接） 再次登录系统，运行：

ls /sys/firmware/efi

如果这个目录存在，并且里面有一堆文件和子目录（如 efivars, fw_platform_size 等），那么毫无疑问，系统正运行在EFI模式下。这是最权威的检查方法。

方法二：查看内核启动日志 运行：

dmesg | grep -i efi

如果输出中包含“EFI v”这样的字样（例如 EFI v2.70 by VMware），那也是一个强有力的证据，表明内核在启动初期就识别到了EFI固件。

方法三：使用EFI专用工具 安装并运行 efibootmgr 工具：

sudo apt install efibootmgr -y
sudo efibootmgr

这个命令会列出EFI固件中管理的所有启动项。如果你能看到一个包含“ubuntu”字样的启动条目，并且命令没有报“EFI variables are not supported”的错误，那就100%确认是EFI模式了。

方法四：再次确认分区表 运行：

sudo parted -l | grep "Partition Table"

输出应该显示“Partition Table: gpt”，这与我们第一步的操作结果相符，形成了完整的证据链。

当你完成以上所有验证，并且系统运行稳定后，就可以回到vSphere，将之前创建的“Before_BIOS_to_EFI_Migration”快照删除了，释放存储空间。至此，整个迁移工作圆满结束。你的Ubuntu 24.04虚拟机已经脱胎换骨，完全准备好了去迎接像GPU直通这类需要EFI支持的现代硬件特性。整个过程就像给一台老车换上了全新的电控系统和导航，虽然步骤不少，但每一步都有清晰的路径和回退方案，实际操作起来并没有想象中那么可怕。