Enable vsyscall=emulate in the kernel config to run older base images such as Centos 6

[dklawren]

They were changes made on vsyscall linking in the Linux Kernel, starting with version 4.11, that caused issues with containers running Centos 6.x

Describe better here:
https://unix.stackexchange.com/questions/478387/running-a-centos-docker-image-on-arch-linux-exits-with-code-139

➜ ~ docker run -it centos:6 bash
Unable to find image 'centos:6' locally
6: Pulling from library/centos
ff50d722b382: Pull complete
Digest: sha256:dec8f471302de43f4cfcf82f56d99a5227b5ea1aa6d02fa56344986e1f4610e7
Status: Downloaded newer image for centos:6
➜ ~ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c4861c529a05 centos:6 "bash" 49 seconds ago Exited (139) 49 seconds ago relaxed_brahmagupta

[therealkenc]

/dupe #1462. Better on WSL2 probably.

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists in this repository. This specific instance is being closed in favor of tracking the concern over on the referenced thread.

Thanks for your report!

[dklawren]

Sorry I didn't specify earlier. This is with WSL2 running the latest insider build. I have looked around and I do not see how to pass custom kernel boot options to the kernel that is used by WSL2. Is this possible? Will the default kernel support the boot option of I could?

[therealkenc]

Ah, okay. Thanks for the clarification, and good question (looks):

ken@DESKTOP-BNN97ME:~$ cat /proc/config.gz | gunzip - | grep VSYSCALL
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_X86_VSYSCALL_EMULATION=y
# CONFIG_LEGACY_VSYSCALL_EMULATE is not set
CONFIG_LEGACY_VSYSCALL_NONE=y

I think (?) that last line means vsyscall is off by default. We don't have a way (I know of) to pass the equivalent of GRUB-time boot options. You could in extremis recompile the kernel, but that is.... extreme.

Will de-dupe you since this is WSL 2, and "how do I get legacy vsyscall emulation" is a legit enough question. At worst this can be parlayed into feature request "pass boot options to WSL" or somesuch.

[dklawren]

Thanks for reopening.

[squeaky-pl]

There is a workaround, not sure if suitable for your use case.

I also hit that problem some time ago. You can actually partially recompile Centos 6 not to depend on this behavior and it was done in some projects:

pypa/manylinux#158

A quick workaround is that you can change FROM centos:6 to FROM quay.io/pypa/manylinux2010_x86_64 (which is centos:6 with the patch and extra manylinux tooling), of course you are gonna pull that entire project. You could slim down this image by building another image removing all the manylinux project parts.

You could also take the patch from the issue I linked.

[squeaky-pl]

OS Name: Microsoft Windows 10 Pro
OS Version: 10.0.19025 N/A Build 19025

>> uname -a
Linux DESKTOP-3AA6EJV 4.19.79-microsoft-standard #1 SMP Mon Oct 14 00:50:46 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

>> docker run quay.io/pypa/manylinux2010_x86_64 bash -c "cat /etc/*release"
CentOS release 6.10 (Final)

[squeaky-pl]

The actual patch to glibc in Centos 6 is in this PR: https://github.com/pypa/manylinux/pull/279/files

[benhillis]

@therealkenc, @squeaky-pl Could you try this?

%userprofile%\.wslconfig

[wsl2]
kernelCommandLine = vsyscall=emulate

[squeaky-pl]

@benhillis it works:

OS Name:                   Microsoft Windows 10 Pro
OS Version:                10.0.19028 N/A Build 19028

>> cat /proc/cmdline
initrd=\initrd.img panic=-1 pty.legacy_count=0 nr_cpus=8 vsyscall=emulate
>> docker run -ti centos:6 bash -c "cat /etc/*release"
CentOS release 6.10 (Final)

[therealkenc]

Right 18995 release notes:

[wsl2]
kernelCommandLine = <string> # Additional kernel command line arguments

I probably stared right at that but dedicated no neurons to storing the knowledge thereof. Thanks Ben!

I guess for purposes "legacy vsyscall emulation" aka #1462 call this feature-fixedininsider for lack.

[dklawren]

Thanks. The .wslconfig change also allows my containers to work again. Feel free to close this since Centos:6 is probably not new enough to worry too much about.

[benhillis]

Glad to hear this is working for you. As we get closer to release we will be updating the WSL2 usage docs to have the various .wslconfig options.

[cboudereau]

I had the same issue even if I configure wsl2

%userprofile%\.wslconfig

[wsl2]
kernelCommandLine = vsyscall=emulate

C:\Users\Clément>ver

Microsoft Windows [Version 10.0.19030.1]

C:\Users\Clément>docker run -ti centos:6 bash -c "cat /etc/*release"

C:\Users\Clément>docker ps -a
CONTAINER ID        IMAGE                COMMAND                  CREATED             STATUS                       PORTS                                                        NAMES
c3092cb0f2f8        centos:6             "bash -c 'cat /etc/*…"   5 seconds ago       Exited (139) 4 seconds ago      

