就上下文而言...我刚刚使用基于 Ubuntu 22.04 的打包程序构建了一个新的 qcow 映像。我们的大多数自定义 ansible 角色都是从 Ubuntu 20.04 中重复使用的，我们发现了一些差异。
作为定制的一部分，我们安装了一个服务，该服务将格式化带有标签“ephemeral0”的驱动器。问题是，在第一次启动时，当此服务运行时，设备显然处于“繁忙”状态
Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/vdb' failed with exit code 1.
14:32:46,509 - DataSourceConfigDrive.py[DEBUG]: devices=['/dev/sr0', '/dev/vdb'] dslist=['ConfigDrive', 'None']
Device /dev/vdb is in use. Cannot proceed with format operation.
WARNING: Device /dev/vdb already contains a 'vfat' superblock signature.
Device /dev/vdb is not a valid LUKS device.
一旦我访问该实例，设备仍处于此状态，如果我尝试运行任何 mount 或 format 命令（例如cryptsetup luksFormat），我只会得到类似这样的信息：
WARNING: Device /dev/vdb already contains a 'vfat' superblock signature.
Device /dev/vdb is in use. Cannot proceed with format operation.
我已经尝试过lsof，mount以及所有其他建议的工具，但我无法弄清楚是什么在控制着我/dev/vdb设备的访问权限。
现在，如果我简单地重新启动实例，当它重新启动时，格式化服务就会运行良好，并且我拥有新格式化的 LV，但是由于我们环境的性质，这不是一个有效的解决方法。
我如何才能知道究竟是什么在访问此设备？也许在非默认 NS 中？
更新：这似乎与 cloud-init 有关。如果我/var/lib/cloud/instances在执行恢复重启之前删除内容，我们最终会处于相同的状态。
更新 2：因此，看起来好像挂载拒绝umount正确执行。禁用我们的本地格式化服务并让 cloud-init 执行其操作后，ephemeral0 驱动器被挂载，并且有一个条目/etc/fstab：
/dev/vdb /mnt auto defaults,nofail,x-systemd.requires=cloud-init.service,_netdev,comment=cloudconfig 0 2
但即便如此，umount /dev/vdb我还是无法针对该设备运行 mkfs。我总是得到“/dev/vdb 显然正在被系统使用；不会在这里创建文件系统！”
再次lsof没有给我任何线索。似乎与 cloud-init 在“首次启动”时执行的操作有关。
如果我：
- 首次启动后重新启动机器，自定义服务能够重新格式化驱动器。
- 在云配置中设置
mounts: [[]]自定义服务能够重新格式化驱动器，并能够在首次启动时格式化临时驱动器。