我正在使用docker-checkpoint-restore检查点并使源容器保持活动状态（--leave-running），然后将该检查点恢复到新创建的容器中（具有不同的 IP 地址）。
但是，我在处理挂载点和 cgroup 时遇到了麻烦。当我使用检查点启动新容器时，我得到
1: mnt: Bind /home/abc to ./HOME
1: Error (mount.c:2406): mnt: Can't mount at ./HOME: No such file or directory
1: Error (mount.c:2555): mnt: Unable to statfs ./HOME: No such file or directory
Error (cr-restore.c:1352): 30140 killed by signal 9
Error (cr-restore.c:2182): Restoring FAILED
cgroups 错误是：
45: Error (cgroup.c:1152): cg: No set 1 found
1: Error (cr-restore.c:1350): 45 exited, status=1
Error (cr-restore.c:1352): 30140 killed by signal 9
Error (cr-restore.c:2182): Restoring FAILED
我推测这是由于mountpoint-12.img和cgroup.img（通过使用 crit decode 显示）引用了旧容器 ID。
crit decode -i mountpoints-12.img --pretty | grep nsroot
crit decode -i cgroup.img --pretty | grep docker
揭示了旧的容器 ID。
我遵循了我用于 skinet的相同的暴击解码 - sed 替换 - 暴击编码策略；但它并没有解决问题。我验证了转换后的mountpoints-12.img 和 cgroup.img 引用了新的容器 ID。但恢复仍然失败，并出现完全相同的错误。就好像挂载点转换和 cgroup 转换没有任何影响。
我具体做错了什么？我不得不说这是我第一次在 Ubuntu 16.04 xenial 映像上通过 docker 进行 CRIU。在过去，我已经为基于 alpine 的图像完成了它，并且在检查新容器时没有任何问题（当旧容器正在运行时）
主机系统是 Ubuntu Xenial，默认 criu/crit 是 2.0-2ubuntu3。我从xemul criu升级到最新的 criu/crit ，将其提升到 2.4。但是，我得到了同样的错误。
我还针对基于高山的容器对此进行了测试。而且效果很好。所以，也许在基于 Ubuntu xenial 的容器中有些东西正在让 criu（检查点或恢复或两者兼有）陷入困境
欢迎任何意见。