Description of problem: The binfmt config configured for ppc64le uses \x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x15 as the magic number rather than \x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x15\x00 The former is the magic number for ppc64. Version-Release number of selected component (if applicable): qemu-2.10.0-0.4.rc4.fc27 (and all earlier versions that included a binfmt config for ppc64le) How reproducible: 100% Steps to Reproduce: 1. Install qemu-user-static and docker on an x86_64 host 2. docker run -it -v /usr/bin/qemu-ppc64le-static:/usr/bin/qemu-ppc64le-static ppc64le/centos:7 /bin/bash Actual results: panic: standard_init_linux.go:178: exec user process caused "exec format error" [recovered] panic: standard_init_linux.go:178: exec user process caused "exec format error" goroutine 1 [running, locked to thread]: github.com/urfave/cli.HandleAction.func1(0xc4200e57a0) /builddir/build/BUILD/docker-0fdc77886ccc101a28b11ce63e87a935c936d2ef/runc-79c3939053c870fbb4de5484d98640d5ba028ef4/Godeps/_workspace/src/github.com/urfave/cli/app.go:478 +0x23f panic(0x6f0c00, 0xc420169030) /usr/lib/golang/src/runtime/panic.go:489 +0x2cf github.com/opencontainers/runc/libcontainer.(*LinuxFactory).StartInitialization.func1(0xc4200e5208, 0xc42000e040, 0xc4200e52a8) /builddir/build/BUILD/docker-0fdc77886ccc101a28b11ce63e87a935c936d2ef/runc-79c3939053c870fbb4de5484d98640d5ba028ef4/Godeps/_workspace/src/github.com/opencontainers/runc/libcontainer/factory_linux.go:259 +0xc1 github.com/opencontainers/runc/libcontainer.(*LinuxFactory).StartInitialization(0xc4200d0280, 0xaa88e0, 0xc420169030) /builddir/build/BUILD/docker-0fdc77886ccc101a28b11ce63e87a935c936d2ef/runc-79c3939053c870fbb4de5484d98640d5ba028ef4/Godeps/_workspace/src/github.com/opencontainers/runc/libcontainer/factory_linux.go:277 +0x353 main.glob..func8(0xc4200b2780, 0x0, 0x0) /builddir/build/BUILD/docker-0fdc77886ccc101a28b11ce63e87a935c936d2ef/runc-79c3939053c870fbb4de5484d98640d5ba028ef4/main_unix.go:26 +0x66 reflect.Value.call(0x6d9b20, 0x7502a8, 0x13, 0x73b882, 0x4, 0xc4200e5760, 0x1, 0x1, 0xc4200e56f0, 0x731360, ...) /usr/lib/golang/src/reflect/value.go:434 +0x91f reflect.Value.Call(0x6d9b20, 0x7502a8, 0x13, 0xc4200e5760, 0x1, 0x1, 0x665a76, 0x73ba0e, 0x4) /usr/lib/golang/src/reflect/value.go:302 +0xa4 github.com/urfave/cli.HandleAction(0x6d9b20, 0x7502a8, 0xc4200b2780, 0x0, 0x0) /builddir/build/BUILD/docker-0fdc77886ccc101a28b11ce63e87a935c936d2ef/runc-79c3939053c870fbb4de5484d98640d5ba028ef4/Godeps/_workspace/src/github.com/urfave/cli/app.go:487 +0x18f github.com/urfave/cli.Command.Run(0x73ba2e, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x74d2ea, 0x51, 0x0, ...) /builddir/build/BUILD/docker-0fdc77886ccc101a28b11ce63e87a935c936d2ef/runc-79c3939053c870fbb4de5484d98640d5ba028ef4/Godeps/_workspace/src/github.com/urfave/cli/command.go:191 +0xac8 github.com/urfave/cli.(*App).Run(0xc420114000, 0xc42008c060, 0x2, 0x2, 0x0, 0x0) /builddir/build/BUILD/docker-0fdc77886ccc101a28b11ce63e87a935c936d2ef/runc-79c3939053c870fbb4de5484d98640d5ba028ef4/Godeps/_workspace/src/github.com/urfave/cli/app.go:240 +0x5d6 main.main() /builddir/build/BUILD/docker-0fdc77886ccc101a28b11ce63e87a935c936d2ef/runc-79c3939053c870fbb4de5484d98640d5ba028ef4/main.go:137 +0xbd2 Expected results: An active shell in the ppc64le container Additional info: Modifying /usr/lib/binfmt.d/qemu-ppc64le-static.conf with the following contents resolves the issue: :qemu-ppc64le:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x15\x00:\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xfe\xff\xff:/usr/bin/qemu-ppc64le-static:
npmccallum you added ppc64le binfmt, does this sound correct?
As I understand the problem, I failed to change the byte order for the ELF e_machine field when I made all the PPC64 binfmts. If that understanding is correct, then yes, this looks like a valid issue and valid fix to me. Jason, as an aside, there is no reason to mount the qemu binary into the chroot if you are running a recent kernel in the host. The kernel now has the F flag in binfmt for this purpose.
https://src.fedoraproject.org/rpms/qemu/c/3b6c813012ab11076e8fb1440dfeae7415db1d98?branch=master I pushed the above fix. It should be available whenever Cole Robinson makes the next Fedora build.
Nathaniel, I'm running a backported version of qemu-user-static on RHEL 7, so unfortunately I can't take advantage of the F flag, but thanks for the quick turnaround.
This is in qemu-2.10.0-1.fc28 now, f27 build in progress
Nathaniel, I'm just getting back around to doing further testing on this, I believe there still needs to be an update to switch the fields for the e_type field as well as the corresponding mask fields. In my previous testing I had swapped the fields for the e_type field, but neglected to also switch the corresponding mask fields, which allowed static binaries to work, but not dynamically linked binaries. The following are the contents of the working /usr/lib/binfmt.d/qemu-ppc64le-static.conf: :qemu-ppc64le:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x15\x00:\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfe\xff\xff\xff:/usr/bin/qemu-ppc64le-static:F
Yup, you're right. Working on a fix now.
Cole, I have fixed and pushed this to rawhide. Like before, I have not built it. Please cherry pick this to whatever branches you want (preferably f26 and f27).
Thanks, pushed to f26/f27 branches as well