Bug 136517 - RFE: Allow installation of foreign binaries.
RFE: Allow installation of foreign binaries.
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-20 13:48 EDT by David Woodhouse
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-17 22:08:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2004-10-20 13:48:26 EDT
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
emulated environment.
Comment 1 David Woodhouse 2004-11-01 17:14:39 EST
FYI this is how the qemu init script sets up binfmt_misc to recognise
'foreign' binaries...

            echo
":qemu-i386:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfb\xff\xff\xff:$QEMU/qemu-i386:"
> /proc/sys/fs/binfmt_misc/register
            echo
":qemu-i486:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x06\x00:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfb\xff\xff\xff:$QEMU/qemu-i386:"
> /proc/sys/fs/binfmt_misc/register
            echo  
":qemu-arm: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\xff\xff\xfb\xff\xff\xff:$QEMU/qemu-arm:"
> /proc/sys/fs/binfmt_misc/register
            echo  
":qemu-ppc:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x14:\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfb\xff\xff\xff:$QEMU/qemu-ppc:"
> /proc/sys/fs/binfmt_misc/register
            echo  
":qemu-sparc:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x02:\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfb\xff\xff\xff:$QEMU/qemu-sparc:"
> /proc/sys/fs/binfmt_misc/register
Comment 2 Jeff Johnson 2004-12-01 08:37:54 EST
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.
Comment 3 Jeff Johnson 2004-12-01 08:40:25 EST
dwmw2: I do have a copy of your qwmu-0.5.5 packaging:
%changelog
* Sat May 8 2004 David Woodhouse <dwmw2@redhat.com> 0.5.5-1
- Update to 0.5.5.
Comment 5 Jeff Johnson 2004-12-01 15:41:44 EST
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.
Comment 6 David Woodhouse 2004-12-01 16:51:33 EST
No, it just works under FC3/ppc for me -- at least for running
acroread. Not sure how well it handles threaded programs.
Comment 7 Jeff Johnson 2004-12-02 22:36:12 EST
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.
Comment 8 David Woodhouse 2004-12-03 06:31:34 EST
I'm not sure how well qemu-arm is working. It dies for me (on ppc
host) thus:

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. 
Comment 9 Jeff Johnson 2004-12-03 17:09:12 EST
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
    %___build_args %{nil}

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
chroot.

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. ;-)

Comment 10 Jeff Johnson 2004-12-03 18:44:44 EST
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
Comment 11 Jeff Johnson 2004-12-03 19:08:44 EST
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 ...
Comment 12 Jeff Johnson 2004-12-03 19:10:18 EST
Nah, just the environment along for the ride, never mind ...
Comment 13 David Woodhouse 2004-12-04 05:59:32 EST
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
your chroot?
Comment 14 Jeff Johnson 2004-12-04 09:04:33 EST
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. ;-)
Comment 15 Jeff Johnson 2005-02-07 18:53:09 EST
Not forgotten, just side tracked ...
Comment 16 Jeff Johnson 2006-03-17 22:08:51 EST
rpm+qemu will be pursued outside of bugzilla.

Note You need to log in before you can comment on or make changes to this bug.