Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#763043: qemu-user-binfmt: binfmt support broken - package empty, foreign binaries do not run

179 views
Skip to first unread message

Michal Suchanek

unread,
Sep 27, 2014, 9:40:02 AM9/27/14
to
Package: qemu-user-binfmt
Version: 2.1+dfsg-4
Severity: normal

Hello,

I tried installing qemu-user-binfmt in the hope I will be able to run foreign architecture binaries.

This has absolutely no results. THe package is empty and foreign binaries do not run.

Interestingly, on machines where this works this plackage is not present.

Is this package supposed to do anything?

If not what is the preferred way to run foreign binaries?

Thanks

Michal

-- System Information:
Debian Release: 7.6
APT prefers stable
APT policy: (900, 'stable'), (510, 'unstable'), (505, 'experimental'), (500, 'saucy-updates'), (500, 'saucy-security'), (500, 'saucy-proposed'), (500, 'saucy'), (500, 'raring-updates'), (500, 'raring'), (500, 'testing'), (100, 'saucy-backports')
Architecture: armhf (armv7l)

Kernel: Linux 3.4.0 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages qemu-user-binfmt depends on:
ii binfmt-support 2.0.12
ii qemu-user 2.1+dfsg-4

qemu-user-binfmt recommends no packages.

qemu-user-binfmt suggests no packages.

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory


--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Michael Tokarev

unread,
Sep 27, 2014, 10:20:02 AM9/27/14
to
Control: tag -1 moreinfo unreproducible

27.09.2014 16:33, Michal Suchanek wrote:
> Package: qemu-user-binfmt
> Version: 2.1+dfsg-4
> Severity: normal
>
> Hello,
>
> I tried installing qemu-user-binfmt in the hope I will be able to run foreign architecture binaries.
>
> This has absolutely no results. THe package is empty and foreign binaries do not run.

As stated in the package description, the package is empty and the only
reason for it to exist is to run scripts at install and remove times to
register binfmt support. This is the reason why it depends on qemu-user
(actual implementation) and binfmt-support (registration).

Please be more specific. Which binaries you tried to run but failed?
What error message did you get? With the info you provided it is
impossible to handle your bugreport, especially since I know this
package works on my systems.

Do you realize that in order to run regular foreign binary, you also
need to install all (foreign) libraries required by that binary. With
plain qemu-user and without additional foreig libraries it is possible
to run only statically linked foreign binaries.

On the other hand you can create a whole foreign chroot with its own
libraries and directory structure, and chroot into it using qemu as
a helper/emulator -- but for this to work, now it is qemu who needs
(now native) libraries inside the chroot, or you should use statically
linked qemu.

> Interestingly, on machines where this works this plackage is not present.
>
> Is this package supposed to do anything?

See above.

> If not what is the preferred way to run foreign binaries?

I don't understand this question. There's no True Way for anything.
Depending on your needs, you may use qemu-user-binfmt or qemu-user-static,
there may be other alternatives.

Thanks,

/mjt

Michal Suchanek

unread,
Sep 27, 2014, 10:30:02 AM9/27/14
to
Package: qemu-user-static
Version: 2.1+dfsg-4
Followup-For: Bug #763043

Hello,

I found that I have qemu-user-static instead of qemu-user-binfmt on system
where this works. I can run armhf binaries on a PC but the reverse does not
work. There is a handler for PC binaries registered but bash still reports it
cannot execute binary file.

Is the magic for PC binaries correct? How do I check?

Thanks

Michal

-- System Information:
Debian Release: 7.6
APT prefers stable
APT policy: (900, 'stable'), (510, 'unstable'), (505, 'experimental'), (500, 'saucy-updates'), (500, 'saucy-security'), (500, 'saucy-proposed'), (500, 'saucy'), (500, 'raring-updates'), (500, 'raring'), (500, 'testing'), (100, 'saucy-backports')
Architecture: armhf (armv7l)

Kernel: Linux 3.4.0 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

qemu-user-static depends on no packages.

Versions of packages qemu-user-static recommends:
ii binfmt-support 2.0.12

Versions of packages qemu-user-static suggests:
ii sudo 1.8.5p2-1+nmu1

