I've unpack a stage3 arm and I try to chroot in it. Before the chroot, I mount dev in the stage3: # mount --bind /dev dev Then I test qemu-arm like this: # qemu-arm -L $PWD bin/bash Here nothing happened except that the qemu process takes 100% of the CPU and eats more and more memory. I stop it and I try a smaller binary but the same result happened then I run strace on it and I get the traces in attachment "strace-qemu-arm.txt". I find that if I umount the dev directory of my stage3, the infinie loop disappears. My config on qemu: QEMU_SOFTMMU_TARGETS="aarch64 arm i386 mips x86_64" QEMU_USER_TARGETS="aarch64 arm i386 mips" Reproducible: Always
Created attachment 395654 [details] command: strace qemu-arm -L $PWD bin/bash The original file takes hundreds of MB. I truncate and compress it but we can see the loop on dev/fd/3 that repeat itself.
Created attachment 395656 [details] emerge --info I've got a hardened profile but I try qemu-arm with a gentoo-sources kernel and a vanilla compiler. No effect.
The loop comes from the add_dir_maybe called by init_paths. The directory dev/fd is a symlink on /proc/self/fd . In the command "qemu -L $PWD bin/bash", the parameter $PWD is the 3rd file descriptor. When add_dir_maybe opens dev/fd/3 it creates a new file descriptor in /proc/self/fd, and therefore in dev/fd, that points on the same location and so on.
The bug already exists upstream as: https://bugs.launchpad.net/qemu/+bug/1245703
fwiw, that's not how you'd chroot into there. you should create a static copy of qemu, register it via binfmt, and then use `chroot` like normal.
Quoting from the upstream discussion: """ Yeah, this -L code is just busted. It's really only intended to work with extremely simple sysroot directories which don't have weird stuff like proc mounts or symlinks and aren't very big. If the thing you're looking at isn't like that then you might be better off using the "static qemu and chroot into the directory" approach instead. """ Please use the qemu[static-user] + chroot approach instead.
a qemu dev has posted a reasonable patch we can consider picking up: https://patchwork.kernel.org/patch/9512083/
(In reply to SpanKY from comment #7) > a qemu dev has posted a reasonable patch we can consider picking up: > https://patchwork.kernel.org/patch/9512083/ This patch never made it upstream with multiple outstanding issues.