I tried to use the quay.io/pypa/manylinux2010_x86_64 image, it works but associated to dotnetcore self contained and rid rhel.6-x64 I had the same issue (no logs and a container in Exited 139 state). The same binary works with Docker Desktop with the VM.

[squeaky-pl]

@cboudereau be sure to execute wsl --shutdown before so the kernel actually is rebooted

this option should also show in

> cat /proc/cmdline
initrd=\initrd.img panic=-1 pty.legacy_count=0 nr_cpus=8 vsyscall=emulate

If it does not it was not picked from .wslconfig for some reason.

[squeaky-pl]

@cboudereau Also you are actually calling docker from cmd.exe and not from WSL2, at least according to your pastes.

[cboudereau]

@squeaky-pl thank you for your answer. I tried in powershell and cmd. I checked it by using the shutdown command and restarting windows but I have the same problem.

How can I call docker from wsl2 (it launches default distro). I configured docker to use wsl2 and it works fine with other images (ie: centos7)

[squeaky-pl]

@cboudereau

I personally don't use Windows Docker installer, I dont know if Windows Docker on WSL2 respects .wslconfig either (but my common sense tells me that it should), I run Docker inside WSL2 distro fully.

Nevertheless what I would start debugging your case by booting a WSL2 Distro like Ubuntu and check that your .wslconfig options are picked up.

You should see:

cat /proc/cmdline
initrd=\initrd.img panic=-1 pty.legacy_count=0 nr_cpus=8 vsyscall=emulate

You should see vsyscall=emulate

What you could also try is querying /proc/cmdline from within Windows Docker

docker run -ti ubuntu cat /proc/cmdline
initrd=\initrd.img panic=-1 pty.legacy_count=0 nr_cpus=8 vsyscall=emulate

I can see vsyscall=emulate myself even within Docker. If it's not there the issue is that options are not picked up.

[cboudereau]

@squeaky-pl thank you very much! I found now why the .wslconfig was not loading thanks to the cat /proc/cmdline command line. In fact I was facing about an Encoding and whitespace isssue. Be sure that the .wslconfig is a UTF8 without BOM and copy/paste exactly what @benhillis supplied. Yesterday I was too tired to see this problem, so sorry the quality of my comment and many thanks @squeaky-pl and @benhillis.

[xspeed1989]

@therealkenc, @squeaky-pl Could you try this?

%userprofile%.wslconfig

[wsl2]
kernelCommandLine = vsyscall=emulate

not working on win10 2004

[gurvinderd]

I have WSL2 and docker wsl integration turned off. Running Ubuntu 20.04 and installed docker inside it.
Ran into the same issue while running step "RUN mkdir -p /server/logs" in dockerfile.
Applied the solution suggested by #4694 (comment) and it worked.
Thanks, it was helpful.

[izbyshev]

It would be even more helpful if MS didn't gratuitously break Linux ABI by using non-default kernel config (especially when another option exists), requiring users to add workarounds into their .wslconfig.

[hyj1991]

@therealkenc, @squeaky-pl Could you try this?

%userprofile%.wslconfig

[wsl2]
kernelCommandLine = vsyscall=emulate

This works for me :)

[fsarter]

@therealkenc, @squeaky-pl Could you try this?

%userprofile%.wslconfig

[wsl2]
kernelCommandLine = vsyscall=emulate

To make the answer more friendly:

1. You can open %userprofile% directory like this,
   
2. If you can not find .wslconfig in the directory, then you should create it.
3. In my case i reboot my system to make this work, you can try.

[mikepmosh]

Thank you a lot for the workaround.

I had the same issue with a old linux docker image using Docker Desktop (for Windows).

Using cmd, these are the step that worked for me :

1. Create file : %userprofile%.wslconfig
2. Add this two lines :
   [wsl2]
   kernelCommandLine = vsyscall=emulate
3. Restart wsl
   wsl --shutdown
4. Restart Docker Desktop

[falves1]

I add vsyscall=emulate to all my servers command lines by default. I need to know if this makes them slower than they should be. I don't have any centos 6, just from centos 7 and up, containers. Plain LXC containers.

[kiview]

AFAIK they will be slower, yes. If this is an issue for your workload on Docker Desktop depends on your use case.

[arsu-leo]

I'm just unable to install any package through apt-get.
apt-get update or any other install takes 5 minutes per package on best case.
I'm forced to do some tests on Debian 7, expected I could just use docker desktop on windows instread of a full VM.
I'm using the image "debian/eol:wheezy" but the issue persists with any debian 7 image I tested.

[AlexMSlalom]

@therealkenc, @squeaky-pl Could you try this?

%userprofile%.wslconfig

[wsl2] kernelCommandLine = vsyscall=emulate

How should I go about replicating this fix on a M1 Pro Mac? I'm running into the exit status 139 after container creation, but am struggling to find a fix.