-- no debconf information

Michael Tokarev

unread,
Sep 27, 2014, 11:10:02 AM9/27/14
to
27.09.2014 17:29, Michal Suchanek wrote:
>
> I found that I have qemu-user-static instead of qemu-user-binfmt on system
> where this works. I can run armhf binaries on a PC but the reverse does not
> work. There is a handler for PC binaries registered but bash still reports it
> cannot execute binary file.
>
> Is the magic for PC binaries correct? How do I check?

Exactly the same set of magic strings is used in qemu-user-static and qemu-user-binfmt.

Thanks,

/mjt

Michael Tokarev

unread,
Nov 11, 2014, 2:40:04 AM11/11/14
to
Hello Michal. A friendly ping? Do you have any additional information
for this bugreport? I can't do anything with it without your input...

Thank you!

Michal Suchanek

unread,
Nov 11, 2014, 3:20:04 AM11/11/14
to
Excerpts from Michael Tokarev's message of Tue Nov 11 08:33:40 +0100 2014:
I found that I have qemu-user-static instead of qemu-user-binfmt on
system where this works. I can run armhf binaries on a PC but the
reverse does not work. There is a handler for PC binaries registered but
bash still reports it cannot execute binary file.

Is the magic for PC binaries correct? How do I check?


>
> Hello Michal. A friendly ping? Do you have any additional information
> for this bugreport? I can't do anything with it without your input...

I did send another email in the bug report, right?

Thanks

Michal

Michael Tokarev

unread,
Nov 11, 2014, 3:20:04 AM11/11/14
to
11.11.2014 11:02, Michal Suchanek wrote:
[]
>
> I found that I have qemu-user-static instead of qemu-user-binfmt on
> system where this works. I can run armhf binaries on a PC but the

Yes, I've seen that.

> reverse does not work. There is a handler for PC binaries registered but
> bash still reports it cannot execute binary file.
>
> Is the magic for PC binaries correct? How do I check?

I replied to that at the time, -- the same magic strings are used in
both packages (qemu-user-static and qemu-user-binfmt), these are
generated (using simple substitutions) from a common file.

>> Hello Michal. A friendly ping? Do you have any additional information
>> for this bugreport? I can't do anything with it without your input...
>
> I did send another email in the bug report, right?

Yes, and I replied to that, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763043#22


So, to rehash, do I understand it right that you're having
probs with running x86 binaries on arm, when using -user-binfmt
but not when using -user-static ?

Did you try using -user-binfmt on PC to run arm binaries, does
that work? (I can try that myself, but I think I verified this).

Please note that -user-binfmt (the non-statically-linked variant)
will not work in a foreign chroot, since it needs not only the
qemu binary itself, but also all the libraries which are linked
dynamically into it. But I think this does not apply since you
don't run foreign binaries in a chroot, at least as far as I can
understand.

Thanks,

/mjt

Michal Suchanek

unread,
Nov 11, 2014, 5:30:03 AM11/11/14
to
Excerpts from Michael Tokarev's message of Tue Nov 11 09:15:15 +0100 2014:
> 11.11.2014 11:02, Michal Suchanek wrote:
> []
> >
> > I found that I have qemu-user-static instead of qemu-user-binfmt on
> > system where this works. I can run armhf binaries on a PC but the
>
> Yes, I've seen that.
>
> > reverse does not work. There is a handler for PC binaries registered but
> > bash still reports it cannot execute binary file.
> >
> > Is the magic for PC binaries correct? How do I check?
>
> I replied to that at the time, -- the same magic strings are used in
> both packages (qemu-user-static and qemu-user-binfmt), these are
> generated (using simple substitutions) from a common file.

Yes, neither works, unsurprisingly.

>
> >> Hello Michal. A friendly ping? Do you have any additional information
> >> for this bugreport? I can't do anything with it without your input...
> >
> > I did send another email in the bug report, right?
>
> Yes, and I replied to that, see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763043#22
>
>
> So, to rehash, do I understand it right that you're having
> probs with running x86 binaries on arm, when using -user-binfmt
> but not when using -user-static ?

I am having problem running x86 binaries on arm with either package.

