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
如果卡在黑屏，通常是Ctrl+Alt+F1到F6任意一个可以切到tty终端。VMware里你可以直接按Ctrl+Alt+空格捕获键盘，然后按Ctrl+Alt+F2，看看能不能跳出登录提示符。
如果连终端都不出来，就在启动时按住Shift不放，让GRUB菜单显示出来，在Ubuntu那一项上按e进入编辑模式，找到以linux开头的那一行，在结尾加上：
systemd.unit=rescue.target然后按Ctrl+X或F10启动，就能进入救援模式。救援模式下会提示你输入root密码，如果没设置过root密码，用你安装时创建的用户名和密码登录，再用sudo -i切换。
如果加rescue.target也不行，换成：
systemd.unit=emergency.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里注释掉是最稳的做法。
编辑fstab：
sudo 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用的是GDM（GNOME显示管理器）。如果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里声明的那些）都通过Requires=xxx.mount挂到它下面。mnt-hgfs.mount就是从fstab自动生成的mount unit。
一旦mnt-hgfs.mount失败，systemd会认为local-fs.target的必需依赖没有满足，于是local-fs.target也变成失败状态。而很多服务（尤其是有图形界面的那些）都Requires=local-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图形"，或在高级选项里关闭"虚拟机内部EPT"（Intel处理器相关）。如果你有多个快照，回退到一个干净快照往往更快。
7.2 共享文件夹挂载成功后权限不对
即使你解决了启动报错，共享文件夹还可能遇到权限问题。因为VMware的hgfs挂载默认会把所有文件映射为一个固定用户，常见的是root或者当前登录用户。
如果你在共享文件夹里创建文件，发现宿主机的对应目录里文件所有者变了，这是正常的。hgfs就是这样设计的，跨越物理机的权限隔离靠的是宿主机侧的权限控制。
想要让共享文件夹里的文件对宿主机和虚拟机都更友好，可以在挂载时加uid=1000,gid=1000参数（前提是1000是虚拟机的首个用户）。在fstab里改成：
.host:/ /mnt/hgfs fuse.vmhgfs-fuse defaults,allow_other,uid=1000,gid=1000 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.unit=emergency.target，按Ctrl+X进入紧急模式。 - 用
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。 - 执行：
卸载官方tools。sudo vmware-uninstall-tools.pl - 重新安装open-vm-tools-desktop：
sudo apt install --reinstall open-vm-tools-desktop - 手动挂载测试：
挂载成功，能看到宿主机共享目录的内容。mkdir -p /mnt/hgfs vmhgfs-fuse -o allow_other .host:/ /mnt/hgfs - 执行
mount -a，fstab里的挂载行也能顺利通过。 - 重启系统，正常进入桌面。
这个例子就是典型的"工具版本冲突"导致的问题。如果你系统里只有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则是社区版的方式，两者本质一样。理解了这层，下次遇到就不会再被黑屏吓到了。
