Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 407099

Summary: Incorrect mount options and binfmt_misc mask for "Compiling with qemu-user chroot" secion
Product: Documentation Reporter: David M <david.mirabito>
Component: Project-specific documentationAssignee: Embedded Gentoo Team <embedded>
Status: RESOLVED FIXED    
Severity: normal CC: binchomittens, david.mirabito
Priority: Normal    
Version: unspecified   
Hardware: ARM   
OS: Linux   
URL: http://www.gentoo.org/proj/en/base/embedded/handbook/?part=1&chap=5
Whiteboard:
Package list:
Runtime testing required: ---

Description David M 2012-03-06 11:54:48 UTC 
I Followed the steps to bootstrap an ARMv7-hardfp in a chroot, using qemu. I got it working, but there was some things required different than the linked document describes:

[stage3-armv7a_hardfp-20120228.tar.bz2]

1. I had to mount -rbind /proc and /dev.
/dev was already populated in the tarball, but I needed /dev/pts also bound - else I got warnings about no more ptys.
Similarly, the /proc/sys/fs/binfmt_misc mountpoint needs to be preserved within the chroot too, else you cannot enter the chroot.

2. For some reason, /usr/libexec/gcc/armv7a-hardfloat-linux-gnueabi/4.5.3/cc1 has the value 0x08 for byte 15 of the file. (i.e. e_ident[14] of ELF header) The ELF spec states (as I read it) this is reserved (should be zero) and readers should ignore whatever is read.

For cc1, it is not zero (all other binaries seem to work as expected) and the binfmt registration line is written to explicitly expect zeroes, and not 'don't care'.

I found this line worked for me:
echo ':arm2:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\x00\xff\xfe\xff\xff\xff:/qemu-wrapper:' > /proc/sys/fs/binfmt_misc/register

But this only ignores the problematic byte. A full solution possibly should ignore all bytes in the header the spec requires us to.

I am not sure if it is a problem or not that cc1 has that byte set in the first place.

This manifests as emerge errors "configure: error: C compiler cannot create executables", so perhaps FAQ 6.1 could reflect this as one possible cause. (reading the config.log pointed me to cc1 resulting in 'cannot execute binary' leading to examination of the binfmt matching string).

Thanks,
DavidM
Comment 1 siler 2013-08-15 20:03:17 UTC 
Same issue using lxc-gentoo and building an ARM container via binfmt. qemu-binfmt set an incorrect value for the arm2 registration. David's change worked for me, allowing the container to start.
Comment 2 Markos Chandras (RETIRED) gentoo-dev 2013-08-15 20:34:15 UTC 
Please provide a patch for the document if you want this fixed