1. 这个报错到底在说什么黑屏只是表面现象如果你在VMware里装好Ubuntu 22.04某天开机发现卡在紫屏或黑屏左下角一行字写着Failed to mount /mnt/hgfs下面跟着Dependency failed for Local File Systems大概率会有点慌。我刚开始遇到也是反复重启结果每次都在同一个位置卡住。这里要先搞清楚一件事这个报错并不是系统坏了而是systemd在启动阶段有一个挂载任务失败了而它把整个启动流程给卡住了。/mnt/hgfs是VMware共享文件夹的默认挂载点。你在虚拟机设置里添加了共享文件夹之后VMware Tools或者open-vm-tools会在系统启动时把这个共享目录挂载到Ubuntu里。问题就出在启动时这三个字上——如果挂载动作发生得太早或者驱动模块没准备好挂载就会失败。而由于/mnt/hgfs在/etc/fstab里被声明成了一个需要开机挂载的文件系统它的失败会连带触发local-fs.target失败。local-fs.target是systemd里的一个同步点本地文件系统都挂载好了它才算完成。这个target失败意味着系统认为本地文件系统没准备好于是后续很多依赖它的服务不会启动。你在屏幕上看到的就是黑屏或者一个孤零零的dmesg错误然后什么都不动了。所以这其实是一个启动时序问题 配置问题的组合不是硬盘坏了也不是内核崩溃。这篇文章我会把完整排查链路、修复方案以及我踩过的坑都写清楚按顺序操作下来大概率能救活你的虚拟机。2. 为什么在我的机器上概率性出现几个容易踩的触发条件这个报错不是每次安装都会遇到。我复盘了几次在不同环境下的复现情况发现它有几个典型的触发条件你在排查的时候可以对照一下自己的环境。2.1 共享文件夹配置得太激进VMware的共享文件夹有三种挂载方式vmhgfs默认、vsock高速通道、或者通过open-vm-tools的vmware-hgfsclient工具挂载。默认方式下VMware Tools装好之后会在/etc/fstab里自动追加一行类似.host:/ /mnt/hgfs fuse.vmhgfs-fuse defaults,allow_other 0 0或者有时候是vmhgfs-fuse /mnt/hgfs fuse defaults,allow_other 0 0这行的存在本身没有问题问题在于systemd在解析fstab时会把这一行转换成一个mount unit并且在启动早期就去尝试挂载。如果这个时候VMware的hgfs模块还没出来或者open-vm-tools的服务还没就绪挂载必然失败。有意思的是我用VMware Workstation 16的时候这个时序问题相对少见换了Workstation 17之后反而出现得更多。一个合理的推测是新版VMware Tools的驱动加载顺序和旧版有差异导致fuse文件系统准备完成的时间点更晚。2.2 open-vm-tools 与 VMware Tools 的版本冲突Ubuntu 22.04默认的软件源里有open-vm-tools-desktop这个包。很多教程会告诉你直接apt install open-vm-tools-desktop就行但如果你之前在VMware菜单里点过重新安装VMware Tools然后系统里同时存在VMware官方打包的tools和open-vm-tools就会出现两个服务互相抢资源的情况。特别是当你手动编译过VMware Tools的内核模块后再用open-vm-tools内核模块的版本对不上hgfs驱动加载失败结果就是挂载失败报错卡启动。2.3 fstab里手动添加了非共享文件夹的挂载项还有一种情况是你自己手动在/etc/fstab里加了某个分区的挂载比如想把宿主机的一个目录通过其他方式挂进来结果UUID写错或者网络文件系统没起来那也会造成local-fs.target失败。这个不是hgfs本身的问题但报错是一样的。我遇到过一位朋友他在fstab里加了一个NTFS分区的挂载UUID复制错了启动时就报Dependency failed for Local File Systems一开始也以为是hgfs的问题结果排查下来是八竿子打不着的另一行配置。所以在动手之前第一步永远是要先看清楚失败的具体是哪个mount unit而不是看到一个错误名就开始操作。3. 完整的排查链路从黑屏到定位根因我不喜欢直接给答案因为很多情况下报错只是表象。下面是我自己复现问题时走的一条完整排查路径每一步都有明确目的你可以照着走一遍。3.1 先想办法进入shell如果卡在黑屏通常是CtrlAltF1到F6任意一个可以切到tty终端。VMware里你可以直接按CtrlAlt空格捕获键盘然后按CtrlAltF2看看能不能跳出登录提示符。如果连终端都不出来就在启动时按住Shift不放让GRUB菜单显示出来在Ubuntu那一项上按e进入编辑模式找到以linux开头的那一行在结尾加上systemd.unitrescue.target然后按CtrlX或F10启动就能进入救援模式。救援模式下会提示你输入root密码如果没设置过root密码用你安装时创建的用户名和密码登录再用sudo -i切换。如果加rescue.target也不行换成systemd.unitemergency.targetemergency是更底层的模式几乎不依赖任何服务。如果emergency都进不去那问题就不在hgfs而是内核启动早期就崩了这个另说。3.2 查看失败的服务和挂载单元进入shell之后第一件事不是改配置而是看日志systemctl --failed这条命令会列出所有启动失败的单元。如果里面有mnt-hgfs.mount那说明就是hgfs挂载失败导致的连锁反应。如果没有你就得看local-fs.target依赖了哪些东西用systemctl list-dependencies local-fs.target --all找到具体失败的mount单元后再针对性处理。接着看journal日志重点看启动阶段的消息journalctl -b -1 | grep -i hgfs如果是当前这次启动把-b -1换成-b。你会看到类似Failed to mount /mnt/hgfs或者vmhgfs-fuse: no such file or directory这基本能确认问题根源。3.3 检查内核模块hgfs的驱动模块名叫vmhgfs老版本或者vmw_vmci、vmw_vsock新版本的依赖模块。用lsmod | grep vm看看有没有相关的模块输出。如果什么都没有说明open-vm-tools的内核模块没加载成功或者根本没装上。用modprobe vmhgfs试试手动加载。如果提示Module not found那就是模块没装如果加载了但挂载还是失败那就是模块和工具的版本不匹配。3.4 手动挂载测试在shell里手动执行一次挂载看看真实报错mkdir -p /mnt/hgfs vmhgfs-fuse -o allow_other .host:/ /mnt/hgfs如果这条命令能成功挂载说明系统本身没问题纯粹是启动时序。如果它报了fuse: device not found说明fuse内核模块没加载如果报host:/ not found那可能是VMware设置里的共享文件夹名称有问题。另外用vmware-hgfsclient这个命令可以列出当前虚拟机能看到的共享文件夹列表。如果输出为空说明VMware Tools和宿主机的握手有问题得去重新装工具。3.5 确认fstab内容cat /etc/fstab看有没有和hgfs相关的挂载行。如果有后面要决定是保留还是注释掉。我个人的建议是如果你不依赖共享文件夹功能直接把这行注释掉是成本最低的解法。如果你确实需要共享文件夹看下一节的修复方案。4. 修复方案的取舍从循序渐进到一刀切排查确定根因之后下面是几条修复路线。按优先级从低到高排列你可以根据自己的场景选择。4.1 方案A注释掉fstab中的hgfs挂载行最小变动对于大多数人来说共享文件夹只是一个方便功能不是核心需求。如果你可以在VMware的虚拟机设置里取消共享文件夹或者只是想在Ubuntu里正常用系统那直接在fstab里注释掉是最稳的做法。编辑fstabsudo nano /etc/fstab找到hgfs相关行在前面加## .host:/ /mnt/hgfs fuse.vmhgfs-fuse defaults,allow_other 0 0保存退出然后重启。系统就会跳过这个挂载任务本地文件系统target也能正常完成黑屏问题直接消失。注意如果你以后在VMware里重新开启了共享文件夹功能但没把fstab这行取消注释共享文件夹不会被自动挂载。到时候你手动挂载一下就恢复不影响启动。4.2 方案B安装或修复 open-vm-tools如果你需要共享文件夹功能那就得让挂载能在启动时正确完成。最简单的方式是确保open-vm-tools-desktop安装正确sudo apt update sudo apt install open-vm-tools-desktop如果已经装了就重装一次sudo apt reinstall open-vm-tools-desktop装完之后检查一下服务状态systemctl status open-vm-tools.service systemctl status vmtoolsd.service确保两个服务都是active (running)。如果服务没起来手动启动sudo systemctl enable --now open-vm-tools.service vmtoolsd.service然后重新挂载sudo mount -a能挂上就说明修复成功。我实测中这个方案在大多数情况下能解决80%的问题。4.3 方案C处理残留的VMware Tools官方包如果你之前装过VMware官方发布的VMware Tools建议彻底清理sudo apt remove open-vm-tools open-vm-tools-desktop vmware-tools sudo vmware-uninstall-tools.plvmware-uninstall-tools.pl是VMware官方卸载脚本如果存在的话。执行完再重新安装open-vm-tools-desktop干净很多。我在一次实际故障处理中遇到的情况就是同时存在/usr/lib/vmware-tools和/usr/lib/open-vm-tools两套文件服务互相打架。清掉官方tools之后问题当场解决。4.4 方案D重启后仍然失败考虑覆盖安装内核模块有些情况是内核升级之后open-vm-tools的模块没有跟着重新编译。Ubuntu 22.04的内核是5.15偶尔大版本升级到6.x模块可能没同步。可以尝试sudo apt install --reinstall linux-modules-extra-$(uname -r) sudo apt install --reinstall open-vm-tools-desktop sudo update-initramfs -u然后重启验证。update-initramfs会把新的模块打包进initramfs确保启动早期就能加载。5. 黑屏但系统其实活着怎么看是不是假死偶尔你会遇到一种情况屏幕黑了但SSH能连进去或者journalctl能看到后面的日志还在输出。这说明不是完全死机只是显示层面被某个服务卡住了。这种情况下不要急着去改fstab或重装工具。先确认系统是否已经进入多用户模式systemctl get-default如果是graphical.target再检查图形界面服务systemctl status gdmUbuntu 22.04用的是GDMGNOME显示管理器。如果GDM挂了而系统已经起来你会看到黑屏但能ssh。这时候重启GDM即可sudo systemctl restart gdm如果你不需要图形界面直接改成多用户模式启动sudo systemctl set-default multi-user.target这样开机直接进命令行避免图形栈的问题。对服务器用途的虚拟机来说这是个非常实用的选择。我遇到过一种情况open-vm-tools的vmtoolsd服务在和GDM交互时发生竞争导致显卡驱动初始化失败屏幕一直黑的但ssh和所有服务都正常。切到multi-user.target之后一切恢复正常根本不用动fstab。6. 从报错看系统设计为什么一个挂载失败能让整个系统卡住如果你愿意多花几分钟理解背后的机制以后再遇到类似报错就不会慌。systemd的设计哲学里有一个很重要的概念叫依赖关系。它把所有启动任务拆分成一个个unit每个unit可以声明自己依赖哪些其他unit也可以声明自己想要哪些其他unit。依赖requires和想要wants的区别在于requires的unit如果失败依赖它的unit会被标记为failed而wants失败了不影响主unit继续执行。local-fs.target是一个聚合点所有本地文件系统的挂载unit比如/etc/fstab里声明的那些都通过Requiresxxx.mount挂到它下面。mnt-hgfs.mount就是从fstab自动生成的mount unit。一旦mnt-hgfs.mount失败systemd会认为local-fs.target的必需依赖没有满足于是local-fs.target也变成失败状态。而很多服务尤其是有图形界面的那些都Requireslocal-fs.target所以它们也不会启动。最终呈现出的现象就是黑屏、卡住、登录不了。用一句话概括一个次要功能共享文件夹的挂载失败通过systemd的依赖链放大成了系统级故障。这也是为什么修复思路里最简单的一招就是把这个次要功能去掉/注释掉——你不是在修一个功能你是在解除一个依赖锁。这个逻辑在Linux的世界里很常见排查问题的时候要时刻记住失败的原因不重要重要的是失败的unit影响了谁。7. 其他VMware环境下类似的启动异常根据搜索热词里很多人提到的问题我再补充几个相关场景虽然不是同一个报错但经常和hgfs问题一起出现。7.1 VMware Workstation 不可恢复错误 (vcpu-1)热词里提到的VMware workstation 不可恢复错误: (vcpu-1) exception 0xc0000005 (access violation)这个报错在Ubuntu 22.04虚拟机中也偶尔出现。它通常和嵌套虚拟化、显卡加速设置有关尤其当你关闭了虚拟机的3D加速但系统还残留有相关配置时容易触发。解决办法是进入虚拟机设置在显示器里勾选加速3D图形或在高级选项里关闭虚拟机内部EPTIntel处理器相关。如果你有多个快照回退到一个干净快照往往更快。7.2 共享文件夹挂载成功后权限不对即使你解决了启动报错共享文件夹还可能遇到权限问题。因为VMware的hgfs挂载默认会把所有文件映射为一个固定用户常见的是root或者当前登录用户。如果你在共享文件夹里创建文件发现宿主机的对应目录里文件所有者变了这是正常的。hgfs就是这样设计的跨越物理机的权限隔离靠的是宿主机侧的权限控制。想要让共享文件夹里的文件对宿主机和虚拟机都更友好可以在挂载时加uid1000,gid1000参数前提是1000是虚拟机的首个用户。在fstab里改成.host:/ /mnt/hgfs fuse.vmhgfs-fuse defaults,allow_other,uid1000,gid1000 0 07.3 虚拟机磁盘扩容后出现挂载失败如果你在VMware里把磁盘从50GB扩到了100GB然后Ubuntu里分区没扩展可能会导致某个挂载点失败。这个报错不一定带hgfs字样但表现也是Dependency failed for Local File Systems。这时候优先检查fstab里所有分区相关的行的UUID是否正确再检查分区表sudo fdisk -l sudo blkid确保fstab里的UUID和实际分区一致。8. 实操复盘一次完整的修复过程记录最后我把自己最近一次遇到这个报错的完整处理过程贴出来给你一个可以直接照着做的参考。机器环境VMware Workstation 17.6 Ubuntu 22.04.3 LTS虚拟机配置了共享文件夹宿主机是Windows 11。现象开机后黑屏左上角有错误信息只能强制关机。处理过程按住Shift重启进入GRUB按e编辑启动项在linux那行末尾加systemd.unitemergency.target按CtrlX进入紧急模式。用systemctl --failed看到mnt-hgfs.mount和local-fs.target失败。用lsmod | grep vmhgfs发现没有任何输出确认驱动没加载。执行modprobe vmhgfs提示Module not found。查看VMware Tools相关包dpkg -l | grep vmware发现竟然同时装了open-vm-tools和vmware-tools。执行sudo vmware-uninstall-tools.pl卸载官方tools。重新安装open-vm-tools-desktopsudo apt install --reinstall open-vm-tools-desktop手动挂载测试mkdir -p /mnt/hgfs vmhgfs-fuse -o allow_other .host:/ /mnt/hgfs挂载成功能看到宿主机共享目录的内容。执行mount -afstab里的挂载行也能顺利通过。重启系统正常进入桌面。这个例子就是典型的工具版本冲突导致的问题。如果你系统里只有open-vm-tools大概率在第3步就能看到模块已经加载直接跳到第9步就完事了。修复过程中有一个细节值得注意emergency模式默认会把文件系统挂载成只读如果你需要编辑fstab记得先mount -o remount,rw /不重新挂载为读写就开始改文件会提示只读文件系统白忙活。9. 最后的经验之谈这个报错我前前后后在不同机器上处理了不下十次有台机器甚至是在仓库里跑了一年多的服务器虚拟机某次大版本更新后突然出现同样的问题。之所以写这么多是因为这个错误卡住的是启动流程很多新手会误以为系统坏了直接重装其实大可不必。根据我的经验先确认失败的mount unit到底是什么永远是最重要的一步。很多人看到/mnt/hgfs就以为是共享文件夹的问题但如果你的fstab里还有其他挂载项鉴别失败目标才是根治的关键。还有一个小技巧我经常用修完之后不要急着反复重启验证先执行systemd-analyze verify检查所有unit的语法和依赖再执行mount -a测试fstab能不能全部通过。两步都正常了再重启。这样能避免修一个坑又踩另一个坑的情况。如果你把共享文件夹视为虚拟机的传输通道那修复它其实是为了让通道在正确的时机建立。VMware Tools在安装时会注册一个服务来管理这个通道open-vm-tools则是社区版的方式两者本质一样。理解了这层下次遇到就不会再被黑屏吓到了。