Docker - /bin/sh: <file> not found - bad ELF interpreter - how to add 32bit lib support to a docker image - linux

UPDATE – Old question title:
Docker - How to execute unzipped/unpacked/extracted binary files during docker build (add files to docker build context)
--
I've been trying (half a day :P) to execute a binary extracted during docker build.
My dockerfile contains roughly:
...
COPY setup /tmp/setup
RUN \
unzip -q /tmp/setup/x/y.zip -d /tmp/setup/a/b
...
Within directory b is a binary file imcl
Error I'm getting was:
/bin/sh: 1: /tmp/setup/a/b/imcl: not found
What was confusing, was that displaying the directory b (inside the dockerfile, during build) before trying to execute the binary, showed the correct file in place:
RUN ls -la /tmp/setup/a/b/imcl
-rwxr-xr-x 1 root root 63050 Aug 9 2012 imcl
RUN file /tmp/setup/a/b/imcl
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped`
Being a Unix noob at first I thought it was a permission issue (root of the host being different than root of the container or something) but, after checking, the UID was 0 for both so it got even weirder.
Docker asks not to use sudo so I tried with su combinations:
su - -c "/tmp/setup/a/b/imcl"
su - root -c "/tmp/setup/a/b/imcl"
Both of these returned:
stdin: is not a tty
-su: /tmp/setup/a/b: No such file or directory
Well heck, I even went and defied Docker recommendations and changed my base image from debian:jessie to the bloatish ubuntu:14.04 so I could try with sudo :D
Guess how that turned out?
sudo: unable to execute /tmp/setup/a/b/imcl: No such file or directory
Randomly googling I happened upon a piece of Docker docs which I believe is the reason to all this head bashing:
"Note: docker build will return a no such file or directory error if the file or directory does not exist in the uploaded context. This may happen if there is no context, or if you specify a file that is elsewhere on the Host system. The context is limited to the current directory (and its children) for security reasons, and to ensure repeatable builds on remote Docker hosts. This is also the reason why ADD ../file will not work."
So my question is:
Is there a workaround to this?
Is there a way to add extracted files to docker build context during a build (within the dockerfile)?
Oh and the machine I'm building this is not connected to the internet...
I guess what I'm asking is similar to this (though I see no answer):
How to include files outside of Docker's build context?
So am I out of luck?
Do I need to unzip with a shell script before sending the build context to Docker daemon so all files are used exactly as they were during build command?
UPDATE:
Meh, the build context actually wasn't the problem. I tested this and was able to execute unpacked binary files during docker build.
My problem is actually this one:
CentOS 64 bit bad ELF interpreter
Using debian:jessie and ubuntu:14.04 as base images only gave No such file or directory error but trying with centos:7 and fedora:23 gave a better error message:
/bin/sh: /tmp/setup/a/b/imcl: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
So that led me to the conclusion that this is actually the problem of running a 32-bit application on a 64-bit system.
Now the solution would be simple if I had internet access and repos enabled:
apt-get install ia32-libs
Or
yum install glibc.i686
However, I dont... :[
So the question becomes now:
What would be the best way to achive the same result without repos or internet connection?
According to IBM, the precise libraries I need are gtk2.i686 and libXtst.i686 and possibly libstdc++
[root#localhost]# yum install gtk2.i686
[root#localhost]# yum install libXtst.i686
[root#localhost]# yum install compat-libstdc++

UPDATE:
So the question becomes now:
What would be the best way to achive the same result without repos or internet connection?
You could use various non-official 32-bit images available on DockerHub, search for debian32, ubuntu32, fedora32, etc.
If you can't trust them, you can build such an image by yourself, and you can find instruction on DockerHub too, e.g.:
on f69m/ubuntu32 home page, there is a link to GitHub repo used to generate images;
on hugodby/fedora32 home page, there is an example of commands used to build the image;
and so on.
Alternatively, you can prepare your own image based on some official image and add 32-bit packages to it.
Say, you can use a Dockerfile like this:
FROM debian:wheezy
ENV DEBIAN_FRONTEND noninteractive
RUN apt-get update
RUN apt-get install -y ia32-libs
...and use produced image as a base (with FROM directive) for images you're building without internet access.
You can even create an automated build on DockerHub that will rebuild your image automatically when your Dockerfile (posted, say, on GitHub) or mainline image (debian in the example above) changes.
No matter how did you obtain an image with 32-bit support (used existing non-official image or built your own), you can then store it to a tar archive using docker save command and then import using docker load command.

You're in luck! You can do this using the ADD command. The docs say:
If <src> is a local tar archive in a recognized compression format
(identity, gzip, bzip2 or xz) then it is unpacked as a directory... When a directory is
copied or unpacked, it has the same behavior as tar -x: the result is
the union of:
Whatever existed at the destination path and
The contents of the
source tree, with conflicts resolved in favor of “2.” on a
file-by-file basis.

Related

Linux and Calamares - how they join

I'm working on making a Arch Linux ISO for getting a my custom Linux system. I read about Calamares installer that seems very cool for customizing your own installer. I prepared my ISO and also my Calamares files but I don't understand how they join. i tried several searches but I don't find it.
For example, assuming that I have my ISO files ready under /home/user/archiso/airootfs directory (airootfs will be the root of my future system), I started by compiling and installing Calamares by following several docs, in my case:
$ git clone https://github.com/calamares/calamares.git
$ mkdir -p /home/user/calamares/build
$ cd calamares/build
$ cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr -DWITH_PYTHONQT=ON -DAppStreamQt_DIR=... ..
$ make
$ sudo make install
and I get the Calamares modules in calamares/build/src/modules and brading in calamares/build/src/branding and I customized these files according my needs.
Now that I have ready Calamares and my custom ISO ready, how in general the airootfs can be tied with Calamares installer in order that when I run the ISO on a new machine, the Calamares installer starts automatically at the login?
I tried to edit build/src/modules/unpackfs/unpackfs.conf file by adding:
unpack:
- source: /home/user/archiso_build/iso/arch/x86_64/airootfs.sfs
sourcefs: ext4
but I didn't get the expected behavior because, when I make the ISO by mkarchiso and I mount it in a new VM:
Calamares Installer does not start automatically (maybe there is a specific command that I should store somewhere)
When I start manually Calamares, I get the error on the GUI: users#users module not found; bootloader#bootloader module not found; and so on
How these two entities communicate one each other during the creation of the ISO by mkarchiso?
Source: https://github.com/calamares/calamares/wiki/Develop-Guide
Thanks

Is it possible to generate linux .rpm packages from flutter linux app?

As far as I know, Flutter for linux app only targets snap packaging format.
Is it possible to generate .rpm and .deb (cross-linux platform) software packages from the flutter build?
Kindly post any help on how to package a flutter-linux app as RPM package
Building RPMs and DEBs is doable, but a pretty involved process. I will try to outline the basic process for RPM's as best as I can. The process of making a DEB is mostly the same with a few differences. I will stick to RPM's for now.
The main thing which is a pain is that to build packages you need specific tools which are only available on the distros. So if you want to do this cross platform (generate a RPM on a ubuntu machine for example) we need to use Docker.
Create a Dockerfile which in which we will install the rpm-build package which contains all tools to build RPMs.
FROM centos:7
RUN yum install -y -q rpm-build
Build this dockerfile and remember the docker image, we will need it later.
Execute the following command mkdir -p build/{BUILD,RPMS,SOURCES,SPECS,SRPMS}. This will create the directory structure required for rpmbuild
Create a .spec file, this file is a config file for the rpmbuild command and place it in the build/SPECS directory. The contents of this file are very specific to the what the package has to do. RPMs are very flexible and can do lots of stuff ranging from just copying files to running complex bash scripts on the target machine to perform compilation on the target machine and perform complex installations. Here are some guides which I found useful: package guide, fedora guide, and redhat guide.
Download the files you want to package, often they are distributed as tarballs and place it in the build/SOURCES directory.
Now we can execute the following command docker run --rm -v $(pwd)/build:/rpmbuild {name of image} /bin/bash -c "cd /rpmbuild && rpmbuild --define '_topdir /rpmbuild' -ba SPECS/flutter.spec"
I will break the command down.
docker run --rm -v $(pwd)/build:/rpmbuild {name of image} - we start a container from the image we created earlier, and mount the build dir in which our .spec and .tar.gz are located so the container can see them. --rm cleans up the container after we are done since we don't need it after the first command.
/bin/bash -c - this is a trick since we need to execute 2 command inside the docker container, if we don't do this our shell will thing the && is meant after the docker command and not passed to the container.
"cd /rpmbuild && rpmbuild --define '_topdir /rpmbuild' -ba SPECS/flutter.spec" - move to the mounted build directory and build the RPM package. the -ba option tells rpmbuild to build both the binary and source packages in case you want the source package as well.
If all went well your should now have an .rpm file in the build/RPMS and a source package in the build/SRPMS directory.
For DEB the process is almost the same, except you need a debian or ubuntu docker image, you use the dpkg-deb command to build and you need a control file instead of a .spec file(same purpose different format)
I will also go over some of the key parts of building rpm packages for flutter applications in case the previous answer was ambiguous.
I have already written an article going into details but here I will only highlight the key parts. You can find the article here
Also for simplicity of explanation, I will be using cool-app as an example throughout this post.
1- Run flutter build linux to get the Linux build inside the build folder in your project root directory.
2- Copy your bundle folder someplace else and there, rename it according to app-name-version semantic. e.g. cool-app-1.0.0
3- Create a .desktop file. e.g. cool-app.desktop will look like the following :
[Desktop Entry]
Name=My Cool App
Comment=A cool app that does everything
Exec=/usr/bin/cool-app/cool-app
Icon=/usr/bin/cool-app/data/flutter_assets/assets/icon.svg
Terminal=false
Type=Application
Categories=Utility;
change the properties accordingly and place the .desktop file inside cool-app-1.0.0 directory
4- run mkdir -p rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS} in your home directory.
5- copy the cool-app-1.0.0 directory to ~/rpmbuild/SOURCES.
Due to a problem that as the time of writing this still persists, the rpath for lib*_plugin.so files point to user's build tree path which results in rpmbuild failure.
6- Run patchelf --print-rpath * inside cool-app-1.0.0/lib and check the output. If the output contains a path from your home directory, run patchelf --set-rpath '$ORIGIN' * to fix the rpaths, then check again. now all paths must be $ORIGIN. (This was the way I was able to fix it, not sure if it's the best solution)
You can check this github issue for further information.
7- cd into ~/rpmbuild/SOURCES and run tar --create --file cool-app-1.0.0.tar.gz cool-app-1.0.0 to create a tar.gz file.
8- Create a file named cool-app.spec inside ~/rpmbuild/SPECS directory.
Sample cool-app.spec file :
Name: cool-app
Version: 1.0.0
Release: 1%{?dist}
Summary: Very cool app
BuildArch: x86_64
URL: https://github.com/CoolDev/cool-app
License: GPLv3
Source0: %{name}-%{version}.tar.gz
Requires: bash
%description
A very cool app that does everything
%prep
%setup -q
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/%{_bindir}/%{name}
cp %{name} $RPM_BUILD_ROOT/%{_bindir}/%{name}
cp -R lib $RPM_BUILD_ROOT/%{_bindir}/%{name}
cp -R data $RPM_BUILD_ROOT/%{_bindir}/%{name}
desktop-file-install %{name}.desktop
%clean
rm -rf $RPM_BUILD_ROOT
%files
%{_bindir}/%{name}
/usr/share/applications/
You could use the same template and only change Name,Version,Summery,Release,BuildArch,URL,License,%description and you will most likely be fine.
I went over the spec file in more detail in my article mentioned in the beginning of this post.
9- run rpmbuild --bb cool-app.spec to get your rpm file inside ~/rpmbuild/RPMS directory.

Docker won't copy files from the container to the host's /tmp folder

I am trying to copy a file from a linux container to a linux host using docker cp. I want to copy this file to the /tmp folder on the host machine.
The problem is simple: I can copy to other places, such as my home folder. For example, this works:
docker cp my_container:/certificate.cer /home/adam/Documents/certificate.cer
But this does not work:
docker cp my_container:/certificate.cer /tmp/certificate.cer.
However, the command completes with a zero exit code as if the operation was successful. I get no error feedback, but the file definitely isn't there.
Am I missing something, or is this a bug with the Docker CLI?
edit: From further testing I have noticed that creating a new directory in /tmp, (i.e.
mkdir /tmp/test) Then trying to copy the file into that subfolder, fails with an error: stat /tmp/test/: not a directory.
This seems to indicate that perhaps docker is looking at a different folder? I am not sure where it could be looking though.
Thanks
I believe I have found the answer to this:
Docker was installed as an Ubuntu Snap, which as I understand, is sandboxed. Running sudo ls /tmp/snap.docker/tmp showed me all the files I was missing.
So, it seems the snap version of docker works a little differently than expected. Uninstalling it and reinstalling from apt fixed the problem. :)

Files installed from debian package with dpkg do not belong to root

I created a binary package with this command:
dpkg-deb --build -z9 -Zlzma $(DEB_SRC_DIR) $(DEB_DEST_DIR)
and install it on my Ubuntu 12.04 with this command:
sudo dpkg -i /path/to/package
The contents of the package I think are irrelevant.
Despite the sudo command the files in the installation directory belong to the current user and not to root as I expected.
How can I fix that?
Try to run the dpkg-deb command with fakeroot:
`fakeroot dpkg-deb ...`
(This will only help if the files in the source directory already have the correct ownership, which they probably dont. The problem you're actually trying to solve here, is to create an archive with files in it that belong to user root, which is where fakeroot theoretically helps.)
Let me say though, that what you are doing is not the best way for creating a binary package (far from it).
Instead, create a debian/ directory with dh_make (from the dh-make package), and edit the control file and changelog accordingly. You also need a file debian/install that lists what files you are installing and where they should go. There are various guides on the net (and on Stack Overflow) that explain this process. For example, look at the Debian New Maintainers' Guide.
You can then use dpkg-buildpackage to create a real, standard-conforming Debian package with your files in a reproducible way.
dpkg-deb is a low-level tool for manipulating existing deb files; it's not meant to be used for package creation.

Install librsync on Amazon EC2 instance

I have trouble installing this library called librsync on an Amazon standard linux instance.
I tried this:
yum install librsync-devel
but I got No package librsync available (fair enough I guess!)
I also followed the install instructions, which says:
To build and test librsync from the extracted distribution do;
$ ./configure
$ make all check
I'm no linux expert, I extracted the library files and run these commands:
[ec2-user#ip-**-***-**-*** librsync]$ ./configure
-bash: ./configure: Permission denied
[ec2-user#ip-**-***-**-*** librsync]$ sudo ./configure
sudo: ./configure: command not found
[ec2-user#ip-**-***-**-*** librsync]$ sudo configure
sudo: configure: command not found
I changed permission of the configure file and run the ./configure command again. I got a long list of yes (full log here) and then this:
checking whether g++ accepts -g... no
checking dependency style of g++... none
checking how to run the C++ preprocessor... /lib/cpp
configure: error: C++ preprocessor "/lib/cpp" fails sanity check
I'm totally lost. Any idea how to install this librsync library on EC2 linux instance?
From the error, it looks like your configure script is not set to be executable. You can check with ls -l configure. You should see a line that starts with something like -rwxr-xr-x. If not, you can run chmod +x configure to add executable permission to it.
If the permissions on that file are not right, it would be good to check the rest of the files in the distribution. How did you get the file? Downloading the tarball from Sourceforge? Download the ZIP from Github? Checking out from Github? And how did you extract it? If you could fill those details in to your question, as well as the full output of ls -l, that might help us figure out what happened.
edit to add: It looks from your configure log like cpp (the C preprocessor) is looking for cc1plus, which is part of g++. You can install that with yum install gcc-c++ (remember to run as root or with sudo).
Also, in regards to your comment, I would recommend copying the .tar.gz file directly to the Linux machine, and extracting it with tar xvzf myfile.tar.gz rather than extracting it on a Windows machine and uploading it. There are enough differences in the filesystem (how permission bits work, case sensitivity), that the process of extracting files on Windows and uploading the extracted files with something like winscp can cause problems like this.

Resources