uname -m shows wrong architecture

[daald]

Running uname -m show the wrong architecture:

me$ docker run 32bit/ubuntu:14.04 /bin/uname -m
x86_64

this is a problem for autoconf/automake because it will not be able to detect the arch correctly.

You can hack around this using:

me$ docker run 32bit/ubuntu:14.04 linux32 /bin/uname -m
i686

I tried to fix it permanently using ...

ENTRYPOINT ["/usr/bin/linux32", "/bin/sh", "-c"]

... but the result was the parameters (-m for uname) were not submitted correctly anymore.

For completeness: Docker itself should provide an ARCH command for Dockerfiles to avoid this problem

[dashohoxha]

Docker itself officially supports only the 64bit arch.

I don't know how the uname command works, and why it should give the wrong answer. Maybe you are trying it on a 64bit machine and it is just telling the truth.

[daald]

Read again my post. Build scripts are using calls like dpkg-architecture -qDEB_HOST_ARCH which indirectly call uname -m. Compiling in this 32bit container will make debian buildfiles trying to build a 64bit executable which will fail because libraries and compiler don't match this target. the linux32 command changes how the kernel reports the architecture to the called process and all its children. I can simply demonstrate this without docker:

me$ linux32 uname -m
i686
me$ linux64 uname -m
x86_64

Prefixing each command line with linux32 should be enough to fix this. I just don't know how to use ENTRYPOINT correctly

[dashohoxha]

This is not a Docker problem and neither a 32bit/ubuntu problem.
Trying to use ENTRYPOINT for solving it is simply stupid; read the Docker docs first.

Just make an alias like this: alias uname='linux32 uname' before starting the compilation.
And if it doesn't work try to find some other solution.

[daald]

alias doesn't work in scripts and Dockerfiles, but ENTRYPOINT ["/usr/bin/linux32", "--"] solved my problem. The Docker docs are huge. I didn't find a place which says that using ENTRYPOINT is stupid

[remram44]

Thanks for the workaround @daald! This is what I was missing!

[jcoffland]

To fix this problem for all invocations of /bin/sh, including docker image build commands, add these commands near the top of your Dockerfile:

RUN mv /bin/sh /bin/sh.orig && \
  echo '#!/bin/sh.orig\n/usr/bin/linux32 /bin/sh.orig "$@"' > /bin/sh && \
  chmod +x /bin/sh

This replaces /bin/sh with a script which transparently runs the original /bin/sh under /usr/bin/linux32. You can do the same for /bin/bash if you like.

[jcoffland]

Alternatively you can just replace /bin/uname like this:

RUN mv /bin/uname /bin/uname.orig && \
  echo '#!/bin/sh\n/usr/bin/linux32 /bin/uname.orig "$@"' > /bin/uname && \
  chmod +x /bin/uname

[remram44]

@jcoffland You understand that uname is a system call right? This will NOT help.

[jcoffland]

@remram44 you should try it before commenting. uname() is a system call but /bin/uname is an executable program.

[remram44]

Your code will fix direct calls to the uname binary but anything using the system call directly will still be broken. You fix a very small part of the issue here.

[jcoffland]

@remram44 You're thinking about an idealized solution. I'm presenting a practical one. The title of this issue is uname -m shows wrong architecture. My solution solves that problem.

[remram44]

You should consider working for Volkswagen. "See? The tests pass now!" You could also replace uname by a script that always prints "i686" no matter the command-line?

What's the point of lying to the user while apt-get, compilers and everything else will still explode in his face?

ioft/u386-ubuntu has been fixed, so it's what I'll use. Unsubscribing from this version that does not seem supported anyway.

[dashohoxha]

Unsubscribing from this version that does not seem supported anyway.

Yes guys, this is a simple solution, built for simple people, by a simple guy, who does not even need to use it anymore. Actually I don't understand anything at all from the discussion above. So, if you can find any better solution, please follow it.

Alternatively, you can try to improve this one (just for the sake of the namespace: docker-32bit). If you need access rights for this, please ask me.

