When I run sudo apt install linux-modules-extra-$(uname -r) in a Docker container based on a Ubuntu 20.04 on a single board computer running Ubuntu 18.04, I get the following errors:
E: Unable to locate package linux-modules-extra-4.15.0-143-generic
E: Couldn't find any package by glob 'linux-modules-extra-4.15.0-143-generic'
E: Couldn't find any package by regex 'linux-modules-extra-4.15.0-143-generic'
To me, this makes me wonder whether it is even possible to install linux-modules-extra-4.15.0-143-generic in Ubuntu 20.04? Maybe it is only compatible with Ubuntu 18.04?
Could anyone clarify this for me please?
In general, if you're building a kernel module, it has to match exactly the kernel that's running on the host system. If you're using a native Debian or Ubuntu system (without Docker), there's a system where kernel modules can be rebuilt or reinstalled when the host kernel is updated. See for example the Debian wiki KernelDKMS page.
In contrast, a Docker image is generally supposed to be portable across hosts. If you upgrade the host's kernel, or if you run a FROM ubuntu:18.04 image on an Ubuntu 20.04 host, the image isn't really supposed to be aware of this.
In your particular case, you can't get the kernel headers you need, because they're not part of the Ubuntu 18.04 distribution. For this particular case it might be possible to get the headers from the later version of Ubuntu, but it might not be possible in the general case; maybe because the system is actually running plain Debian or RHEL and the kernel build is different, maybe because the operator built their own kernel.
Since a Linux kernel module is so specific to the host it runs on, and since it can bypass any and all security concerns, it's not appropriate to try to install one in a container. Do it directly on the host instead.
Related
I want to use USBIP in an Ubuntu 20.04 Docker Container. I tried installing the "linux-tools-generic" Package, but when i run USBIP afterwards i get the message:
You may need to install the following packages for this specific kernel:
linux-tools-5.10.16.3-microsoft-standard-WSL2
linux-cloud-tools-5.10.16.3-microsoft-standard-WSL2
You may also want to install one of the following packages to keep up to date:
linux-tools-standard-WSL2
linux-cloud-tools-standard-WSL2
How can i install these Packages ? Could'nt find them with apt-get.
Since Docker relies on the features of the Linux kernel, you'll need to make sure that you have the USB/IP module compiled into your WSL kernel. It is not there in the stock WSL kernel, so you'll need to build your own. I haven't done this with USB/IP myself, but there are reports from the Home Assistant (home automation) forums that indicate that it works.
See this answer for more details.
I have a bootable iso image (live cd) with Linux system that is pretty old. That distro doesn't have remote repo (all installations are done from cdrom and separate disk with packages). I wanted to turn it into a docker image. Reading through articles google gave me, I've found several ways to do that. The first one is to mount the iso and find filesystem.squashfs - only modern distros use that way, not my case. My distro doesn't have that file available. The second approach is to call debootstrap but it requires to specify the repo for the distro with dist directory available in it. My distro doesn't have a public repo. What can I do? Is it even possible? I think that should be possible by doing a lot of things manually but how?
I faced similar problems when I had to containerize an old build server (building natively for legacy systems), eventually I succeeded. This approach describes how to containerize some old Linux distro (kernel 2.6.27 in my case), in the present Linux kernel 5 era.
General steps
if necessary: boot the old OS (or Live CD image)
login to the old system as root (or use sudo)
create a tarball from the relevant folders present in root
cd / ; tar cfvz image.tar.gz --one-file-system --exclude=/var/log --exclude=/image.tar.gz /
the selection worked in my case; review for yourself which folders to include or exclude
transfer the tarball to the Docker host (step not shown here)
and import it:
docker import image.tar.gz
the previous command will print out some hash
if convenient, tag the imported image:
docker tag <import-hash> <your-label>
Legacy problem: unsupported system calls
The imported image contains a Linux distribution snapshot. Some binaries can be executed from Docker, eg.:
docker run --rm <your-label> bin/ls
may actually work.
Some important binaries initially did not work for me, most notably bash:
docker run -it --rm <your-label> bin/bash
was failing silently. (Also, running with strace was possible but gave no clear indication.)
As #hiranchaudhuri pointed out, this is likely due to an API discrepancy between the host's kernel and the container's user space code.
In my case the problem was solved by enabling the legacy vsyscall kernel API
for Windows WSL2, this is described here https://learn.microsoft.com/en-us/windows/wsl/wsl-config
for native Linux systems of today, I guess this can be set in the boot configuration, with the kernel command-line parameter vsyscall=emulate, if the present kernel supports this option
I seriously doubt you will succeed on that.
Be aware Docker is not a full virtualization like KVM or VirtualBox. The lightweight virtualization benefits from the docker containers running on the host's Linux kernel. Which means the kernel is the same inside and outside of the container.
If you now try to install some old distro inside the container you may end up with an incompatible combination. Patching the kernel may involve upgrading glibc, and patching that may involve recompiling the rest of the OS.
I am not sure why you want to stick to the old distro, but seriously I believe you are better off with real virtualization.
This was a huge surprise for me:
Today, using Docker For Mac (18.03.1-ce-mac65), I ran a Debian Stretch image. Inside the image I mounted the latest Raspbian Stretch image (2018-04-18-raspbian-stretch-lite) using mount. I then used chroot to this mounted Raspbian filesystem.
This is where it got weird. I was able to use apt (without any special modifications) to install software into this mounted filesystem.
Running:
dpkg --print-architecture
returned: armfh
and the software I installed (vim) worked like a charm
I was even able to compile a simple program using gcc and run it.
But, I need to know! How is this possible?
According to Docker:
Docker for Mac provides binfmt_misc multi architecture support, so you can run containers for different Linux architectures, such as arm, mips, ppc64le, and even s390x.
EDIT
On Linux, you can install qemu-user-static and then follow this git repo to get cross-architecture support!
I am new learner for Docker.I have a very simple question.
I want my application to work on Linux system but I am writing application in Windows.So do I need to install Docker for Windows or Linux?
If I run using Docker for Linux,i am not getting option to run in windows and it is getting failed(I understand it might be some other unrelated error) but I need to confirm if my approach is correct or not.
Am I right in installing Docker for Linux?
Also,in case I plan to move to AWS, what docker I need in that case.
Thanks
Consider docker as any software. if your OS is windows you install windows version of a software. if your is a linux distro then you install linux version of a software.
So you need to install docker for windows afterwards you can install any docker image/container you want under your operating system. Could be windows, linux or anything else.
I have been working with LXC containers, the basic tutorials and some networking and it seems to me that its a very straightforward and simple way to create a pure distribution on top of my host.
Current list of templates available does not however list the RHEL x.x distribution. There is CentOS.
I see that Red Hat has supported some efforts in LXC with the libvirt driver, however that shows as deprecated on the site and everything is pointing to their Atomic host which I am experimenting anyways, however, that seems more of a docker way. There might be some variations of docker which ultimately may give me a bare minimum container running a full distro.
I am OK getting more into docker but what I expect at this moment is to run as a simple LXC container with RHEL 6.x distro. Is there no way to run a RHEL LXC container ?
it is indeed unfortunate that redhat plans to discontinue libvirt support for lxc. even within rhel7, so that means rhel6 may be the last version where it will be supported for the lifetime of that release.
as an alternative, there are packages for lxc in epel: https://dl.fedoraproject.org/pub/epel/6/x86_64/repoview/lxc.html
they are even easier to use than libvirt-lxc
as for the template, in either case you should be able to use the centos template with little modification. all the packages are the same and really only the repo sources should point to redhat instead of centos.