Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 407099 - Incorrect mount options and binfmt_misc mask for "Compiling with qemu-user chroot" secion
Summary: Incorrect mount options and binfmt_misc mask for "Compiling with qemu-user ch...
Status: RESOLVED FIXED
Alias: None
Product: Documentation
Classification: Unclassified
Component: Project-specific documentation (show other bugs)
Hardware: ARM Linux
: Normal normal (vote)
Assignee: Embedded Gentoo Team
URL: http://www.gentoo.org/proj/en/base/em...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-06 11:54 UTC by David M
Modified: 2013-12-11 07:18 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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