Hmm, so the created chroot env hangs on a native s390x - interesting. Thanks for the cross check Jürg.
For the arm64 note, yes as it works for many other architecture combinations as seen in my (rather unreadable) matrix in comment #2. I wonder very much as I got it working on s390x host by just running the qemu-debootstrap (which falls back to no qemu needed as host=guest). In the case you tried on s390x and it hung the chrooting - did you create the chroot on x86 and then copy it over? Or did you run the qemu-debootstrap on s390x? Did you run it on the ?older? Debian VM there? OTOH The strace doesn't give me a ringing bell what it could be. But if it really is 100% reproducible on the s390x host. And if exchanging /lib & /bin really unlocks it how about copying the files in a loop and testing until it succeeds ? You said you copied from Debian VM into the chroot, would you mind trying that with a Ubuntu VM. And if reasonable/possible the files in a loop to check on which file it suddenly resolves to work? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1712534 Title: qemu-debootstrap second stage hangs indefinitely To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1712534/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