[remram44]

The fix is ENTRYPOINT ["linux32", "--"]. ioft maintains an image at https://github.com/ioft/dockerhub that has the fix and that he keeps up to date, so no action is necessary here 😄

[Logout22]

@remram44 We cannot apply such a fix because the script does not create a Dockerfile, but rather uses Docker directly.

@dashohoxha Given your last statement, do you think it would make sense to deprecate the repo officially in the Readme and link to the alternative @remram44 mentioned?

[dashohoxha]

Given your last statement, do you think it would make sense to deprecate the repo officially in the Readme and link to the alternative @remram44 mentioned?

My last statement was: if you can, please help to keep this repo up-to-date and to improve it.
@Logout22 do you think that this repo should be deprecated?

Actually I don't even understand the bug that is being discussed here. Are they trying to run a 32bit container inside a 64bit host, but it does not work as expected? What actually are the expectations for such a situation?

[Logout22]

Exactly. Compilation fails because uname reports architecture correctly according to the running kernel. Prefixing every command with linux32 is a hack that wraps the processes in the docker into another environment that pretends the computer is running on a 32-bit architecture (as described here for example: http://linux.die.net/man/8/linux32 ).

The reason I would like to deprecate this repo is not that missing feature in particular, but the fact that due to a missing Dockerfile in the setup we will not be able to specify the container's creation in detail. Apparently, someone else already did a better job at that; a similarly easy solution that seems to provide more flexibility and apparently is better aligned with Docker's general architecture.

Deprecating the repo is not the same as deleting it. We would only claim that our hands are tied and development and usage should continue elsewhere (and I think that seems to be the case, given the script's limitations, also the ones we discussed in my original pull request). The code would not be lost -- if your approach turns out to be more useful for some reason, we can easily remove the deprecation note and continue working here.

[dashohoxha]

This project would be deprecated if the docker command "import" was deprecated. Otherwise it is just a different approach, neither better nor worse than the others.
I don't think that deprecating a project makes sense, people can choose to use it or not depending on their needs and situation.

[dashohoxha]

The reason I would like to deprecate this repo is not that missing feature in particular, but the fact that due to a missing Dockerfile in the setup we will not be able to specify the container's creation in detail.

In my opinion, that is not a missing feature. Also, the lack of Dockerfile is not a problem, because we just build the image, we don't give the details of the container. The users can use this image within their own Dockerfile and specify the container details for themselves.

Apparently, someone else already did a better job at that; a similarly easy solution that seems to provide more flexibility and apparently is better aligned with Docker's general architecture.

I don't agree that they are more flexible or better solutions. But if you wish you can add on README a list of 2-3 links to similar projects, so that the users are better informed about their choises.

By the way, did you stop using this project? Let me know if you don't want to maintain it anymore, so that I can look for other maintainers.

[Logout22]

Honestly, I stopped using Docker altogether due to a lot of bugs and limitations that bothered me, so if you like you can revoke my admin rights again. Thanks!

[dashohoxha]

Thanks for letting me know.

[ericcurtin]

I normally put something like this in my x86 32 bit dockers:

RUN echo $'#!/usr/bin/perl\n\
\n\
use strict;\n\
use warnings;\n\
\n\
use Getopt::Long qw(GetOptions);\n\
\n\
my $opts = {};\n\
GetOptions($opts, "kernel-name|s", "nodename|n", "machine|m", "processor|p",\n\
           "hardware-platform|i", "operating-system|o");\n\
\n\
if ($opts->{"kernel-name"}) {\n\
  print("Linux\n");\n\
} elsif ($opts->{"nodename"}) {\n\
  exec("hostname");\n\
} elsif ($opts->{"machine"} || $opts->{"processor"}) {\n\
  print("i686\n");\n\
} elsif ($opts->{"hardware-platform"}) {\n\
  print("i386\n");\n\
} elsif ($opts->{"operating-system"}) {\n\
  print("GNU/Linux\n");\n\
}\n' > /bin/uname

Hacky, but it's hard to avoid