作为自动化 VM 创建系统的一部分，块设备被安装到临时文件夹 ( /tmp/whatever )。各种脚本在 VM 首次运行之前安装和配置它。
最近发生了一些变化，临时挂载很忙，拒绝卸载。在尝试确定可能仍使文件保持打开状态的原因时，我检查了：
测试以 root 身份运行
- 山
- lsof | grep /tmp/
- 定影器-m /tmp/…
- 导出文件系统-rv
- 无论如何都要重新启动运行创建脚本的守护进程...
- ps 压缩文件
- dmsetup 表
- 丢失 -a
- fuser -vm /tmp/tmp.random-chars/（产生两行）
- 用户 PID 访问命令
- /tmp/tmp.random-chars：根内核挂载/tmp/tmp.random-chars
上述测试均未得到指向文件系统使用的结果，但是 umount -f 仍然抱怨“设备或资源忙”/“设备忙”。
我应该尝试哪些其他测试，以便能够找到真正的根本原因，从而希望在目前无法重新启动的系统上修复卡住的安装而无需重新启动，并防止这种情况再次发生？
值得怀疑的是（但我不知道如何检查），临时挂载的内核模块是否被加载，因为临时挂载安装的 Linux 版本与主机正在运行的 Linux 版本不同。
編輯
- 从各种搜索结果来看，/modules/ 似乎只是被读入内存。我不知道内核是否可以打开文件以及如何访问任何此类列表。
- 将 dmsetup / losetup 添加到“不显示问题的测试”列表中
- fuser -vm 按照 freenode ##linux 中的建议
答案1
如果它是构建过程的一部分，我假设您无论如何都需要在某个时候重新启动。尝试在过程中插入“延迟”卸载。使用umount -l /tmp并查看这是否有助于您克服过程中的这一障碍。
答案2
我们遇到了同样的问题，但似乎只有当虚拟机的根文件系统是 ext4 时才会发生这种情况。ext3 可以正常工作。我知道这听起来很奇怪，但它可能是内核错误，在http://www.phoronix.com/scan.php?page=news_item&px=MTIxNDQ
如果是这样，我们必须等待内核补丁或避免在主机上安装新的虚拟机。从临时 Linux 虚拟机运行安装它可以正常工作，因为机器重新启动而无需重新启动主机。
你试过 ext3 吗？如果没有，请尝试在 ext3 上安装，如果使用 ext4 是关键，你可以稍后将其转换为 ext4（这在http://www.debian-administration.org/article/643/Migrating_a_live_system_from_ext3_to_ext4_filesystem）
答案3
失败的一个原因umount是远程设备的底层 IP 地址已发生变化。
当我从我的台式机服务器远程安装笔记本电脑时，我曾见过这种情况。第一次安装使用的是 IP 地址 A。虽然重新启动笔记本电脑后会给它提供地址 B，但我的台式机仍将地址 A 记录为笔记本电脑的地址。当我检查命令返回的 IP 地址mount并将其与笔记本电脑的当前地址进行比较时，我可以看到这一点。
- 我能够使用
umount -l - 对我来说，解决这个问题的方法是给笔记本电脑使用固定 IP 地址