I was thinking that 64 bit host machine can launch 32 bit LXC as we have a option of specifying arch during LXC creation.
hostmc$> lxc-create -n ubuntu -t ubuntu -- i386
Host machine:
hostmc$> uname -a Linux D 3.11.0-26-generic #45~precise1-Ubuntu SMP Tue Jul 15 04:02:35 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
But then on login in to the 32 bit LXC container, I find uname -a specify the arch as x86_64 and even running file command also specify the arch as x86_64 instead of i386
hostmc$> lxc-console -n ubuntu
ubuntu#ubuntu:~$ uname -a
Linux ubuntu 3.11.0-26-generic #45~precise1-Ubuntu SMP Tue Jul 15 04:02:35 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
ubuntu#ubuntu:~$ file /bin/ls
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x37cdd635587f519989044055623abff939002027, stripped
On my Debian 8.2 (jessie), I get:
root#srv1:~# uname -a
Linux srv1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u4 (2015-09-19) x86_64 GNU/Linux
root#srv1:~# lxc-create -n vm -t debian --dir /data/vm -- -a i386
...
root#srv1:~# lxc-start -n vm
...
(in the VM)
root#vm:~# uname -a
Linux vm 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u4 (2015-09-19) i686 GNU/Linux
The key difference with your example is the -a flag.
Although this is late, but it might be helpful to someone.
I did it in Ubuntu Bionic with a Bionic 32-bit guest with the following:
sudo lxc launch images:ubuntu/18.04/i386 GuestName
# run with
sudo lxc exec GuestName bash
and uname -a returns:
Linux MachineName 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:33:07 UTC 2019 i686 i686 i686 GNU/Linux
So it's 32-bit, and the application I'm debugging confirmed it.
When the host runs a 64 bit system the containers will always show a 64 bit system when you execute uname.
Containers and the host share the same Linux kernel instance. Containers are encapsulated processes but they still run in the host kernel. And if the host kernel is a 64 bit kernel the container processes are always processes that are executed 64 bit.
Related
My Dockerfile works on x86 machine, but fails on the machine with arm64 architecture; specifically on a1.2xlarge (an aws EC2-instance).
Error on running docker compose up -d
#0 0.462 exec /bin/sh: exec format error
------
failed to solve: executor failed running [/bin/sh -c apt-get update]: exit code: 1
Dockerfile looks like this
FROM phusion/passenger-ruby27
ENV HOME /root
RUN apt-get update
docker -v
Docker version 20.10.17, build 100c701
uname -a
Linux Ubuntu SMP Thu Jun 9 13:06:11 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux
lsb_release -a
Ubuntu 20.04.4 LTS
phusion/passenger-ruby27 repository separates the arm64-based images via tags (as of Nov-2022).
I.e. 2.3.1 and 2.3.1-arm64
Assuming that you want to build an arm64 image on your arm64 instance, a simple way to resolve this is to pass the tag as a build argument.
Dockerfile:
ARG BASE_TAG
FROM phusion/passenger-ruby27:$BASE_TAG
ENV HOME /root
RUN apt-get update
Build examples:
# on arm
$ docker build --build-arg BASE_TAG=2.3.1-arm64 .
# on amd
$ docker build --build-arg BASE_TAG=2.3.1 .
The official image ubuntu18.04 of the installed Docker
PS C:\Users\17293> docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
ubuntu 18.04 4eb8f7c43909 2 weeks ago 63.1MB
PS C:\Users\17293> docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
12910e0535ad ubuntu:18.04 "bash" 2 hours ago Up 2 hours mineos
I tried poweroff, shutdown and halt, but how can I shutdown?
root#12910e0535ad:/# uname -a
Linux 12910e0535ad 5.4.72-microsoft-standard-WSL2 #1 SMP Wed Oct 28 23:40:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
root#12910e0535ad:/# poweroff
bash: poweroff: command not found
root#12910e0535ad:/# shutdown
bash: shutdown: command not found
root#12910e0535ad:/# halt
bash: halt: command not found
root#12910e0535ad:/#
From the host you can use stop:
docker stop container_ip/name
From the container itself, if you have an interactive command line, use exit
Inside an ubuntu docker container based on this image:
docker.elastic.co/elasticsearch/elasticsearch:7.7.0
I am trying to run apt-get install (yes I am aware I should build a new image from a dockerfile but still trying to understand why it fails) but get the below error:
# uname -a
Linux 217054a34cb7 5.3.0-55-generic #49-Ubuntu SMP Thu May 21 12:47:19 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
# apt-get install
bash: apt-get: command not found
From what I can see the above is ubuntu so whats up with bash: apt-get: command not found?
UPDATE:
Its CentOS:
# cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
So it works with:
yum install openssl
But why does
# uname -a
Linux 217054a34cb7 5.3.0-55-generic #49-Ubuntu SMP Thu May 21 12:47:19 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
return Ubuntu SMP?
The elasticsearch image isn't Ubuntu based.
Docker isn't emulating a kernel, instead it uses the (already running) kernel of the host system in every container, so the kernel information in every container will be the kernel information of the host. Your host is Ubuntu, but the image isn't.
I am using the below command in the dockerfile to automatically start mysql on docker run:
ENTRYPOINT service mysql start && bash
The above command is working fine in some system but not in all. I also have tried the below command but still facing the same issue.
EXPOSE 3306
CMD /etc/init.d/mysql start && \
/bin/bash
I am getting the below error in some system:
* Starting MySQL database server mysqld [fail]
So can anyone please help me solve this issue. So that my docker container can run on all type of system where docker can be installed.
First, it depends on your exact docker run command.
As commented here, you approach works with docker run -itd ...
Second, it depends on the host, which should be compatible with docker execution (ie, its kernel should be the right architecture, 64bits not 32, recent enough...)
The OP adds:
I am using docker run -it docker_image_name command to run the docker image and second system i.e. Linux corona2 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux its not working.
I have used 1.8.3 version to build my image and.
is it because of the community edition version as ce is written with 18.03.1-ce.
Then yes: make sure to use the same docker version for building and running (on both servers)
I am creating a very basic image on my debian wheezy host machine. This is the Dockerfile:
FROM ubuntu:trusty
USER root
# Activate multiverse repos
RUN echo 'deb http://archive.ubuntu.com/ubuntu/ trusty universe multiverse' >> /etc/apt/sources.list
RUN echo 'deb http://security.ubuntu.com/ubuntu trusty-security universe multiverse' >> /etc/apt/sources.list
RUN echo 'deb http://archive.ubuntu.com/ubuntu/ trusty-updates universe multiverse' >> /etc/apt/sources.list
RUN apt-get update
RUN apt-get install -y supervisor
WORKDIR /
CMD ["/usr/bin/supervisord", "-n"]
To build the image, I used docker build -t basic-ubuntu .
To run the container, I used docker run -d basic-ubuntu
To go into the container, I used docker exec -i -t <container_id> bash
When I am into the container, what I see is that the container's root directory / has the same content as the host. When I create a file on the container, it's also created on the host. Even when I add in the Dockerfile a RUN apt-get install -y of some package I don't have on the host, then I don't find it on the container. Actually even the $PATH variable on the container is the same as the host.
Here are some info on my env
host$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 7.8 (wheezy)
Release: 7.8
Codename: wheezy
host$ docker version
Client:
Version: 1.10.1
API version: 1.22
Go version: go1.5.3
Git commit: 9e83765
Built: Thu Feb 11 19:20:12 2016
OS/Arch: linux/amd64
Server:
Version: 1.10.1
API version: 1.22
Go version: go1.5.3
Git commit: 9e83765
Built: Thu Feb 11 19:20:12 2016
OS/Arch: linux/amd64
The mounts shown by docker inspect
"Mounts": []
For the full docker inspect trace: http://pastebin.com/t4uSu4ZH
I think that the problem comes from the docker exec step. Because the build and run seem to work correctly.
I think that the problem comes from the docker exec step
That is certainly the case, considering a container is there to isolate you from the host.
(different filesystem, process, root, user, ...)
When you "exec bash" to a container, you should see a prompt:
root#<short_container_id>
If you don't see that, it is because somehow your docker exec did not execute properly.
If you do see that, then what you think is on the host is actually still the container content.
Also relevant, there is a potential bug around -i (interactive) when used with docker exec.
See "Why do there exist “-i” and “-t” options for the “docker exec” command?".
The OP amine confirms it is the case in the comments:
Issue 8755 ("Docker tty is not a tty with docker exec") means -t (tty) does not correctly opens a tty on centos7 (not centos6).
This happens even if TERM is set to xterm (don't forget issue 9299: docker exec does not set TERM env when -t passed)
The other issue mentioned by the Op is:
When I went back to the howto install docker in debian, I found that in the prerequisites: "kernel must be 3.10 at minimum" and "These older versions are known to have bugs".
And my debian's kernel version is 3.2.
The solution was to upgrade to a newer debian version, with a kernel version above 3.10.
I met the same issue where docker volume mount function was not working correctly . And this turned out to be the kernel version issue. After I upgrade my Debian kernel from 3.2 up to 3.16, everything works fine.
$ uname -a
Linux 3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3~bpo70+1 (2016-01-19) x86_64 GNU/Linux