<div dir="ltr">Hi Ross,<div><br></div><div>I just tried to re-produce the problem that you see by creating my container&#39;s root filesystem at / but both checkpoint and restore succeeded for me (see below).  How exactly are you setting up your container?  Are you running CRIU directly or are you using nsinit to checkpoint your container?</div><div><br></div><div>Please note that due to a host of other activities, unfortunately I won&#39;t be able to respond quickly.</div><div><br></div><div>--Saied</div><div><br></div><div>[Terminal A]</div><div># cd /</div><div># <span class="">curl </span><span class="">-sSL</span><span class=""> </span><span class="">&#39;</span><a href="https://github.com/jpetazzo/docker-">https://github.com/jpetazzo/docker-</a><span class="">busybox</span>/raw/buildroot-2014.02/rootfs.tar<span class="">&#39;</span><span class=""> </span><span class="">&gt;</span><span class=""> /tmp/rootfs.tar</span></div><div><span class=""># </span>cat /tmp/rootfs.tar <span class="">|</span> tar <span class="">-xC</span> <span class="">&quot;</span><span class="">$container_dir</span><span class="">&quot;</span> <span class="">2</span><span class="">&gt;</span> /dev/null</div><div># cd /busybox</div><div># nsinit exec -- sh -i</div><div>sh: can&#39;t access tty; job control turned off</div><div>/ #</div><div><br></div><div>[Terminal B]</div><div># cd /busybox</div><div># nsinit -criu /usr/local/bin/criu checkpoint</div><div>#</div><div><br></div><div>[Terminal A]</div><div># mount --rbind /busybox /busybox</div><div># cd /busybox<br></div><div># nsinit -criu /usr/local/bin/criu restore</div><div>/ #</div><div><br></div>







<div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 2, 2015 at 4:51 PM, Ross Boucher <span dir="ltr">&lt;<a href="mailto:rboucher@gmail.com" target="_blank">rboucher@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I&#39;m running into a failure when trying to checkpoint (with the as of yet unmerged support being worked on libcontainer). The command I&#39;m running is:<div><br></div><div>&gt;&gt;&gt; criu dump -v4 -D /busybox/nsinit/checkpoint -o dump.log --root /busybox --manage-cgroups --evasive-devices -t 51<br></div><div><br></div><div>Which eventually ends up with this error:</div><div><br></div><div>(00.017527) Replacing /var/lib/docker/aufs/diff/df29663e06373227d372bdd13867dbdce00bf02dac9627679ee3d4985021beb0/busybox/bin/busybox with /busybox/bin/busybox<br></div><div>(00.017537) Saved AUFS paths ./busybox/bin/busybox and /busybox/busybox/bin/busybox</div><div>(00.017575) Error (sysfs_parse.c:304): Failed stat on map 400000 (/busybox/busybox/bin/busybox): No such file or directory</div><div>(00.017583) Error (proc_parse.c:589): Can&#39;t open 51&#39;s mapfile link 400000: No such file or directory</div><div><br></div><div>(full dump: <a href="https://gist.github.com/boucher/d2539bcaa1311c5d5f5c" target="_blank">https://gist.github.com/boucher/d2539bcaa1311c5d5f5c</a>)<br></div><div><br></div><div>I can see in the criu source that this is part of potentially trying to workaround a kernel bug (according to the comments around fixup_aufs_vma_fd). I&#39;m not entirely sure what the expected behavior is, or why /busybox/bin/busybox seems to get turned into the relative version ./busybox/bin/busybox. </div><div><br></div><div>Any ideas?</div><div><br></div></div>
<br>_______________________________________________<br>
CRIU mailing list<br>
<a href="mailto:CRIU@openvz.org">CRIU@openvz.org</a><br>
<a href="https://lists.openvz.org/mailman/listinfo/criu" target="_blank">https://lists.openvz.org/mailman/listinfo/criu</a><br>
<br></blockquote></div><br></div></div>