我使用docker-checkpoint-restore检查点并保持源容器处于活动状态（--leave-running），然后将该检查点恢复到新创建的容器（具有不同的IP地址）。
但是，我在处理mountpoints和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 （使用暴击解码显示）引用了旧容器ID。
crit decode -i mountpoints-12.img --pretty | grep nsroot
crit decode -i cgroup.img --pretty | grep docker
透露了旧容器ID。
我遵循了同样的暴击解码 - sed替换 - 暴击编码策略，我用于skinet;但它没有解决问题。我验证了转换 mountpoints-12.img和cgroup.img引用了新的容器ID。但恢复仍然失败，完全相同的错误。就像mountpoints转换而cgroup转换没有任何影响一样。
具体到底我做错了什么？我不得不说这是我第一次在Ubuntu 16.04 xenial映像上通过docker进行CRIU。在过去，我已经为基于阿尔卑斯山的图像做了这个，并且没有任何问题检查到新容器（当旧的容器运行时）
主机系统是Ubuntu Xenial，默认的criu / crit是2.0-2ubuntu3。我从xemul criu升级到最新的criu / crit，将其提升到2.4。但是，我得到了同样的错误。
我还对一个基于高山的容器进行了测试。它运作良好。所以，也许在基于Ubuntu xenial的容器中有一些东西将criu（检查点，或恢复或两者）投入到tizzy中
欢迎任何投入。