# strace ./app
execve("./app", ["./app"], [/* 17 vars */]) = -1 ENOEXEC (Exec format
error)
write(2, "strace: exec: Exec format error\n", 32strace: exec: Exec
format error
) = 32
exit_group(1) = ?
+++ exited with 1 +++

# file app
app: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux),
statically linked, stripped

# uname -a
Linux sun5i 3.4.103+ #36 PREEMPT Thu Aug 28 17:40:10 CEST 2014 armv7l
GNU/Linux

There is probably problem with static binaries:

# apt-get install unrar:amd64
...
ldconfig: /lib/x86_64-linux-gnu/libz.so.1 is for unknown machine 62.
...
ldconfig: /lib/ld-linux.so.2 is for unknown machine 3.
...

# unrar /?
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

# apt-get install cdebootstrap-static:amd64

# cdebootstrap-static /?
-bash: /usr/bin/cdebootstrap-static: cannot execute binary file

Thanks

Michal

Michael Tokarev

unread,
Nov 11, 2014, 8:20:03 AM11/11/14
to
Control: retitle -1 x86 emulation does not work on arm host
Control: reassign -1 qemu-user
Control: tag -1 - moreinfo

11.11.2014 13:18, Michal Suchanek wrote:
[]
>> So, to rehash, do I understand it right that you're having
>> probs with running x86 binaries on arm, when using -user-binfmt
>> but not when using -user-static ?
>
> I am having problem running x86 binaries on arm with either package.

Aha. That is entirely different thing. Retitling the bugreport
accordingly. Please correct me if I'm wrong.
Ok. This makes sense. Thanks, will try to look into this.

Thanks,

/mjt

Michal Suchanek

unread,
Nov 11, 2014, 9:10:03 AM11/11/14
to
Excerpts from Michael Tokarev's message of Tue Nov 11 14:16:23 +0100 2014:
> 11.11.2014 13:18, Michal Suchanek wrote:
> []
> >> So, to rehash, do I understand it right that you're having
> >> probs with running x86 binaries on arm, when using -user-binfmt
> >> but not when using -user-static ?
> >
> > I am having problem running x86 binaries on arm with either package.
>
> Aha. That is entirely different thing. Retitling the bugreport
> accordingly. Please correct me if I'm wrong.

That's not entirely true. It only fails for static binaries and I
happened to have a statically linked application. I am able to run full
x86 wine at racing snail speed. Probably because it's dynamically
linked.
Michal

Michael Tokarev

unread,
Nov 14, 2014, 2:50:03 AM11/14/14
to
11.11.2014 17:07, Michal Suchanek wrote:
> Excerpts from Michael Tokarev's message of Tue Nov 11 14:16:23 +0100 2014:
>> 11.11.2014 13:18, Michal Suchanek wrote:
>> []
>>>> So, to rehash, do I understand it right that you're having
>>>> probs with running x86 binaries on arm, when using -user-binfmt
>>>> but not when using -user-static ?
>>>
>>> I am having problem running x86 binaries on arm with either package.
>>
>> Aha. That is entirely different thing. Retitling the bugreport
>> accordingly. Please correct me if I'm wrong.
>
> That's not entirely true. It only fails for static binaries and I
> happened to have a statically linked application. I am able to run full
> x86 wine at racing snail speed. Probably because it's dynamically
> linked.

Does it help if you invoke qemu-x86_64[-static] to run your non-working
executables, like, say,

qemu-x86_64 /usr/bin/cdebootstrap-static

?

This way we'll know if it is binfmt registration which is broken or
qemu. It might sure be some missing binfmt bits.

[]
>>> # unrar /?
>>> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>>> Segmentation fault
>>>
>>> # apt-get install cdebootstrap-static:amd64
>>>
>>> # cdebootstrap-static /?
>>> -bash: /usr/bin/cdebootstrap-static: cannot execute binary file

What is the version of unrar and cdebootstrap-static? I want to reproduce
the problem so that it's possible to go from here.

Please note that x86 qemu user target is one of less tested targets,
because it is rather uncommon to run x86 hw on non-x86 platform, usually
it is the opposite.

Thanks,

/mjt

Michael Tokarev

