Shell fails to open in a pod

[IsaSih]

Internal reference: SURE-8318

Setup

• Rancher version: v2.9-c9be13b09329bbee60a5f6419d500198f83c44d1-head
• Browser type & version: Google Chrome 123.0.6312.107 (Official Build) (arm64) and Safari 16.6

Describe the bug

Shell fails to open in a pod due to an unknown path/bin/sh: no such file or directory: unknown. According to the console logs, the error occurs in file ContainerShell.vue:319.

To Reproduce

1. Create a downstream cluster (in this example, it's a GKE cluster)
2. When the cluster is available, via UI, go to Workloads > Pods and click on the 3 dot button of any pod, then click on Execute Shell
3. Observe the error message when the shell is open

Result Shell fails to open in a pod due to an unknown path/bin/sh: no such file or directory: unknown

Expected Result Shell should be open in a pod with no errors

Screenshots

[richard-cox]

I wonder if this is related to changing the underlying image to BCI?

We should confirm if this is a bug in 2.7 and 2.8 as well

[gaktive]

Will file something for Mapps to figure out what we can do around new BCI behaviours. Ideally, the UI could detect that there is no shell and elegantly state there's nothing to shell into.

[gaktive]

@IsaSih when you get a moment, can you check the behaviour in 2.8.x? I don't know if we have to go back into 2.7.x at all but that may help if the problem existed somewhat earlier than 2.9.0

[IsaSih]

This issue does not occur in version 2.8-head. Tested on v2.8-94108186cf35028bb5f7db2c34c5ae99450dad9b-head

[gaktive]

Internal reference with Mapps: SURE-8318 May have to monitor here as that team works on that in case it comes back to UI or QA

[nwmac]

We should re-validate that this is still an issue - I believe this is down to a change in base image which does not contain sh - I think this may have been fixed - we should validate.

Should also add an automated test for this.

[richard-cox]

Worked through this with Neil.

The description shows pods with images not from Rancher, it looks like those just don't contain a shell so will never work.

I've brought up a new v2.9-head with the BCI change and can confirm some work

• alertmanager-rancher-monitoring-alertmanager-0, cattle-monitoring-system, docker.io/rancher/mirrored-prometheus-alertmanager:v0.26.0
• gitjob-7f85cd5774-4r429, cattle-fleet-system, rancher/fleet:v0.10.0-rc.13

and some don't

• capi-controller-manager-64b8d54977-c54w6, cattle-provisioning-capi-system, rancher/mirrored-cluster-api-controller:v1.4.4
• coredns-6799fbcd5-dzggt, kube-system, rancher/mirrored-coredns-coredns:1.10.1

I don't think this is a regression, but we need to make the error clearer. Two are the root failures and one is from the UI. We can do this by adding a return after each error and maybe some before our error.

[gaktive]

Holding on backport for now until someone picks this up to see what a solution looks like.