canonical / canonical/workshop

Workshop breaks when a symlink can't be resolved

Open
#924 8 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
108
Forks
17
Avg merge
1d 7h
Merged PRs (30d)
40

Description

### Issue
Workshop fails to get GPU information when a device symlink can't be resolved (i.e. a device was physically disconnected)

### Relevant context
I went to `workshop launch` and received the following output:
```
error: cannot perform the following tasks:
- Setup "system" SDK profile (Failed retrieving GPU information: Failed adding device information for "/sys/class/drm/card0/device": Failed reading "/sys/class/drm/card0/device/de
vice": open /sys/class/drm/card0/device/device: no such file or directory)
"dev" launch aborted
```
`workshop remove` on a completely different workshop resulted in:
```
error: cannot perform the following tasks:
- Disconnect "dev/copilot:copilot-config" from "dev/system:mount" (Failed retrieving GPU information: Failed adding device information for "/sys/class/drm/card0/device": Failed reading "/sys/class/drm/card0/device/device": open /sys/class/drm/card0/device/device: no such file or directory)
```

The issue here is that path `/sys/class/drm/card0/device/device` exists, but is a broken symlink to a DisplayLink device:
```
lrwxrwxrwx 1 root root 0 Jul 7 10:00 /sys/class/drm/card0/device/device -> ../../pci0000:00/0000:00:0d.0/usb2/2-2/2-2.1
```
When I reconnected the DisplayLink device, the symlink was resolved and all of my workshop commands worked again. I cannot `launch` or `remove` any workshop when I am away from my desk unless I uninstall the `evdi` module, which seems undesireable.

### What it should do
Seeing as the DisplayLink has nothing to do with workshop, this definitely doesn't seem like ideal behavior. I suspect that the GPU search functionality should pass on broken symlinks rather than aborting.

Contributor guide

Open the contributing guide

Research direction

Start by tracing the GPU information retrieval path from the error messages and reproduce the failure with a broken device symlink under /sys/class/drm. Done means workshop launch and remove continue when an unrelated GPU symlink cannot be resolved, while valid GPU information is still handled normally.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
devtools, operating-systems
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
58/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.