unread,
Nov 14, 2014, 3:00:03 AM11/14/14
to
14.11.2014 10:43, Michael Tokarev wrote:
> 11.11.2014 17:07, Michal Suchanek wrote:
>> Excerpts from Michael Tokarev's message of Tue Nov 11 14:16:23 +0100 2014:
[]
>>>> I am having problem running x86 binaries on arm with either package.
>>>
>>> Aha. That is entirely different thing. Retitling the bugreport
>>> accordingly. Please correct me if I'm wrong.
>>
>> That's not entirely true. It only fails for static binaries and I
>> happened to have a statically linked application. I am able to run full
>> x86 wine at racing snail speed. Probably because it's dynamically
>> linked.

And also, which variant of arm host/hardware do you have? Which arch
it is, -- arm, armel, or arm64?

Michal Suchanek

unread,
Nov 14, 2014, 4:40:04 AM11/14/14
to
Excerpts from Michael Tokarev's message of Fri Nov 14 08:43:32 +0100 2014:
> 11.11.2014 17:07, Michal Suchanek wrote:
> > Excerpts from Michael Tokarev's message of Tue Nov 11 14:16:23 +0100 2014:
> >> 11.11.2014 13:18, Michal Suchanek wrote:
> >> []
> >>>> So, to rehash, do I understand it right that you're having
> >>>> probs with running x86 binaries on arm, when using -user-binfmt
> >>>> but not when using -user-static ?
> >>>
> >>> I am having problem running x86 binaries on arm with either package.
> >>
> >> Aha. That is entirely different thing. Retitling the bugreport
> >> accordingly. Please correct me if I'm wrong.
> >
> > That's not entirely true. It only fails for static binaries and I
> > happened to have a statically linked application. I am able to run full
> > x86 wine at racing snail speed. Probably because it's dynamically
> > linked.
>
> Does it help if you invoke qemu-x86_64[-static] to run your non-working
> executables, like, say,
>
> qemu-x86_64 /usr/bin/cdebootstrap-static
>
> ?

# qemu-x86_64 /usr/bin/cdebootstrap-static
/usr/bin/cdebootstrap-static: missing suite argument
Try `/usr/bin/cdebootstrap-static --help' for more information.
# cdebootstrap-static
-bash: /usr/bin/cdebootstrap-static: cannot execute binary file: Exec
format error

>
> This way we'll know if it is binfmt registration which is broken or
> qemu. It might sure be some missing binfmt bits.
>
> []
> >>> # unrar /?
> >>> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> >>> Segmentation fault
> >>>
> >>> # apt-get install cdebootstrap-static:amd64
> >>>
> >>> # cdebootstrap-static /?
> >>> -bash: /usr/bin/cdebootstrap-static: cannot execute binary file
>
> What is the version of unrar and cdebootstrap-static? I want to reproduce
> the problem so that it's possible to go from here.

Just whatever was in the archive:
ii cdebootstrap-static 0.6.3 amd64 Bootstrap a Debian system - static binary
ii unrar 1:5.0.10-1 amd64 Unarchiver for .rar files (non-free version)

>
> Please note that x86 qemu user target is one of less tested targets,
> because it is rather uncommon to run x86 hw on non-x86 platform, usually
> it is the opposite.

If somebody was using the emulation bug like this would not exist. The
emulation also does not work that well - the unrar binary is crashing
in the emulation and presumably just runs normally on x86.

CPU is Allwinner A13 sun5i ARM Cortex A8 ARMv7, armhf architecture:

# dpkg-architecture
DEB_BUILD_ARCH=armhf
DEB_BUILD_ARCH_BITS=32
DEB_BUILD_ARCH_CPU=arm
DEB_BUILD_ARCH_ENDIAN=little
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_GNU_CPU=arm
DEB_BUILD_GNU_SYSTEM=linux-gnueabihf
DEB_BUILD_GNU_TYPE=arm-linux-gnueabihf
DEB_BUILD_MULTIARCH=arm-linux-gnueabihf
DEB_HOST_ARCH=armhf
DEB_HOST_ARCH_BITS=32
DEB_HOST_ARCH_CPU=arm
DEB_HOST_ARCH_ENDIAN=little
DEB_HOST_ARCH_OS=linux
DEB_HOST_GNU_CPU=arm
DEB_HOST_GNU_SYSTEM=linux-gnueabihf
DEB_HOST_GNU_TYPE=arm-linux-gnueabihf
DEB_HOST_MULTIARCH=arm-linux-gnueabihf
DEB_TARGET_ARCH=armhf
DEB_TARGET_ARCH_BITS=32
DEB_TARGET_ARCH_CPU=arm
DEB_TARGET_ARCH_ENDIAN=little
DEB_TARGET_ARCH_OS=linux
DEB_TARGET_GNU_CPU=arm
DEB_TARGET_GNU_SYSTEM=linux-gnueabihf
DEB_TARGET_GNU_TYPE=arm-linux-gnueabihf
DEB_TARGET_MULTIARCH=arm-linux-gnueabihf
# cat /proc/cpuinfo
Processor : ARMv7 Processor rev 2 (v7l)
BogoMIPS : 298.17
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc08
CPU revision : 2

Hardware : sun5i
Revision : 0000
Serial : 0000000000000000

Thanks

Michal

Michael Tokarev

unread,
Nov 14, 2014, 5:00:04 AM11/14/14
to
14.11.2014 12:35, Michal Suchanek wrote:
[]
> # qemu-x86_64 /usr/bin/cdebootstrap-static
> /usr/bin/cdebootstrap-static: missing suite argument
> Try `/usr/bin/cdebootstrap-static --help' for more information.
> # cdebootstrap-static
> -bash: /usr/bin/cdebootstrap-static: cannot execute binary file: Exec
> format error

