Red Hat Bugzilla – Bug 136517
RFE: Allow installation of foreign binaries.
Last modified: 2007-11-30 17:10:52 EST
qemu (and ia32el on ia64, and em86 on Alpha) allow i386 (and other
non-native) binaries to be run on other architectures.
However, these emulators require a full set of libraries to be
installed in a chroot-like environment for the system to be emulated.
RPM should allow foreign binaries to be installed to a location such
as /usr/qemu-i386/ in order to allow proper maintenance of the
FYI this is how the qemu init script sets up binfmt_misc to recognise
Do you have a ptr to a functional qemu-0.6.1 package? Or should
some other version be used? (make test from CVS is segfaulting for me).
What gcc should be used to compile?
What /proc settings are needed these days for functional qemu?
Are the settings dependent on qemu version?
Any hints on what I should expect to see fail, like NPTL?
I'm looking at qemu under rpm now, prolly x86 on x86 first,
then perhaps ppc arm sparc.
dwmw2: I do have a copy of your qwmu-0.5.5 packaging:
* Sat May 8 2004 David Woodhouse <email@example.com> 0.5.5-1
- Update to 0.5.5.
Ah, thank you.
Any special /proc handling needed these days? I remember
exec-shield preventing qemu execution at one point, but perhaps
that is fixed now.
No, it just works under FC3/ppc for me -- at least for running
acroread. Not sure how well it handles threaded programs.
Well, after wasting 2 hours on a stupid thinko brain fart, I have
joy of qemu-arm. w00t!
Next will be to throw some rpm builds against qemu-arm,
then some installs, and watch what breaks.
qemu-ppc, and mac os x, as soon as I can cobble up some images.
I may get openoffice on my netwinder yet ;-) Thanks for the hand holding.
I'm not sure how well qemu-arm is working. It dies for me (on ppc
shinybook /usr/qemu-arm/bin $ ./ls
qemu: uncaught target signal 11 (Segmentation fault) - exiting
Personally I'd pick a different target to play with first.
Working well enough for me to attempt testing so
far. This is farther than I've ever gotten with
wemu in the last year, which is quite promising.
My hacking plan for qemu-under-rpm is basically:
Plan A: attempt user mode qemu under rpmbuild using qemu-i386.
This config in /etc/rpm/macros is what I'm attempting
%___build_shell /usr/bin/qemu-i386 -L / /bin/sh
I'm currently blocked by EINVAL on attempted fork from the
emulated shell (not surprising once I figgered what user
mode means). I've also attempted a user mode emulated
chroot with various incarnations (binfmt_misc on arm known good
because /usr/qemu-arm/bin/ls "works") of
chroot /usr/qemu-arm /usr/qemu-arm/bin/sh
but I've not yet been able to figger a user mode emulated
Plan B system mode emulation
This is likely to succeed afaict, but is perhaps
conceptually trickier to wire into rpmbuild and rpm
Plan C is to translate shell into lua in order to be able
to run scriptlets for other arches, but let's not go there ...
If I can get some proof-of-concept hackery in place, I will
attempt builds and installs all emulations to ascertain
what is actually feasible, none of that needs NPTL or
emulated hardware, and so looks quite viable and promising.
Any/all hacking help appreciated. ;-)
This is perhaps a simple reproducer that illustrates
something fundamental and conceptual that I am missing:
[root@wellfleet ~]# /usr/qemu-arm/bin/uname -a
Linux wellfleet.jbj.org 2.6.9-1.667smp #1 SMP Tue Nov 2 14:59:52 EST
2004 i686 i686 i386 GNU/Linux
[root@wellfleet ~]# chroot /usr/qemu-arm /bin/uname -a
chroot: cannot run command `/bin/uname': No such file or directory
And this appears to be the fundamental stumbling block
to a user mode chroot (note: proc and binfmt_misc are
mounted under /usr/qemu-arm):
strace -o /tmp/xxx chroot /usr/qemu-arm /bin/sh
chroot: cannot run command `/bin/sh': No such file or directory
execve("/bin/sh", ["/bin/sh"], [/* 21 vars */]) = -1 ENOENT (No such
file or directory)
Any ideas appreciated. Hmmm, /* 21 vars */ looks a bit fishy ...
Nah, just the environment along for the ride, never mind ...
Remember binfmt_misc will be trying to turn your invocation of an ARM
binary into '/usr/bin/qemu-arm /bin/sh'. Do you have qemu installed in
Aha! That's what I missed.
# chroot /usr/qemu-arm /bin/ls
chroot: cannot run command `/bin/ls': Accessing a corrupted shared library
Hmmm, I begin to understand the need for -L to change ldconfig
search paths. ;-)
Not forgotten, just side tracked ...
rpm+qemu will be pursued outside of bugzilla.