Bug 136517

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

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:
%changelog
* Sat May 8 2004 David Woodhouse <dwmw2> 0.5.5-1
- Update to 0.5.5.

ftp://ftp.uk.linux.org/pub/people/dwmw2/fc2-mac/SRPMS/qemu-0.6.1-1.src.rpm

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

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

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
your chroot?

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.