I created a sys-gui with salt scripts, added the AwesomeWM package and qubes.lua to the template, used this to use awesome in sys-gui, booted, and everything ran about the same as without modification.
Then I ran qvm-run – xterm, and it failed. XFCE’s problem reporter described it as qubes-core-admin-client crashing, and stderr gave me a message about the qvm-copy python program failing at lines 5, 331, and 214. I then replicated the problem in XFCE after coming across it in Awesome. The problems are identical.
I checked the program on GitHub, but the lines and errors didn’t match.
Any ideas?
You are looking at the Unit Test file. Here is the main file.
1 Like
Thanks, no wonder that program looked weird. I’m not too familiar with that language, so I just chalked it up to that. I’ll do some digging at the correct one and see what I can piece together.
1 Like
I don’t see much details here, but I would guess it’s a qrexec policy issue - AFAIR by default it doesn’t allow qubes.VMShell or qubes.VMExec service from sys-gui - you should get some notification about this. But it should allow qubes.StartApp, so you can try starting something from the menu, or if you prefer manually, then qvm-run --service untrusted qubes.StartApp+xterm (note xterm here is the desktop file name from /usr/share/applications, not a command to execute).
1 Like
This makes sense. I noticed a discrepancy earlier as I was working on it that I get policy notifications in dom0 that I don’t get in sys-gui. I’d assumed that global rwx included these, or maybe I just forgot if I had read it. Either way, I’ll try the qubes.StartApp and for qvm-run I’ll temporarily enable policies and see what that does. Thanks!
This works perfectly. Marking as solution. Thank you very much; you’re a lifesaver!
I’ll look into notification logs and also into why I’m not getting them in sys-gui.
Notifications are shown in guivm of the source. Since sys-gui’s guivm is dom0, they are shown there. This sounds like something that could use an improvement.
2 Likes
I agree. On a design and administrative level, I really love where policy is going. Perhaps a notification policy could fix this? I haven’t yet looked into the logging qube, but I suggest policy because notifications could be defaulted to the GUIVM, but the sys-gui salt could edit policy to make GUIVM(s) go both to dom0 and to themselves. It could then be used to also route notifications to the appropriate log qubes.
This may be a terrible idea; if the log qube already can get notifications then it’s certainly a terrible idea. I just put it here when it came to me. But it sounds good at the moment, so I figured I’d share before I forgot.
