遇到Failed to mount /mnt/hgfs和Dependency failed for Local File Systems这个组合报错基本可以确定是VMware共享文件夹机制和Ubuntu 22.04的启动流程打架了。这不是系统坏了也犯不上重装虚拟机。这篇文章我会从问题根源讲起给出一条从恢复模式进root、注释fstab残留项、重装open-vm-tools到恢复共享文件夹挂载的完整处理路径。刚被黑屏卡住的新手可以直接对照操作被这问题反复折腾过、每次升级内核后就复发的读者也能在这里找到原因。1. 先搞明白“黑屏挂载失败”是怎么来的1.1 从报错信息反推启动链路Ubuntu 22.04使用systemd管理开机流程整个启动过程是以“目标单元”为节点串起来的。local-fs.target是其中一个关键节点它负责确认所有本地文件系统挂载完毕、可以正常读写。你可以把它理解成一个宴会开席前的“服务员集合点”——只有所有服务员都到位了宴会才敢正式开始。systemd也一样只要某个挂载项失败local-fs.target就会进入failed状态接下来依赖它的服务全部遭殃。你在黑屏上看到的那句Failed to mount /mnt/hgfs就是在告诉systemd有一个挂载任务失败了。后面那句Dependency failed for Local File Systems就是local-fs.target这个节点本身宣布失败。此时图形界面GDM还没有拿到启动权限Ubuntu默认的splash画面又只显示logo于是你看到的就是一块黑屏或者卡在logo界面不动。整个过程不是死机而是systemd在等待一个永远完不成的挂载任务最终因依赖关系连锁失败。这里有个关键认知这个错误根本不是硬盘故障也不是Ubuntu系统本身损坏。它跟VMware的共享文件夹机制强相关。只要把挂载链路修好系统就能正常进桌面。我见过太多人一看到Dependency failed就重装系统其实完全没到那一步。1.2 共享文件夹在VMware里的真实实现在VMware Workstation中配置了共享文件夹后宿主机目录会通过VMware Tools组件映射到虚拟机内的/mnt/hgfs。这个挂载动作有两种实现方式一种是传统的内核模块vmhgfs.ko另一种是更现代的用户态方案vmhgfs-fuse。无论哪种方式都需要一个前提——open-vm-tools或者VMware官方Tools正确安装并能运行。实际工作中挂载失败通常逃不出这三种情况fstab里残留了挂载项但对应的服务或模块根本没启动open-vm-tools未安装、损坏或者版本太旧VMware共享开关虽然开着Linux侧却没人干活升级内核后vmhgfs内核模块没跟上新内核版本出现模块缺失或CRC校验失败。打个比方宿主机共享目录是仓库里的货/mnt/hgfs是收货口vmhgfs模块是叉车。现在调度表fstab上写着“三号叉车给一区送货”但三号叉车今天根本不在岗内核模块没加载调度台只能一直干等。系统启动流程就是这么卡住的。2. 修复流程先让系统能进桌面再谈共享文件夹2.1 从GRUB恢复模式进入root shell修复的第一步是拿到一个有写入权限的root shell。重启虚拟机在开机画面出现时快速按Shift或者连续点Esc。VMware里GRUB菜单显示窗口很短动作慢了就直接进系统了所以我通常的做法是开机后立刻把手放在按键上连按宁可多按几下也别错过。进入GRUB菜单后选择“Advanced options for Ubuntu”然后找到带“recovery mode”的内核条目。回车后你会看到一个蓝色界面的Recovery Menu里面有一系列选项选中“root”并回车就进入了root shell。这里有个细节此时根文件系统是只读挂载的必须先执行mount -o rw,remount /让它可写否则后面所有修改fstab和apt安装操作都会报“read-only file system”。如果你在Recovery Menu里找不到root选项也可以按CtrlAltF3切换到纯文本终端用普通账号登录后执行sudo。核心目标只有一个拿到一个能写文件的shell。只要能做到这台虚拟机就有救。2.2 第一步永远是注释fstab里的残留挂载项拿到root shell后先看/etc/fstab。一般情况下你会看到类似这样的行.host:/ /mnt/hgfs fuse.vmhgfs-fuse defaults 0 0或者早期一些的写法vmhgfs-fuse /mnt/hgfs fuse defaults 0 0这行配置不一定是使用者亲手写的。有些版本的open-vm-tools在启用共享文件夹时会自动向fstab追加挂载项系统升级后环境变了这行就成了地雷。我处理这类问题的顺序是不管三七二十一先把含hgfs的行注释掉让启动链路先恢复健康再谈后续恢复功能。操作上直接用nano /etc/fstab最直观在对应行前面加#保存退出。如果用sed注意点号转义命令大致是sed -i s|^\.host:/|#.host:/| /etc/fstab为什么坚持“先注释”而不是“先重装”因为重装open-vm-tools后旧内核下模块加载未必能立即生效系统启动到挂载步骤照样会失败或长时间等待。先把失败源从启动链路上摘掉让系统能正常开机是最快的止损手段。注释不等于放弃共享文件夹只要你愿意修好服务后可以随时恢复这一行。2.3 重装open-vm-tools并验证内核模块注释完fstab后在root shell中执行apt update apt install --reinstall open-vm-tools open-vm-tools-desktop这里多说一句为什么强调用open-vm-tools而不是VMware官方安装包。Ubuntu 22.04的仓库里维护的open-vm-tools会跟随系统更新和内核版本保持同步。而VMware官方tarball安装的vmware-tools在Ubuntu每次发新内核后很容易出现模块不匹配的问题这是很多“升级后黑屏”案例的根源。装完后验证三件事。第一内核模块能否正常加载modprobe vmhgfs没有输出就说明模块加载正常。第二服务是否启动systemctl status open-vm-tools如果服务没跑起来用systemctl enable --now open-vm-tools启动并设置开机自启。第三用vmware-hgfsclient列出宿主机共享目录vmware-hgfsclient这条命令会返回你在VMware Workstation里配置的所有共享文件夹名称。如果返回为空回到VMware菜单里检查Shared Folders是否处于Always enabled状态这个开关没打开Linux侧怎么折腾都白搭。2.4 重启后的正确共享文件夹挂载配置修好Tools后别急着把fstab原样写回去。先手动验证挂载是否正常再考虑自动化。手动挂载命令sudo mkdir -p /mnt/hgfs sudo vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other,uid1000,gid1000如果不报错ls /mnt/hgfs能看到宿主目录说明整条链路已经通了。此时再决定是否写回fstab。如果需要开机自动挂载推荐写法是.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other,defaults,uid1000,gid1000 0 0我见过不少人纠结用vmhgfs内核模块方式还是vmhgfs-fuse方式这里直接给结论Ubuntu 22.04推荐fuse方式。因为传统的内核模块方式在新内核升级后经常出问题而fuse方案是用户态进程不依赖内核模块编译稳定性好很多。两者对比可以看下表。挂载方式依赖组件常见问题稳定性传统vmhgfs内核模块vmhgfs.ko内核升级后模块未重编加载失败一般vmhgfs-fuseopen-vm-tools用户态程序需确保fusermount权限和open-vm-tools已安装更稳定3. 实际操作记录从黑屏到恢复桌面的完整过程3.1 问题现场还原下面这场操作我实打实走过一遍。虚拟机环境是VMware Workstation 17 Pro客户机Ubuntu 22.04.2之前一切正常Windows宿主机上配了一个共享目录映射到虚拟机内的 /mnt/hgfs。某天执行apt upgrade后重启虚拟机开机后迟迟不出桌面屏幕最终停在一行Failed to mount /mnt/hgfs紧接着就是那句Dependency failed for Local File Systems。第一反应不是重装而是先ping一下这台虚拟机的IP——居然通了。这里给你一个判断依据如果虚拟机IP能ping通说明内核、网络服务都起来了系统不是真死只是桌面没起来。这种情况下按本文流程修就能解决。如果ping不通那是内核阶段就崩了问题性质完全不同需要走Live CD修复流程不在本文讨论范围。3.2 一步步操作实录我按当时实际敲命令的顺序记录下来你可以完全照着做。第一步重启虚拟机。开机画面出现时不停按Shift进入GRUB菜单选Advanced options for Ubuntu再选带recovery mode的内核在Recovery Menu里选root。进入root shell后立刻执行mount -o rw,remount /第二步查看fstab内容cat /etc/fstab屏幕上出现了一行典型的残留配置.host:/ /mnt/hgfs fuse.vmhgfs-fuse defaults 0 0我用nano打开fstab在这一行最前面加了一个#保存退出。稳妥起见又执行一遍cat /etc/fstab复查确认注释生效。第三步重装工具包apt update apt install --reinstall open-vm-tools open-vm-tools-desktop等待安装结束后验证模块加载modprobe vmhgfs命令执行后没有任何输出说明模块正常。接着又确认了服务状态和服务启动systemctl enable --now open-vm-tools systemctl status open-vm-tools服务显示active (running)这步通过。第四步重启虚拟机reboot这次启动很顺利没再看到那行碍眼的错误桌面正常出现。登录后我用journalctl -b -p err检查本次启动的错误日志确认没有新的挂载失败记录。第五步恢复共享目录。回到VMware菜单确认Shared Folders开关仍处于Always enabled。然后在虚拟机里执行sudo mkdir -p /mnt/hgfs sudo vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other,uid1000,gid1000执行后/mnt/hgfs里出现了宿主机的共享文件夹一切恢复原状。3.3 如果fstab里根本没有hgfs行问题在哪如果你按上面的方法打开fstab发现里面压根没有hgfs相关行那问题就另当别论了。这种情况我遇到过几次fstab是干净的但系统里安装了旧版vmware-tools的init脚本或者某个systemd服务里残留了挂载指令一样会报这个错。这时候别只盯着屏幕上最后一行的hgfs报错要一次看全部失败项journalctl -b | grep -i fail我见过最典型的案例是fstab里某个UUID写错了比如分区UUID和实际对不上local-fs.target一样失败而hgfs报错只是恰好显示在屏幕末尾给人造成是hgfs导致一切的错觉。排查时可以用这两个命令定位真实问题systemd-analyze blame systemd-analyze critical-chain local-fs.targetblame按耗时排序显示启动阶段每个单元的耗时critical-chain显示目标单元的依赖链。依赖链上一目了然哪个环节failed就是罪魁祸首主意直接打到那一个环节上。4. 常见问题与排查技巧实录Failed to mount /mnt/hgfs速查表4.1 问题速查表把几个月来处理过的相关咨询和踩坑经验整理成一张表方便你直接对号入座。现象原因处理办法一直黑屏但虚拟机IP能ping通挂载失败导致systemd等待桌面没起来按CtrlAltF3切TTY注释fstab重装open-vm-tools报错后进入emergency modefstab里有无效挂载项recovery模式进入root修复fstab或恢复快照modprobe vmhgfs报module not found内核模块未安装或与当前内核不匹配安装linux-headers重装open-vm-tools或open-vm-tools-dkms/mnt/hgfs目录不存在open-vm-tools服务未启动或VMware共享开关未开启systemctl enable --now open-vm-tools检查VMware Shared Folders配置桌面黑屏但CtrlAltF3能切到终端GDM或桌面会话服务失败重装gdm3或ubuntu-desktop必要时切换Xorg会话复制粘贴、窗口自适应失效缺open-vm-tools-desktop包apt install open-vm-tools-desktop这张表里的第三行尤其重要。很多人升级内核后复发就是因为在新的内核目录下找不到vmhgfs模块。你可以在重启前主动检查ls /lib/modules/$(uname -r)/misc | grep vmhgfs如果这个目录下没有vmhgfs相关文件说明新内核缺少模块重启后必挂。4.2 三个实操中容易踩的坑第一个坑只注释fstab不重装Tools。这种情况我当时见过不止一次用户把fstab里的挂载行注释掉系统能启动了就以为完事了。结果VMware里的共享文件夹开关还开着某些版本的open-vm-tools会在下次重启时重新注入挂载配置问题又回来了。正确做法是注释fstab和重装open-vm-tools同时做缺一不可。第二个坑直接删除fstab里的那行而不是注释。删除虽然也能让系统启动但以后想恢复共享文件夹时你得重新复习挂载配置的正确写法。以我自己的习惯注释行保留着反而是个提示这里曾经挂载过共享目录以后环境变了也知道去哪改。删除一旦误删其他行恢复起来更麻烦。第三个坑升级内核后不管模块状态就重启。Ubuntu 22.04使用HWE内核机制apt upgrade很可能把内核版本更换掉。升级后如果不确认vmhgfs模块是否匹配新内核重启大概率回到黑屏状态。我现在养成一个习惯升级完先不急着重启执行一遍uname -a和ls /lib/modules/$(uname -r)/misc | grep vmhgfs确认新内核有共享目录模块再执行reboot。5. 避免以后重启再黑屏内核升级与快照习惯5.1 内核升级前后记住这三条把下面这套动作变成例行公事基本能把这类问题堵在门外。升级前在VMware里先给虚拟机拍快照。右键虚拟机 - Snapshot - Take Snapshot整个过程不影响虚拟机关机状态下的文件也可以开着机直接拍。有这个快照垫底后面升级装包再出什么幺蛾子回滚只需要一分钟。升级后、重启前检查新内核的模块目录和当前内核是否一致uname -r ls /lib/modules/$(uname -r)/misc | grep vmhgfs modinfo vmhgfs如果查到模块缺失执行apt install --reinstall open-vm-tools open-vm-tools-desktop或者安装open-vm-tools-dkms重新构建模块。确认无误后再重启。这一套流程本质上就是把“不等重启发现黑屏”变成“重启前主动排雷”看起来多花两分钟实际省下的是黑屏后半小时的折腾。5.2 现实一点的建议fstab别写太满再分享一个我自己的习惯共享文件夹不一定要写进fstab。如果你只是偶尔传个文件完全可以在需要的时候手动执行vmhgfs-fuse挂载用完再umount。这样fstab里少一行启动阶段就少一个失败点系统也更干净。如果确实需要开机自动挂载建议在fstab里加上nofail选项.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other,defaults,uid1000,gid1000,nofail 0 0加上nofail后即使这个挂载项失败了systemd也只会把它标记为失败不会拖累整个local-fs.target。这笔交易很划算你不需要在功能性和启动成功率之间二选一。最后说个私心话我现在看到Ubuntu 22.04虚拟机报这个错第一反应永远是进恢复模式看fstab。90%以上的“Dependency failed for Local File Systems”最后查出来都是fstab挂载项和VMware Tools之间打架。别被那句“Dependency failed”吓到它不过是个传话的真正的问题藏在fstab和服务状态里。把这两样搞明白了这个坑你以后基本不会再踩第二次。
遇到Failed to mount /mnt/hgfs和Dependency failed for Local File Systems这个组合报错基本可以确定是VMware共享文件夹机制和Ubuntu 22.04的启动流程打架了。这不是系统坏了也犯不上重装虚拟机。这篇文章我会从问题根源讲起给出一条从恢复模式进root、注释fstab残留项、重装open-vm-tools到恢复共享文件夹挂载的完整处理路径。刚被黑屏卡住的新手可以直接对照操作被这问题反复折腾过、每次升级内核后就复发的读者也能在这里找到原因。1. 先搞明白“黑屏挂载失败”是怎么来的1.1 从报错信息反推启动链路Ubuntu 22.04使用systemd管理开机流程整个启动过程是以“目标单元”为节点串起来的。local-fs.target是其中一个关键节点它负责确认所有本地文件系统挂载完毕、可以正常读写。你可以把它理解成一个宴会开席前的“服务员集合点”——只有所有服务员都到位了宴会才敢正式开始。systemd也一样只要某个挂载项失败local-fs.target就会进入failed状态接下来依赖它的服务全部遭殃。你在黑屏上看到的那句Failed to mount /mnt/hgfs就是在告诉systemd有一个挂载任务失败了。后面那句Dependency failed for Local File Systems就是local-fs.target这个节点本身宣布失败。此时图形界面GDM还没有拿到启动权限Ubuntu默认的splash画面又只显示logo于是你看到的就是一块黑屏或者卡在logo界面不动。整个过程不是死机而是systemd在等待一个永远完不成的挂载任务最终因依赖关系连锁失败。这里有个关键认知这个错误根本不是硬盘故障也不是Ubuntu系统本身损坏。它跟VMware的共享文件夹机制强相关。只要把挂载链路修好系统就能正常进桌面。我见过太多人一看到Dependency failed就重装系统其实完全没到那一步。1.2 共享文件夹在VMware里的真实实现在VMware Workstation中配置了共享文件夹后宿主机目录会通过VMware Tools组件映射到虚拟机内的/mnt/hgfs。这个挂载动作有两种实现方式一种是传统的内核模块vmhgfs.ko另一种是更现代的用户态方案vmhgfs-fuse。无论哪种方式都需要一个前提——open-vm-tools或者VMware官方Tools正确安装并能运行。实际工作中挂载失败通常逃不出这三种情况fstab里残留了挂载项但对应的服务或模块根本没启动open-vm-tools未安装、损坏或者版本太旧VMware共享开关虽然开着Linux侧却没人干活升级内核后vmhgfs内核模块没跟上新内核版本出现模块缺失或CRC校验失败。打个比方宿主机共享目录是仓库里的货/mnt/hgfs是收货口vmhgfs模块是叉车。现在调度表fstab上写着“三号叉车给一区送货”但三号叉车今天根本不在岗内核模块没加载调度台只能一直干等。系统启动流程就是这么卡住的。2. 修复流程先让系统能进桌面再谈共享文件夹2.1 从GRUB恢复模式进入root shell修复的第一步是拿到一个有写入权限的root shell。重启虚拟机在开机画面出现时快速按Shift或者连续点Esc。VMware里GRUB菜单显示窗口很短动作慢了就直接进系统了所以我通常的做法是开机后立刻把手放在按键上连按宁可多按几下也别错过。进入GRUB菜单后选择“Advanced options for Ubuntu”然后找到带“recovery mode”的内核条目。回车后你会看到一个蓝色界面的Recovery Menu里面有一系列选项选中“root”并回车就进入了root shell。这里有个细节此时根文件系统是只读挂载的必须先执行mount -o rw,remount /让它可写否则后面所有修改fstab和apt安装操作都会报“read-only file system”。如果你在Recovery Menu里找不到root选项也可以按CtrlAltF3切换到纯文本终端用普通账号登录后执行sudo。核心目标只有一个拿到一个能写文件的shell。只要能做到这台虚拟机就有救。2.2 第一步永远是注释fstab里的残留挂载项拿到root shell后先看/etc/fstab。一般情况下你会看到类似这样的行.host:/ /mnt/hgfs fuse.vmhgfs-fuse defaults 0 0或者早期一些的写法vmhgfs-fuse /mnt/hgfs fuse defaults 0 0这行配置不一定是使用者亲手写的。有些版本的open-vm-tools在启用共享文件夹时会自动向fstab追加挂载项系统升级后环境变了这行就成了地雷。我处理这类问题的顺序是不管三七二十一先把含hgfs的行注释掉让启动链路先恢复健康再谈后续恢复功能。操作上直接用nano /etc/fstab最直观在对应行前面加#保存退出。如果用sed注意点号转义命令大致是sed -i s|^\.host:/|#.host:/| /etc/fstab为什么坚持“先注释”而不是“先重装”因为重装open-vm-tools后旧内核下模块加载未必能立即生效系统启动到挂载步骤照样会失败或长时间等待。先把失败源从启动链路上摘掉让系统能正常开机是最快的止损手段。注释不等于放弃共享文件夹只要你愿意修好服务后可以随时恢复这一行。2.3 重装open-vm-tools并验证内核模块注释完fstab后在root shell中执行apt update apt install --reinstall open-vm-tools open-vm-tools-desktop这里多说一句为什么强调用open-vm-tools而不是VMware官方安装包。Ubuntu 22.04的仓库里维护的open-vm-tools会跟随系统更新和内核版本保持同步。而VMware官方tarball安装的vmware-tools在Ubuntu每次发新内核后很容易出现模块不匹配的问题这是很多“升级后黑屏”案例的根源。装完后验证三件事。第一内核模块能否正常加载modprobe vmhgfs没有输出就说明模块加载正常。第二服务是否启动systemctl status open-vm-tools如果服务没跑起来用systemctl enable --now open-vm-tools启动并设置开机自启。第三用vmware-hgfsclient列出宿主机共享目录vmware-hgfsclient这条命令会返回你在VMware Workstation里配置的所有共享文件夹名称。如果返回为空回到VMware菜单里检查Shared Folders是否处于Always enabled状态这个开关没打开Linux侧怎么折腾都白搭。2.4 重启后的正确共享文件夹挂载配置修好Tools后别急着把fstab原样写回去。先手动验证挂载是否正常再考虑自动化。手动挂载命令sudo mkdir -p /mnt/hgfs sudo vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other,uid1000,gid1000如果不报错ls /mnt/hgfs能看到宿主目录说明整条链路已经通了。此时再决定是否写回fstab。如果需要开机自动挂载推荐写法是.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other,defaults,uid1000,gid1000 0 0我见过不少人纠结用vmhgfs内核模块方式还是vmhgfs-fuse方式这里直接给结论Ubuntu 22.04推荐fuse方式。因为传统的内核模块方式在新内核升级后经常出问题而fuse方案是用户态进程不依赖内核模块编译稳定性好很多。两者对比可以看下表。挂载方式依赖组件常见问题稳定性传统vmhgfs内核模块vmhgfs.ko内核升级后模块未重编加载失败一般vmhgfs-fuseopen-vm-tools用户态程序需确保fusermount权限和open-vm-tools已安装更稳定3. 实际操作记录从黑屏到恢复桌面的完整过程3.1 问题现场还原下面这场操作我实打实走过一遍。虚拟机环境是VMware Workstation 17 Pro客户机Ubuntu 22.04.2之前一切正常Windows宿主机上配了一个共享目录映射到虚拟机内的 /mnt/hgfs。某天执行apt upgrade后重启虚拟机开机后迟迟不出桌面屏幕最终停在一行Failed to mount /mnt/hgfs紧接着就是那句Dependency failed for Local File Systems。第一反应不是重装而是先ping一下这台虚拟机的IP——居然通了。这里给你一个判断依据如果虚拟机IP能ping通说明内核、网络服务都起来了系统不是真死只是桌面没起来。这种情况下按本文流程修就能解决。如果ping不通那是内核阶段就崩了问题性质完全不同需要走Live CD修复流程不在本文讨论范围。3.2 一步步操作实录我按当时实际敲命令的顺序记录下来你可以完全照着做。第一步重启虚拟机。开机画面出现时不停按Shift进入GRUB菜单选Advanced options for Ubuntu再选带recovery mode的内核在Recovery Menu里选root。进入root shell后立刻执行mount -o rw,remount /第二步查看fstab内容cat /etc/fstab屏幕上出现了一行典型的残留配置.host:/ /mnt/hgfs fuse.vmhgfs-fuse defaults 0 0我用nano打开fstab在这一行最前面加了一个#保存退出。稳妥起见又执行一遍cat /etc/fstab复查确认注释生效。第三步重装工具包apt update apt install --reinstall open-vm-tools open-vm-tools-desktop等待安装结束后验证模块加载modprobe vmhgfs命令执行后没有任何输出说明模块正常。接着又确认了服务状态和服务启动systemctl enable --now open-vm-tools systemctl status open-vm-tools服务显示active (running)这步通过。第四步重启虚拟机reboot这次启动很顺利没再看到那行碍眼的错误桌面正常出现。登录后我用journalctl -b -p err检查本次启动的错误日志确认没有新的挂载失败记录。第五步恢复共享目录。回到VMware菜单确认Shared Folders开关仍处于Always enabled。然后在虚拟机里执行sudo mkdir -p /mnt/hgfs sudo vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other,uid1000,gid1000执行后/mnt/hgfs里出现了宿主机的共享文件夹一切恢复原状。3.3 如果fstab里根本没有hgfs行问题在哪如果你按上面的方法打开fstab发现里面压根没有hgfs相关行那问题就另当别论了。这种情况我遇到过几次fstab是干净的但系统里安装了旧版vmware-tools的init脚本或者某个systemd服务里残留了挂载指令一样会报这个错。这时候别只盯着屏幕上最后一行的hgfs报错要一次看全部失败项journalctl -b | grep -i fail我见过最典型的案例是fstab里某个UUID写错了比如分区UUID和实际对不上local-fs.target一样失败而hgfs报错只是恰好显示在屏幕末尾给人造成是hgfs导致一切的错觉。排查时可以用这两个命令定位真实问题systemd-analyze blame systemd-analyze critical-chain local-fs.targetblame按耗时排序显示启动阶段每个单元的耗时critical-chain显示目标单元的依赖链。依赖链上一目了然哪个环节failed就是罪魁祸首主意直接打到那一个环节上。4. 常见问题与排查技巧实录Failed to mount /mnt/hgfs速查表4.1 问题速查表把几个月来处理过的相关咨询和踩坑经验整理成一张表方便你直接对号入座。现象原因处理办法一直黑屏但虚拟机IP能ping通挂载失败导致systemd等待桌面没起来按CtrlAltF3切TTY注释fstab重装open-vm-tools报错后进入emergency modefstab里有无效挂载项recovery模式进入root修复fstab或恢复快照modprobe vmhgfs报module not found内核模块未安装或与当前内核不匹配安装linux-headers重装open-vm-tools或open-vm-tools-dkms/mnt/hgfs目录不存在open-vm-tools服务未启动或VMware共享开关未开启systemctl enable --now open-vm-tools检查VMware Shared Folders配置桌面黑屏但CtrlAltF3能切到终端GDM或桌面会话服务失败重装gdm3或ubuntu-desktop必要时切换Xorg会话复制粘贴、窗口自适应失效缺open-vm-tools-desktop包apt install open-vm-tools-desktop这张表里的第三行尤其重要。很多人升级内核后复发就是因为在新的内核目录下找不到vmhgfs模块。你可以在重启前主动检查ls /lib/modules/$(uname -r)/misc | grep vmhgfs如果这个目录下没有vmhgfs相关文件说明新内核缺少模块重启后必挂。4.2 三个实操中容易踩的坑第一个坑只注释fstab不重装Tools。这种情况我当时见过不止一次用户把fstab里的挂载行注释掉系统能启动了就以为完事了。结果VMware里的共享文件夹开关还开着某些版本的open-vm-tools会在下次重启时重新注入挂载配置问题又回来了。正确做法是注释fstab和重装open-vm-tools同时做缺一不可。第二个坑直接删除fstab里的那行而不是注释。删除虽然也能让系统启动但以后想恢复共享文件夹时你得重新复习挂载配置的正确写法。以我自己的习惯注释行保留着反而是个提示这里曾经挂载过共享目录以后环境变了也知道去哪改。删除一旦误删其他行恢复起来更麻烦。第三个坑升级内核后不管模块状态就重启。Ubuntu 22.04使用HWE内核机制apt upgrade很可能把内核版本更换掉。升级后如果不确认vmhgfs模块是否匹配新内核重启大概率回到黑屏状态。我现在养成一个习惯升级完先不急着重启执行一遍uname -a和ls /lib/modules/$(uname -r)/misc | grep vmhgfs确认新内核有共享目录模块再执行reboot。5. 避免以后重启再黑屏内核升级与快照习惯5.1 内核升级前后记住这三条把下面这套动作变成例行公事基本能把这类问题堵在门外。升级前在VMware里先给虚拟机拍快照。右键虚拟机 - Snapshot - Take Snapshot整个过程不影响虚拟机关机状态下的文件也可以开着机直接拍。有这个快照垫底后面升级装包再出什么幺蛾子回滚只需要一分钟。升级后、重启前检查新内核的模块目录和当前内核是否一致uname -r ls /lib/modules/$(uname -r)/misc | grep vmhgfs modinfo vmhgfs如果查到模块缺失执行apt install --reinstall open-vm-tools open-vm-tools-desktop或者安装open-vm-tools-dkms重新构建模块。确认无误后再重启。这一套流程本质上就是把“不等重启发现黑屏”变成“重启前主动排雷”看起来多花两分钟实际省下的是黑屏后半小时的折腾。5.2 现实一点的建议fstab别写太满再分享一个我自己的习惯共享文件夹不一定要写进fstab。如果你只是偶尔传个文件完全可以在需要的时候手动执行vmhgfs-fuse挂载用完再umount。这样fstab里少一行启动阶段就少一个失败点系统也更干净。如果确实需要开机自动挂载建议在fstab里加上nofail选项.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other,defaults,uid1000,gid1000,nofail 0 0加上nofail后即使这个挂载项失败了systemd也只会把它标记为失败不会拖累整个local-fs.target。这笔交易很划算你不需要在功能性和启动成功率之间二选一。最后说个私心话我现在看到Ubuntu 22.04虚拟机报这个错第一反应永远是进恢复模式看fstab。90%以上的“Dependency failed for Local File Systems”最后查出来都是fstab挂载项和VMware Tools之间打架。别被那句“Dependency failed”吓到它不过是个传话的真正的问题藏在fstab和服务状态里。把这两样搞明白了这个坑你以后基本不会再踩第二次。
