Traceback on os-prober call with debug logging
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 16
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Description
The detection of Windows Boot Manager with os-prober requires admin rights (sudo), thus running
mdd --dry-run
without sudo does not work. On the other hand, running
sudo mdd --dry-run
works well for the detection of Windows Boot Manager, but it struggles detecting the Display Manager with following error message and output
xset: unable to open display ""
…
"desktop": {
"cli": "/usr/bin/bash",
"gui": "i3",
"dm": "",
"wm": null,
"display": "unspecified",
"display_with": "Xwayland"
}
instead of "display": "x11".
What kind of works, is running any command with sudo before. Then, mdd calls sudo -n os-prober within the timeout of sudo (15 min). But this should not be intended to be used like this.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the issue with mdd --dry-run and sudo mdd --dry-run, focusing on the sudo -n os-prober call and the xset: unable to open display output. Trace how Windows Boot Manager and display information are detected; done means avoiding the traceback and reporting the display as x11 when appropriate.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux, python
- Domain
- desktop-dev, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100