第一次遇到“EFI Network... TimeOut”这行字的时候我正坐在工位上往一台新配的台式机上装VMware Workstation。本来以为半小时能搞定环境结果屏幕上反复弹出网络启动超时的提示那一刻真是有点破防。后来弄清楚原因之后发现这个报错其实是VMware虚拟机在启动阶段最经典、也最容易被新手误判的问题之一——它跟网络没半点关系纯粹是虚拟机的固件设置和启动介质不匹配导致系统一路摸到了网络启动这一步。这篇内容我会把完整的前因后果、排查思路和几个实测可行的解决方法写清楚适合刚接触VMware虚拟机、被这个报错卡住的初学者也适合需要批量处理虚拟机配置的运维朋友参考。整个排查过程用到的工具就是VMware Workstation自带的功能和命令行工具不需要额外装任何插件。1. 先搞懂EFI Network TimeOut是怎么冒出来的1.1 报错现场的完整画面你在VMware里新建虚拟机、加载好系统镜像、点击“开启此虚拟机”之后如果一切正常屏幕上要么出现Windows的Logo要么出现Linux的GRUB引导菜单。但当虚拟机固件设置不对时屏幕会先闪一下VMware的LOGO接着跳出一行类似这样的提示EFI Network: TimeOut后面可能还会跟着类似“PXE-E53: No boot filename received”或者“Start PXE over IPv4”之类的字样。有些版本还会在右下角显示“Press ESC for boot menu”之类的提示。此时系统会停在那里不再继续引导看起来就像死机了实际上虚拟机还在运行。这行字的字面意思是EFI固件尝试通过网络从PXE服务器启动但是在超时时间内没有收到响应。这里的关键不是网络通不通而是“为什么会去尝试网络启动”。一台正常的物理机开机后如果硬盘里有系统BIOS固件绝不会跑到网卡启动这一步。虚拟机会走到这步说明虚拟机当前的启动项里找不到一个能用的启动设备。1.2 固件引导顺序才是真正的幕后推手VMware虚拟机和物理机一样都有两套固件类型传统BIOS也叫Legacy BIOS和UEFI在VMware里显示为EFI。两种固件都有自己的启动顺序列表。VMware Workstation在创建虚拟机时会基于“操作系统类型”这个选项自动分配一套默认固件。我遇到过最典型的情况就是在新建虚拟机时选择操作系统类型时选了“Microsoft Windows”但实际下载的镜像却是一个老旧的Windows安装包或者反过来选了“Linux”但用了只支持UEFI引导的镜像。VMware不会自动判断你挂载的ISO镜像支持哪种启动方式它只会按照预设的启动顺序往下走先看硬盘能不能引导再看光驱也就是挂载的ISO最后如果都不行就跳到EFI Network尝试从网络获取启动文件。整个流程可以类比成你早上出门先看公交卡在不在不在就看钱包里有没有零钱再没有就只能扫码骑共享单车。EFI Network就是固件眼里最后那辆“共享单车”——不到万不得已不会骑但真到了那一步骑不上就会原地等超时。1.3 为什么超时而不是直接报错失败很多读者可能疑惑既然是找不到启动设备直接提示“找不到启动设备”不就行了为什么要等一个超时这是EFI规范下“网络启动”这个环节的工作方式决定的。EFI固件会向局域网内广播DHCP请求等待DHCP服务器分配IP同时提供一个“下一跳启动文件”的位置。如果没等到DHCP响应固件必须等待一个固定时间才能放弃这个时间就是超时时间。VMware默认等待时间不算短大概几十秒到一分钟左右。所以从你点击开机到看到报错中间会有一种“等了好久才出结果”的感觉。这不是机器卡死而是固件在网络启动阶段老老实实地等完了一个完整周期。弄清楚这个机制之后你就会明白直接改固件的启动顺序或者固件类型比去检查物理网络要靠谱得多。注意如果你看到的是“EFI Network: TimeOut”而不是“No Boot Device”说明当前虚拟机的固件类型是EFI这基本可以断定问题出在固件和系统镜像的匹配关系上而不是硬盘没挂载。2. 核心解法把虚拟机的固件类型改成BIOS2.1 为什么要优先尝试改成BIOS市面上绝大多数Windows系统镜像包括Win 7、Win 10、Win Server系列甚至很多精简版Linux镜像都同时支持传统BIOS引导和UEFI引导。但更古老一些的镜像比如Win XP、Win 7早期版本或者一些经过定制封装的Ghost版系统往往只支持传统BIOS引导。VMware Workstation在创建虚拟机时如果你选的操作系统是“Windows 7”默认固件是BIOS但如果选的是“Windows 10”或更新的系统默认固件可能是EFI。问题就出在这里你以为选了正确的系统类型但用旧镜像安装时固件按EFI模式找启动文件镜像里根本没有EFI引导文件于是只能一路向下走到网络启动。把固件改成BIOS后虚拟机就会改用传统方式寻找启动文件目标位置从“EFI分区中的.efi文件”变成“磁盘主引导记录MBR中的引导代码”。对于绝大多数ISO镜像来说两种模式都有对应的文件但MBR方式更普适兼容性最好。所以我的建议是遇到EFI Network TimeOut不要犹豫第一选择就是改成BIOS试试。2.2 新建虚拟机时如何避开这个坑如果你还没创建虚拟机那处理起来最省事。在VMware Workstation的“新建虚拟机向导”中选择“自定义高级”模式这样可以手动设置虚拟硬件参数。具体步骤如下点击“文件”菜单选择“新建虚拟机”。向导类型选择“自定义高级”这能比“典型”模式多出不少手动配置项。一直点到“固件类型”这一步。有的版本这一项叫“固件类型”有的版本在“虚拟机设置”里叫“操作系统”选项卡下。选择“BIOS”而不是“UEFI”然后继续完成后续设置。如果你的VMware Workstation版本较新向导会自动为你选择固件类型。比如选择“Windows 10 x64”时向导往往默认“UEFI”这本身没问题前提是你的ISO镜像确实支持UEFI引导。如果你不确定镜像支不支持最稳妥的办法就是手动选“BIOS”。我实操中经常这样区分如果你用的镜像是从微软官网下载的原版ISO那选UEFI或BIOS都行如果你用的是各种论坛封装版、Ghost版或者一些老系统镜像一律选BIOS。这个经验我用到现在没有出过差错。2.3 虚拟机已经创建好了改哪里如果虚拟机已经建好并且已经出现EFI Network TimeOut修改起来也不难。分两步走第一步右键点击虚拟机标签页选择“设置”或者选中虚拟机后点击“编辑虚拟机设置”。在“选项”选项卡中找到“高级”右侧能看到“固件类型”这一栏。如果当前显示的是“UEFI”把它改成“BIOS”。确认后虚拟机电源状态如果处于开启需要先关机再改否则无法修改。第二步把启动介质放回光驱。重新打开“虚拟机设置”在“CD/DVD”一项里确认“连接”选择的是“使用ISO映像文件”并重新浏览选择一次你的系统镜像。设置好后再次启动虚拟机画面应该会出现熟悉的系统安装界面而不是卡在EFI Network。整个过程大概一分钟只需要改一个选项但很多新手就是找不到这个入口。注意修改固件类型后已安装好的系统可能会无法启动。因为系统已经按UEFI模式安装了引导管理器改成BIOS后MBR里没有引导代码就会出现“Bootmgr is missing”或者直接黑屏。如果你只是刚开始安装系统、还没装完那随便改没关系。如果系统已经装好了想从UEFI转BIOS需要单独处理引导文件不是本文重点。3. 不改BIOS也行让EFI引导顺序里出现正确的启动项3.1 你的ISO可能支持UEFI但你需要把它“放进”启动顺序有些情况并不需要改成BIOS。比如你手里是一个支持UEFI引导的最新版Windows 10/11 ISO或者Ubuntu 20.04以上的官方镜像那固件保持EFI完全没问题。之所以还会出现EFI Network TimeOut只是因为虚拟机启动顺序里光驱排在硬盘后面而硬盘是空的光驱里的ISO又因为某种原因没有被识别为有效的EFI启动设备。这种时候正确的做法不是改固件类型而是检查启动顺序。在虚拟机设置里选择“选项”选项卡找到“高级”的右侧区域或者通过“虚拟机”菜单“电源”→“打开电源时进入固件”进入虚拟机的BIOS/UEFI界面调整启动顺序。在VMware Workstation里一个更简单的操作是启动虚拟机时快速连续点击屏幕直到出现“Press ESC for boot menu”的提示按ESC直接调出启动菜单手动选择“CD-ROM Drive”启动。这样就能一次性绕过启动顺序的问题让ISO直接引导安装。3.2 用vmrun命令行验证和修改固件类型的另一种方式如果你要处理的是大量虚拟机或者想通过脚本快速修正配置VMware Workstation自带的vmrun命令行工具和虚拟机配置文件修改技巧会高效很多。每个虚拟机都有一个.vmx配置文件记事本打开后找到这样一行firmware efi把它改成firmware bios保存前记得确认虚拟机处于关机状态。然后重新用VMware Workstation打开这个虚拟机固件类型就会改变。这个方法适合批量处理也适合在文本编辑时顺手排查其他配置问题。我也遇到过一种情况.vmx文件里根本没有“firmware”这一行。这时默认固件是BIOS说明当前配置已经是BIOS那么EFI Network TimeOut的出现就和固件类型无关。此时应该往“挂载的镜像是否可引导”方向排查。3.3 怎样快速判断一个ISO镜像的引导模式判断ISO支持哪种引导模式不需要专门去读引导扇区。最简单的办法是直接解压ISO看根目录下有没有一个名为“efi”的文件夹。有说明支持UEFI没有那它走的就是传统BIOS引导。以Windows 10官方ISO为例解压后你能看到“efi”和“sources”等文件夹。老的Windows 7 ISO尤其是早期版本根目录下则没有“efi”文件夹。Linux发行版的ISO也类似Ubuntu 20.04的ISO里有“EFI”目录而一些精简镜像可能只有“isolinux”之类的目录。把这个判断方法记住之后你就不会再纠结选哪个固件了有“efi”目录的镜像两种固件都能用没有“efi”目录的只能选BIOS。注意有些双启动ISO同时支持BIOS和UEFI在UEFI模式下引导时界面会和BIOS模式不完全一样有些选项会隐藏。如果你在UEFI引导的安装界面里找不到某个功能可以退回去改用BIOS引导试试很多时候不是什么系统缺陷只是引导模式导致的界面差异。4. 更隐蔽的坑ISO引导方式与固件不匹配的其他场景4.1 同一种报错可能来自不完全一样的原因EFI Network TimeOut这个报错虽然指向明确但触发它的场景不止“固件类型不匹配”这一种。我整理几个实际遇到过的场景方便你对照排查场景一ISO镜像没有EFI引导文件但虚拟机的固件是EFI。这是最常见的原因按第2节改成BIOS即可。场景二ISO镜像支持EFI引导但虚拟机光驱控制器类型或总线位置不被EFI识别。常见于光驱挂载在IDE控制器上而EFI固件只认SATA控制器。这时候可以把CD/DVD的“虚拟设备节点”改成SATA重新启动。场景三ISO镜像没问题、固件类型也没问题但是启动顺序里光驱排在硬盘之后而硬盘又是空盘。有些固件版本不会因为第一个硬盘为空自动跳到光驱而是直接跳到网络。此时用ESC启动菜单手动选光驱即可。场景四ISO文件本身损坏或者下载不完整。这会导致固件无法从CD中读取引导信息最终也走向网络启动。排查方法是用校验工具核对ISO的SHA256值或者换个来源重新下载。4.2 为什么Windows 10默认UEFI反而更容易踩这个坑从Windows 8开始微软把“UEFI安全启动”作为预装系统的标配很多国内用户手里的Windows 10/11镜像都附带了完整的EFI引导结构。这类镜像在VMware里自动匹配EFI固件没问题。但在网上随便下载的精简版、优化版、装机版镜像很多制作时去掉了EFI引导文件只留下传统BIOS引导。所以在网上看帖子会发现很多人“装了Win 10却遇到EFI Network TimeOut”这不是因为他们操作失误而是镜像的问题。镜像作者为了兼容性往往只保留一种引导方式你拿到手之后必须根据镜像实际的引导文件去设置虚拟机固件。这提醒我们一个很实际的原则不要迷信“新系统一定用UEFI”的印象流一切以镜像里实际有什么文件为准。动手之前先解压看一眼能省掉至少半小时的瞎折腾。4.3 物理机上的类似问题为什么少见有人可能会问物理机装系统时为什么很少看到这种提示因为物理机的BIOS/UEFI设置里通常有明确的“启动优先级”列表每个启动项是独立配置的光驱、硬盘、网卡分开排列。就算硬盘没系统光驱也能正常引导。虚拟机里的EFI固件则更精简启动项之间的优先级规则和物理机不完全一样而且VMware Workstation的虚拟EFI固件对不同设备的支持程度有细微差别。我的理解是VMware为了简化用户体验把启动设备扫描做得比较“聪明”宁可跳到网络也不卡在光驱上。这种设计平时没感觉但遇到不匹配的镜像时就会暴露出来。理解了这一点你就能明白为什么网上的教程总是强调“手动选启动菜单”因为在虚拟机场景里手动选择往往比设置优先级更可靠。5. 实操中容易忽略的连带问题与工作习惯5.1 改完固件后镜像盘符对不上先别慌把固件从EFI改成BIOSWindows安装程序可能会重新分配盘符。比如原来UEFI模式下你看到的是“磁盘0分区1”改成BIOS后安装界面里分区显示会变少可能只剩“未分配空间”。这不是虚拟机坏了而是Windows安装程序在两种引导模式下对分区表的解读方式不同。特别是如果你在UEFI模式下已经对硬盘分过区改成BIOS后这些分区可能“消失”——其实数据还在只是BIOS模式下安装程序不认识GPT分区表上的EFI分区。解决方法是如果要装64位Win 7或更新的系统建议安装前把虚拟硬盘清空让Windows安装程序自动用对应模式分区如果需要保留数据那就别改固件改用第3节的方法。5.2 常见问题速查表我根据实际经验整理了一个速查表适合出手排查时报错时间紧的情况现象可能原因优先处理方式EFI Network TimeOut BIOS固件光驱控制器不被识别把CD/DVD控制器改为SATAEFI Network TimeOut 新Win10 ISO启动顺序光驱靠后开机按ESC手动选CD-ROMEFI Network TimeOut 老Win7 ISO固件默认为EFI镜像不支持修改固件类型为BIOSEFI Network TimeOut Linux ISO镜像只支持BIOS引导修改固件类型为BIOSEFI Network TimeOut 已装好系统系统引导文件损坏重新修复引导文件而不是改固件这张表覆盖了我遇到过的大部分情况。如果按表处理还没解决建议把虚拟机的.vmx文件打开把“ethernet0.present”从“TRUE”改成“FALSE”彻底移除网卡。这样EFI固件就没有网络设备可用了会直接跳过网络启动这个步骤报错会变成更直白的“无法找到启动设备”方便进一步定位问题。5.3 几个值得养成的虚拟机安装习惯踩过这么多次的坑我总结出几个比较实用的习惯分享出来供参考第一创建虚拟机时选“自定义高级”模式不要用“典型”模式。典型模式会自动帮你选好固件和硬件参数省事是省事但出了问题反而更难排查。自定义模式至少能让你清楚每个参数是什么。第二手边常备一个支持双引导的最小Linux ISO比如Ubuntu Server版或Debian网络安装版。它既可以用来测试虚拟机的启动链路是否正常也可以在排查时区分“固件问题”还是“镜像问题”。如果连这个ISO都启动不了那基本是虚拟机本身配置问题如果能启动说明就是镜像不匹配。第三安装系统前先拍一个虚拟机快照。VMware Workstation的“快照”功能在安装系统前特别好用。装坏了、引导出问题了一键恢复省去重建虚拟机的时间。不要觉得这是多此一举我见过的很多问题最后都是靠快照“悔棋”解决的。第四能用命令行就不反复点鼠标。修改.vmx文件、用vmrun命令启动虚拟机熟练掌握之后不仅快还方便在论坛里贴出配置截图求助别人一眼就能看出问题。对于经常折腾虚拟机的人来说这是一项性价比很高的技能。5.4 装好系统之后记得把ISO从光驱里拿出来这个问题不算致命但很容易忽视。系统装好后如果你不把光驱里的ISO断开下次开机时会发现VMware又去读了一遍光盘。虽然不会再出现EFI Network TimeOut但每次启动都会多等几秒有时还会干扰到Windows的启动流程。正确做法是系统安装完成后右键点击虚拟机“设置”在“CD/DVD”里选择“断开连接”或者“使用物理驱动器”确保启动时不会重新挂载ISO。这一步看似无关紧要但对于追求干净环境的开发者来说属于基本素养。另外如果你用的是ESXi或者VCSA这类服务器级产品处理思路其实和Workstation是一致的检查虚拟机的启动选项确认固件类型和镜像引导方式匹配。不同管理界面中入口位置不一样但原理完全通用。6. 写在最后的经验之谈:这份折腾其实很值得EFI Network TimeOut这个报错看起来可怕理解之后其实就是固件引导程序在找不到启动设备时的一次“求救信号”。搞懂它之后你对虚拟机的启动机制会有一个全新的理解——你不再是机械地跟着教程点鼠标而是真正明白每一步在干什么。我个人实际使用中最大的体会是VMware虚拟机的报错信息虽然看着乱但几乎都能从虚拟硬件配置层面找到答案。网络超时、启动失败、硬盘无法访问这些看上去是系统层面问题九成以上都是虚拟机硬件参数设置出了问题。养成“先看配置再怀疑系统”的思维习惯能帮你省下大量排查时间。如果你照着上面的方法试了一圈还是卡在EFI Network TimeOut那很可能是下载的镜像文件本身有问题。重新下载或者换一个官方镜像源大概率能解决。我自己遇到过两三次折腾半天发现就是镜像损坏重新下载后问题瞬间消失那一刻真的觉得前面的排查也都值了。