While I was running kubectl command in my ubuntu 16.04 os which is a 32 bit machine, I was getting
cannot execute binary file: Exec format error
Can some one tell me whether Kubernetes works on 32 bit machine or not ?
Currently there are no ready-made binaries for 32bit systems at: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.7.md#downloads-for-v1710
You can build kubernetes from source though: https://kubernetes.io/docs/getting-started-guides/binary_release/#building-from-source
As a commenter mentioned, there is support for 32bit systems for the client tool, kubectl: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.7.md#client-binaries
Related
I'm very new to Pulsar. Looking at the documentation about how to install a Standalone Pulsar system, I see the following sentence :
"Currently, Pulsar is available for 64-bit macOS, Linux, and Windows. To use Pulsar, you need to install 64-bit JRE/JDK 8 or later versions."
So Windows is supported. I downloaded the Pulsar binaries and unzip it to some location on my workstation.
But the /bin folder does not contain any Windows batch/executable. Only Unix shell script a provided.
My question is how do we start a Stand alone Pulsar on Windows as obviously the command "bin/pulsar standalone" does not work on Windows systems.
Thanks
You can run Pulsar on Docker or K8. That is your best option for Windows.
you can try Windows with Linux subsystem.
I don't really recommend using the standalone Pulsar on Windows.
C# for Windows client is solid though.
Run a training environment free here https://www.academy.streamnative.io/
there.
I'm trying to install the Microchip XC8 compiler on a Ubuntu container to make a pipeline for building the project with Gitlab CI. But there's no response after I run the "xc8-v1.45-full-install-linux-installer.run" file.
Here is the environment I have:
Official Ubuntu 18.04 LTS image on a Docker container
Docker version 19.03.13
Windows 10 as Docker host
Microchip XC8 v1.45 compiler
And the commands I used for downloading and installing are as following:
# Download XC8 from the Microchip official site
wget http://ww1.microchip.com/downloads/en/DeviceDoc/xc8-v1.45-full-install-linux-installer.run
# Change the access permission
chmod +x xc8-v1.45-full-install-linux-installer.run
# Execute the ".run" file
./xc8-v1.45-full-install-linux-installer.run
After I did them all, there's no response. Obviously, something went wrong.
I have tried the installation process above on a native Ubuntu computer, and it just works fine.
Is there any prerequisite I missed? Or there have some ways for me to achieve the same purpose?
Thanks!
I was having this problem on 64 bit Ubuntu 20.04 as well.
I had several problems, could not change execution bit because it was on an NTFS partition and the executable required 32 bit libraries to run.
First I had to move the file from an NTFS partition so that I could set the file to executable. In my case I moved it to my downloads directory and then in that folder executed:
sudo chmod +x ./xc8-v1.42-full-install-linux-installer.run
It still would not run, so I checked its type by executing:
file ./xc8-v1.42-full-install-linux-installer.run
which resulted in the response:
./xc8-v1.42-full-install-linux-installer.run: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, no section header
Eventually the main solutions was to install 32 bit libraries:
sudo apt-get install lib32z1
Finally I could install install that 32 bit library. Then running this worked:
sudo ./xc8-v1.42-full-install-linux-installer.run
Using existing MPLAB Docker repo
This GitLab.com project exists:
MPLAB X IDE/IPE podman/docker container
This may not help with your .run file problem, but maybe switching to an existing docker container might make it easier for you.
They also work with .run files, so you may find your solution over there as well.
Features:
Has a general-purpose installation of MPLAB X and the toolchain.
X11 forwarding for working in the IDE is supported.
Can use USB from inside the container.
Requires some setup. See readme for installation instructions.
MIT License
Need to test this still myself, but just wanted to share here, might just as well.
Posted in the microchip forums by the creator:
Dockerfile for MPLAB X IDE/IPE and toolchains
Im wondering if its possible to use very old Linux Distribution like Debian GNU/Linux 3.1 (Sarge) and create a base-image of it to run legacy code not working under "younger" distros.
Only Thing i found about it was somebody successfully using Ubuntu Feisty: Run old Linux release in a Docker container?
Are there any known limitations?
Your host needs to have a minimal version of the Linux kernel, and that version is 3.10
See
Docker minimum kernel version 3.8.13 or 3.10
extract from the previous link
There's also a shell-script to check if your system has the required dependencies in place and to check which features are available;
https://github.com/docker/docker/blob/master/contrib/check-config.sh
So you can use this to check if you will be able to use docker on this host.
From
https://wiki.debian.org/DebianSarge?action=show&redirect=Sarge
I see
kernel : linux 2.4.27 and 2.6.8
So it may not work
I'm able to run the ARM images (eg. hypriot/rpi-node) in Docker on Windows (64bit), but in all linux x86/64 machines I've tried (Debian, CoreOS, Alpine etc) I get the following error - which makes sense to me but I dont get why it'd run in Docker on Windows then, and I wonder whether I'm missing some opportunity to use an x86 machine as a build server for ARM images (ie. the in google/aws cloud/azure). Any ideas how I might be able to?
docker run -ti hypriot/rpi-node ls
standard_init_linux.go:175: exec user process caused "exec format error"
Docker for windows (and docker for mac) both use a linux vm to host containers. However, the difference between the linux vm they use and your linux machines is the fact that their VM has a kernel system called binfmt_misc setup to call qemu whenever it encounters a binary for a foreign architecture (https://github.com/linuxkit/linuxkit/blob/1c552f7a9db7f0660d3c83362d241e54142323ca/pkg/binfmt/etc/binfmt.d/00_linuxkit.conf )
If you were to configure your linux machine appropriately, it could be used as a build server for ARM images. Google qemu-user-static for some ideas of how to set it up.
Note that the linuxkit vm uses the 'F' flag which doesn't seem to be standard when configuring a typical linux environment. Without it, you need to put the qemu binary inside the container. I'm not sure why it isn't standard practice to use 'F' in more places (there does seem to be a debian bug to do so https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868030 )
On Windows and Mac docker works under Linux VM. So, I think, that for your container under Windows started ARM Linux VM. But under native Linux used native architecture.
The "exec format error" confirms that you are not running your docker image on the correct architecture.
I had this error trying to run a x86 docker image on a Raspberry Pi 2 (Which works with an ARM architecture). I am pretty sure it might be the same error when you do it the other way round.
So, as Kulti said, Windows/MAC must have started an ARM Linux VM.
If you wish to work with ARM docker images on Linux, you may want to try running a linux docker VM manually. I think you can do it using "docker-machine" even on linux : Docker documentation for docker-machine. (Haven't done it myself so I am not sure)
Hope this helps.
Docker on Windows uses a Linux VM which has been configured such that it can run images of other architectures through Qemu user mode emulation. You can configure native linux in a similar way and it too will then run ARM images. There is a well written three part series that describes it all in detail
Main thing to take away from Part#1 is that any file on Linux is executed through an interpreter (even binary files). The choice of interpreter is configurable, through binfmt_misc, based on byte patterns at the beginning of file or filename extension etc.
Part#2 builds on Part#1 to show how to configure Linux kernel (installed on any architecture) to interpret ARM binaries using Qemu User Emulation.
Finally Part#3 shows how to apply the same trick this time to a linux setup in a docker container which means that linux docker container (which could be for any architecture) will be able to execute ARM binaries.
Important thing to note here is that there is nothing special about docker implementation or containerization that allows docker on Windows to be able to execute ARM binaries. Instead any Linux setup (whether on bare metal or in a container) can be configured to execute ARM binaries through Qemu's user mode emulation of an ARM cpu.
I know this post is old but I will post my solution here in case someone came here through Google.
This happen because your Docker host is not able to run images with AMR architecture. To be enable this in your Docker just run:
docker run --rm --privileged hypriot/qemu-register
More info you can find on this post.
You need the kernel configured for qemu's binfmt_misc module, and the container needs to have the static binaries used by qemu available inside the container filesystem.
You can load the files on the host with the hyperiot/qemu-register image, however I prefer the distribution vendor packages when available (ensures that I get patches when I update). For Debian, the imporant packages is qemu-user-static which you can install as root with:
apt-get update && apt-get install qemu-user-static
Ensure the kernel module is loaded (as root):
modprobe binfmt_misc
Then when running the container, you can mount the static qemu binaries into your container rather than packaging them inside your image, e.g. for the arm arch:
docker run -it --rm \
-v /usr/bin/qemu-arm-static:/usr/bin/qemu-arm-static:ro \
hypriot/rpi-node /bin/sh
Docker includes binfmt_misc in the embedded Linux VM's used on Docker for Desktop, and there appears to be some additional functionality to avoid the need to manually mount the static qemu files inside the container.
I am trying to follow this tutorial for building and running an MPI application on an ARM based Ubuntu 11.10 system.
When installing open-mpi environment on my PC machine, the sample program runs well. However, trying the same on the ARM machine, the terminal hangs up and I need to kill the MPI process from a second terminal in order to release it.
The MPI packages I installed using apt-get, on both machines, were mpi-default-dev and mpi-default-bin, so I assume that the packages are as updated as they can be.
The first sample program in the tutorial makes every process prints a "hello" message with some info. On the PC I get messages from all 8 processes (although running on a single core) and then the program ends. On the ARM, I get no output at all. The program is just stuck immediately after launch.
Any idea on what's wrong? I am not sure even where to start to debug this?
Update: I tried removing the OpenMPI package and install the alternative MPICH2 package - but the result is just the same.
Ubuntu 11.10 did not ship with a functional Open MPI implementation for ARM (although it may have shipped with a nonfunctional one). Ubuntu 12.04 did.
I would recommend building your own Open MPI from source - available at http://www.open-mpi.org/software/ompi/v1.6/, unless you can update to a more recent version of Ubuntu.
Alternatively, you could rebuild the 11.10 package using the fixes pointed out in https://bugs.launchpad.net/ubuntu/+source/openmpi/+bug/949044.