Docker image with R converted into singularity image outputs FATAL: kernel too old

[juanesarango]

I create a very basic container of docker installing the core-library or R. That runs without problem as docker container. But when I convert it to a singularity image, I get kernel too old error, and container doesn't work.

Version of Singularity:

2.2.99

Expected behavior

Run R inside the singularity container, that was converted from a docker image.

Actual behavior

Error kernel too old when trying to run singularity container.

Steps to reproduce behavior

Dockerfile

FROM ubuntu:17.10
RUN apt-get update && apt-get install -y r-base-core
CMD ["bash"]

docker build -t example-image .
docker run -it example bash
It runs without problem. And I can run R from the bash inside the container.

Then, I convert it to a singularity image using the docker2singularity tool

docker run \
        -v /var/run/docker.sock:/var/run/docker.sock \
        -v `pwd`:/output \
        --privileged -t --rm \
        singularityware/docker2singularity 
        example-image

Which outputs the singularity image: example-image-#####.img
But when I try to run it with singularity:
singularity shell example-image-####.img

I get FATAL: kernel too old

[juanesarango]

If I also push the image to a docker containers repo and just run it to make the conversion to singularity image on the fly:
singularity shell docker://my-username/example-image
I also get the same FATAL: kernel too old error.

[GodloveD]

What is the Host OS? I think that glibc inside the container is complaining that the host kernel is too old to work properly. You may need to change your image to use Ubuntu 16 or RHEL.

[juanesarango]

@GodloveD the host is CentOS 6.9

With Ubuntu<=16 this basic example works, but some more robust Dockerfiles I have seems to show the same issue. So what I understand is that the problem may be with my host OS kernel and not an issue from singularity itself.

Thanks

[GodloveD]

If you really need a newer containerized OS to work on an older host, I think you can compile glibc from source with the --enable-kernel=[version] flag. But that sounds like a big hassle to me.

But anyway, yes this is technically not a Singularity issue afaik. I'll close for now and you can re-open if necessary. Thanks!

[concatenize]

"Mobility of compute is defined as the ability to define, create and maintain a workflow and be confident that the workflow can be executed on different hosts, operating systems (as long as it is Linux) and service providers." So why is this not a Singularity issue? I thought it would be the primary concern of Singularity.

[jmstover]

@concatenize ... This is a distribution issue. @GodloveD 's comment is the controlling factor here. When the distribution compiles glibc, they set a minimum kernel version with the --enable-kernel flag. Ubuntu 18 was setting this around 3.2 IIRC, which mean the kernel must be 3.2 or greater, otherwise it won't run, so an Ubuntu 18 container wouldn't run on a RHEL 6.x host (2.6.x kernel).

It is a concern, but it's also something outside of Singularity's control. This is a container creater issue. If they choose an OS where glibc was built saying "Hey, you need to have a 4.1 kernel to run" ... then it isn't going to run on a Host where the Kernel is less than 4.1.