On January 22, 2017 2:34:09 PM GMT-02:00, Antonio Terceiro <terce...@debian.org> wrote: >Hi, > >[sorry for the large cross-post, but I don't really know where the >problem could be; please keep me in Cc: since I'm not debian-powerpc@ >not on deity@] > >The Campinas IBM team has generously made a few VMs available to run >the >Debian CI (https://ci.debian.net) on ppc64el. I am having some trouble >to get it working properly due to an issue with LXC. I have done this >countless times on amd64 and arm64, and never had any issues like this >one, so that is why I suspect it's ppc64el-specific. > >`apt update` inside a LXC container hangs forever like this: > ># apt update >0% [Waiting for headers]^C > >Running `apt update` under strace shows this infinite loop at the end: > >_newselect(6, [5], [], NULL, {tv_sec=0, tv_usec=500000}) = 0 (Timeout) >rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0 >rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 >0% [Waiting for headers]) = 25aders]", 25 >_newselect(6, [5], [], NULL, {tv_sec=0, tv_usec=500000}) = 0 (Timeout) >rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0 >rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 >0% [Waiting for headers]) = 25aders]", 25 >_newselect(6, [5], [], NULL, {tv_sec=0, tv_usec=500000}) = 0 (Timeout) >rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0 >rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 >0% [Waiting for headers]) = 25aders]", 25 >_newselect(6, [5], [], NULL, {tv_sec=0, tv_usec=500000}) = 0 (Timeout) >rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0 >rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 >0% [Waiting for headers]) = 25aders]", 25 >_newselect(6, [5], [], NULL, {tv_sec=0, tv_usec=500000}) = 0 (Timeout) >rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0 >rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 >0% [Waiting for headers]) = 25aders]", 25 >_newselect(6, [5], [], NULL, {tv_sec=0, tv_usec=500000}^Cstrace: >Process 127 detached > <detached ...> > >The host is a ppc64el VM running jessie. I tried LXC guests running >both >jessie and sid, and I get the same result on both. > >I have also tried all of the following: > >- running `apt update` from the host, when chroot'ed to the container > rootfs; just works normally > >- upgrading the kernel on the host to the latest one in >jessie-backports > (4.8); did not help > >- upgrading LXC to the latest version from jessie-backports (2.0), and > starting the container with it; did not help
What is file descriptor 5? I would assume it's the http connection. Does wget/curl work fine inside the container? How is the network behavior in general? Are you using veth plus NAT? What if you set a namespace with unshare -n, setup a veth pair and set the same network setup? Does it work? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.