Containers targeting old glibc versions might segfault (error 1, vsyscall attempted with vsyscall=none)

[moio]

Actual Behavior

Containers with executables using old glibc versions will unexpectedly terminate without any output nor trace in logs.

Steps to Reproduce

docker run -ti --entrypoint /bin/bash gcr.io/google_samples/gb-redisslave:v1

or

nerdctl run -ti --entrypoint /bin/bash gcr.io/google_samples/gb-redisslave:v1

Result

No output, no trace in logs (container logs, troubleshooting logs exposed by Rancher Desktop).

SSH'ing into the lima VM and running dmesg reveals the core problem:

[ 3117.038764] bash[4471] vsyscall attempted with vsyscall=none ip:ffffffffff600400 cs:33 sp:7ffe39f2c278 ax:ffffffffff600400 si:7ffe39f2ced8 di:0

vsyscall is a mechanism used by old glibc versions disabled by default in recent kernels due to security concerns. If containers have executables which use it but the kernel does not have the vsyscall=emulate command line parameter, the container will segfault.

https://gitlab.alpinelinux.org/alpine/aports/-/issues/6927#note_31075

Expected Behavior

A bash shell opens.

Additional Information

No response

Rancher Desktop Version

1.3.0

Rancher Desktop K8s Version

No k8s

Which container runtime are you using?

containerd (nerdctl)

What operating system are you using?

macOS

Operating System / Build Version

Monterey 12.3.1 (21E258)

What CPU architecture are you using?

x64

Linux only: what package format did you use to install Rancher Desktop?

No response

Windows User Only

No response

[jandubois]

On Windows this can be configured via %USERPROFILE%\.wslconfig: microsoft/WSL#4694 (comment)

For macOS and Linux I've filed an issue against Lima to make this more easily configurable: lima-vm/lima#857

[moio]

Thanks @jandubois!

Tangent question: would it be a good idea to surface dmesg output in logs somehow, to help in similar cases? Or even offer an easy way to SSH into the lima VM (I understand this would open up doors to a lot of unexpected behavior, but still I found myself wanting to do that in a number of occasions as a newbie).

What does the team think about that?

[jandubois]

Tangent question: would it be a good idea to surface dmesg output in logs somehow,

On macOS and Linux you have the boot part of dmesg in the serial.log file:

$ head ~/Library/Application\ Support/rancher-desktop/lima/0/serial.log

ISOLINUX 6.04 6.04-pre1  Copyright (C) 1994-2015 H. Peter Anvin et al
boot:
Loading /boot/vmlinuz-virt... ok
Loading /boot/initramfs-virt...ok
[    0.000000] Linux version 5.15.37-0-virt (buildozer@build-3-15-x86_64) (gcc (Alpine 10.3.1_git20211027) 10.3.1 20211027, GNU ld (GNU Binutils) 2.37) #1-Alpine SMP Tue, 03 May 2022 11:42:03 +0000
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-virt modules=loop,squashfs,sd-mod,usb-storage console=tty0 console=ttyS0,115200 initrd=/boot/initramfs-virt
[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'

Or even offer an easy way to SSH into the lima VM

We do indeed offer this, but the usual caveat about "If you break anything, you gotta keep all the pieces" still applies:

$ rdctl shell sudo dmesg | head
[ 3036.263290] audit: type=1327 audit(1652682502.369:227): proctitle=69707461626C65732D726573746F7265002D2D77616974002D540066696C746572
[ 3041.017007] docker0: port 1(vethdf2598f) entered blocking state
[ 3041.017010] docker0: port 1(vethdf2598f) entered disabled state
[ 3041.017034] device vethdf2598f entered promiscuous mode
[ 3041.017072] audit: type=1700 audit(1652682507.119:228): dev=vethdf2598f prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295
[ 3041.017074] audit: type=1300 audit(1652682507.119:228): arch=c000003e syscall=44 success=yes exit=40 a0=e a1=c001531140 a2=28 a3=0 items=0 ppid=2868 pid=2869 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dockerd" exe="/usr/bin/dockerd" key=(null)
[ 3041.017076] audit: type=1327 audit(1652682507.119:228): proctitle="/usr/bin/dockerd"
[ 3041.214888] eth0: renamed from veth07d4bd3
[ 3041.265335] IPv6: ADDRCONF(NETDEV_CHANGE): vethdf2598f: link becomes ready
[ 3041.265356] docker0: port 1(vethdf2598f) entered blocking state

$ rdctl shell
lima-rancher-desktop:/Users/jan$

[moio]

Thank you very much!

FTR: as a workaround in case anybody needs it, the following works:

• edit the following line: https://github.com/lima-vm/alpine-lima/blob/main/mkimg.lima.sh#L13
• rebuild alpine-lima
• injecting the iso into a development version of rancher-desktop