Unable to open terminal with linux arm and arm64 servers on qemu

[deepak1556]

Sanity testing 1.75 on linux servers following the steps at https://github.com/microsoft/vscode-remote-release/wiki/Sanity-Check-VS-Code-Servers#linux-platforms and attempting to open a terminal throws the following error.

Issue is from the pty module, following snippet can trigger the error on any of the containers

> var ptyProcess = pty.spawn('bash', [], {cwd: process.env.HOME});
Unsupported ioctl: cmd=0x5441
Uncaught Error: chdir() failed: Not a directory
    at new UnixTerminal (/root/.vscode-server/bin/e8bf7514f31cef005c988b206c61948e56aab9cb/node_modules/node-pty/lib/unixTerminal.js:106:24)
    at Object.spawn (/root/.vscode-server/bin/e8bf7514f31cef005c988b206c61948e56aab9cb/node_modules/node-pty/lib/index.js:29:12)

[deepak1556]

The bug seems to be localized to qemu environment, if I open arm64 container from arm64 host the terminal launches fine inside the container.

[bpasero]

Talked in standup to not take as candidate.

[deepak1556]

I will try to sum-up my findings here:

• The issue only affects when running on top of qemu
• The way https://github.com/hypriot/qemu-register works is that it ships docker image with qemu built for certain architectures and during run it installs the qemu binaries as interpreters for the relevant architectures via the binfmt_misc kernel feature https://docs.kernel.org/admin-guide/binfmt-misc.html
• The default behavior of binfmt_misc is to override the argv[0] with the full path to the binary that is being executed. For our case, the spawn-helper gets the following argv[] under qemu

["absolute-path-to-helper-binary", "uid_value", "gid_value"] -> see how `cwd` value at 0 is replaced

• This affects our expected positional argument
• Couple of solutions,
  (i) When launching the helper executable, always set an environment variable QEMU_ARGV0 set to the argv[0] value we expect in the child process. This would force qemu to use this as argv[0] in the child process.
  (ii) Alternatively, we align the argument array to have the first position as path to the program that is being executed since that is what is expected in the unix platforms. So we would basically launch the helper executable with the following arguments

["absolute-path-to-helper-binary", "cwd", "uid_value",....] -> see how we are explicitly passing the first argument as the program name

I am inclined to solution (ii) as it aligns with unix expectations and also avoids using any environment particular to a platform.