Aha. So it is just the binfmt registration problem -- the magic strings.
I'll take a look at this.

[]
>> Please note that x86 qemu user target is one of less tested targets,
>> because it is rather uncommon to run x86 hw on non-x86 platform, usually
>> it is the opposite.
>
> If somebody was using the emulation bug like this would not exist. The
> emulation also does not work that well - the unrar binary is crashing
> in the emulation and presumably just runs normally on x86.

There are *many* issues with user-mode emulation in qemu today. For one,
threaded applications does not work (they work sometimes by pure luck),
because qemu does not even try to implement multi-threaded support, but
in modern world, lots of non-multithreaded apps uses clone() or some
thread primitives internally behind the scenes, so many even non-MT
apps doesn't work. Implementing mt mode in qemu means major redesign
of whole thing. This is probably a reason why unrar is crashing.
Also, qemu does not implement many system calls, especially more
modern ones.

So it is not that simple -- "if someone was using, it would work" --
no, not at all, things are much more complex, someone should actually
do the work.

> CPU is Allwinner A13 sun5i ARM Cortex A8 ARMv7, armhf architecture:
>
> # dpkg-architecture
> DEB_BUILD_ARCH=armhf

Ok, thank you.

I'll see if I can fix the magic strings -- after that, static executables
should work.

Thanks,

/mjt

Michael Tokarev

