Hi Frank, I was trying to grasp the exact details that you are describing and giving this another repro run. You are saying bullseye armhf chroot @ focal on an x86 host is failing for you, correct?
Note: We have just fixed a similar (only on the surface of it) issue in Impish (bug 1947860). Repro on Focal: Note: As Host I was using a new VM based on the current daily focal cloud image which is based on 5.4.0-90-generic. $ apt install qemu-user-static debootstrap $ sudo qemu-debootstrap --arch=arm64 bullseye bullseye-arm64 http://ftp.debian.org/debian # and in another terminal $ sudo qemu-debootstrap --arch=armhf bullseye bullseye-armhf http://ftp.debian.org/debian For me as of the test today armhf worked and arm64 failed. $ tail -n 2 bullseye-arm64/debootstrap/debootstrap.log qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault (core dumped) I was fetching TJs test script from https://iam.tj/projects/misc/binfmt-check and running it in the chroots. In the partially failing arm64 chroot all that is a bit tricky and might need reruns. The magic in both cases matches: ubuntu@f-emuarmhf-1928075:~$ python3 binfmt-check qemu-aarch64 bullseye-arm64/sbin/ldconfig target_file=bullseye-arm64/sbin/ldconfig octets=20 mask=ffffffffffffff00fffffffffffffffffeffffff target=7f454c460201010300000000000000000300b700 result=7f454c460201010000000000000000000200b700 magic=7f454c460201010000000000000000000200b700 Matches magic ubuntu@f-emuarmhf-1928075:~$ python3 binfmt-check qemu-arm bullseye-armhf/sbin/ldconfig target_file=bullseye-armhf/sbin/ldconfig octets=20 mask=ffffffffffffff00fffffffffffffffffeffffff target=7f454c4601010103000000000000000002002800 result=7f454c4601010100000000000000000002002800 magic=7f454c4601010100000000000000000002002800 Matches magic Then I tried 1:6.0+dfsg-2expubuntu1.1~backport20.04-202111060014~ubuntu20.04.1 from https://launchpad.net/~canonical-server/+archive/ubuntu/server-backports With the qemu-user-static package from that indeed armhf and arm64 works. Magic handling stays the same We had quite some binfmt changes in 6.1 and 5.2, but quite maybe as reported in comment #15 even qemu 5.0 would have been enough. After all 4.2-3 (just after focal) did switch the registration of binfmts. This case certainly can be considered confirmed now, the questions for now is if that was the actual qemu code, or the surrounding changes/fixups to binfmt handling. P.S. /me hopes this problem will not again become as eluding as it was before ... Unless someone can directly point to a fix I think I need to build a series of PPAs to bisect through that a bit until we have an idea what the fix really was. ** Changed in: qemu (Ubuntu Focal) Status: Incomplete => Confirmed ** Tags added: server-next -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928075 Title: Segfault with qemu-aarch64-static doing debootstrap for debian bullseye but not buster To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1928075/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
