Closed rdbahm closed 3 months ago
I did a git bisect on this issue, since it doesn't seem to repro in v0.3.9. The issue seems to start at commit 74e9f61c40b0c784939f9b34a060200341fcfa7f.
just did an install of the old bullseye, and i could reproduce the issue after fighting my screen that didn't want to show up,
apparently this is caused by %I in the service changing %I to tty7 and rebooting fixes the issue did not happen on bookworm but i always install and use zsh so maybe that's the difference
Yep, new commit seems to be working in my test scenario as well. Thanks for the fast fix.
What happened?
During re-configuration of my Klipper-based printer (uses a Raspberry Pi 4, typically based on the latest build of MainsailOS), I had repeated difficulties with permissions on /dev/null after installing KlipperScreen. I eventually narrowed down that issue to something within KIAUH and opened an issue there, but investigation found that even without involving KIAUH, installing and uninstalling KlipperScreen results in an identical issue.![image](https://github.com/KlipperScreen/KlipperScreen/assets/4553626/94ea02ac-ff4d-41bc-a1a7-99bd61bb5921)
What did you expect to happen instead?
I expect the "pi" user to be able to access /dev/null normally. Same system as previous screenshot, just before uninstall:![image](https://github.com/KlipperScreen/KlipperScreen/assets/4553626/10c80230-36b4-4497-929a-4605f531b835)
How to reproduce this bug?
Before beginning, you can verify the issue is not present by running ls /dev/null (not as root or with sudo)
Additional information:
I opened an issue for a similar issue in a different part of the KlipperScreen installation on the KIAUH repository, Issue 448. In that case, installing KlipperScreeen via KIAUH (but not via KlipperScreen-install.sh) causes the exact same symptom. I expect they're related, but I don't yet understand how.
As implied in the repro steps, the issue doesn't happen if the service is not installed before uninstalling.
Log output