unread,
Nov 14, 2014, 6:30:04 AM11/14/14
to
Control: reassign -1 src:qemu
Control: retitle -1 wrong some magic strings in binfmt registration
Control: tag -1 confirmed
[]
>> # qemu-x86_64 /usr/bin/cdebootstrap-static
>> /usr/bin/cdebootstrap-static: missing suite argument
>> Try `/usr/bin/cdebootstrap-static --help' for more information.
>> # cdebootstrap-static
>> -bash: /usr/bin/cdebootstrap-static: cannot execute binary file: Exec
>> format error
>
> Aha. So it is just the binfmt registration problem -- the magic strings.
> I'll take a look at this.

So the problem is quite interesting.

There's a field in ELF header, byte #7, ELF_OSABI. All at least x86
binaries so far had this field = 0, which means OSABI_SYSV. But
static libraries produced by recent gcc/binutils has this field = 3,
which means OSABI_GNU ("with GNU extensions" as comment says). And
this OSABI=3 variant is not handled by our binfmt magic/mask pair.

Now, this field (ELF_OSABI) is a enumeration, and we need to allow
either 0 or 3 in there, but not other variants, since this will
result in qemu trying to execute some clearly different-ABI binaries.
A somewhat too intrusive fix for a freeze, but I'll try.

Michael Tokarev

unread,
Nov 14, 2014, 7:10:04 AM11/14/14
to
Control: tag -1 + patch pending

> So the problem is quite interesting.
>
> There's a field in ELF header, byte #7, ELF_OSABI. All at least x86
> binaries so far had this field = 0, which means OSABI_SYSV. But
> static libraries produced by recent gcc/binutils has this field = 3,
> which means OSABI_GNU ("with GNU extensions" as comment says). And
> this OSABI=3 variant is not handled by our binfmt magic/mask pair.
>
> Now, this field (ELF_OSABI) is a enumeration, and we need to allow
> either 0 or 3 in there, but not other variants, since this will
> result in qemu trying to execute some clearly different-ABI binaries.
> A somewhat too intrusive fix for a freeze, but I'll try.

For now I just extended the mask to allow either 0, 1, 2 or 3 in this
(ELF_OSABI) field. You can do it locally -- in /var/lib/binfmts/qemu-x86_64,
change 7th byte (counting from 0) in the mask (the string which starts
with \xff\xff...) from 0xff to 0xfb and re-run /etc/init.d/binfmt-support.
After that, your static x86 binaries should at least try to work in qemu.

Note again the bytes are counted from 0, not from 1. It should look
like this:

\xff\xff\xff\xff\xff\xfe\xfe\xfb\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff
0 1 2 3 4 5 6 7 ^^

Since I don't have access to arm box where I can verify this, can you
please try this for me and tell if it fixes this issue?

Michal Suchanek

unread,
Nov 14, 2014, 7:50:05 AM11/14/14
to
Excerpts from Michael Tokarev's message of Fri Nov 14 12:56:46 +0100 2014:
> Control: tag -1 + patch pending
>
> > So the problem is quite interesting.
> >
> > There's a field in ELF header, byte #7, ELF_OSABI. All at least x86
> > binaries so far had this field = 0, which means OSABI_SYSV. But
> > static libraries produced by recent gcc/binutils has this field = 3,
> > which means OSABI_GNU ("with GNU extensions" as comment says). And
> > this OSABI=3 variant is not handled by our binfmt magic/mask pair.
> >
> > Now, this field (ELF_OSABI) is a enumeration, and we need to allow
> > either 0 or 3 in there, but not other variants, since this will
> > result in qemu trying to execute some clearly different-ABI binaries.
> > A somewhat too intrusive fix for a freeze, but I'll try.
>
> For now I just extended the mask to allow either 0, 1, 2 or 3 in this
> (ELF_OSABI) field. You can do it locally -- in /var/lib/binfmts/qemu-x86_64,
> change 7th byte (counting from 0) in the mask (the string which starts
> with \xff\xff...) from 0xff to 0xfb and re-run /etc/init.d/binfmt-support.
> After that, your static x86 binaries should at least try to work in qemu.
>
> Note again the bytes are counted from 0, not from 1. It should look
> like this:
>
> \xff\xff\xff\xff\xff\xfe\xfe\xfb\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff
> 0 1 2 3 4 5 6 7 ^^
>
> Since I don't have access to arm box where I can verify this, can you
> please try this for me and tell if it fixes this issue?

Presumably you could add multiple magicks (in one file or in multiple
files if one cannot support them).

However, this does not seem to fix the issue:

root@sun5i:~# cdebootstrap-static
-bash: /usr/bin/cdebootstrap-static: cannot execute binary file: Exec
format error
root@sun5i:~# qemu-x86_64 /usr/bin/cdebootstrap-static
/usr/bin/cdebootstrap-static: missing suite argument
Try `/usr/bin/cdebootstrap-static --help' for more information.
root@sun5i:~# grep /usr/bin/qemu-x86_64 /var/lib/binfmts/*
/var/lib/binfmts/qemu-x86_64:/usr/bin/qemu-x86_64
root@sun5i:~# cat /var/lib/binfmts/qemu-x86_64
qemu-user-binfmt
magic

0
\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x3e\x00
\xff\xff\xff\xff\xff\xfe\xfe\xfb\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff
/usr/bin/qemu-x86_64

yes


Thanks

Michal
0 new messages