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.

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)