After upgrading to 4.3 & fedora-43 *one* of AppVMs boots but refuses to start apps

User Support General
1

I’ve updated in-place from 4.2. to 4.3 (with a re-try to fix the whonix-17 expired keys). After update I’ve installed fedora 43 template, and applied via salt same customizations I’ve had on fedora 42, then switched my AppVMs over. And here’s the interesting issue: one of the AppVMs, configured in very similar way to another one (same services; the one with issues has more memory assigned), boots up, but refuses to run anything. I can open console from Qubes Manager, but not a terminal, nor anything else. qubes-gui-agent.service is running, and the last line it displays is Waiting on /var/run/xf86-qubes-socket socket.... Switching that qube to use fedora-42 template lets it operate normally, whereas the other qube happily works on fedora-43.

FWIW, both fail to start the service qubes-ctapproxy@sys-usb.service, but that doesn’t seem to be relevant.

2

Commenting things out in ~/.bashrc made it possible to run things in AppVM. Which is interesting that bash configuration was able to break starting apps from the dom0 menu.

Edit: most likely keychain that was waiting for input.

1 Like
3

Can you tell us what line(s) in .bashrc can prevent application from launching? Was it waiting for some user input?

Maybe it can help someone in the future.

1 Like
4

I would have to check which one specifically caused this, but I commented out keychain that was waiting for input, powerline, and loading hooks for direnv and gopass. Yes, it’s quite likely it was keychain.

1 Like
5

OK, that is interesting.

qvm-run has an option to run a command without a shell - I think that would have worked for you.

If the applications in the Q menu were blocked, then it suggests that a shell is started there. Maybe there is a reason, but it seems like an unnecessary use of resource…

Thank you for your answer.

6

Yeah, uncommenting the keychain line brought back the issue. I didn’t yet try the other ones.

7

In that state, neither qvm-run -a --service -- personal qubes.StartApp+terminator nor qvm-run -a --no-shell -- personal qubes.StartApp+terminator nor qvm-run -a --no-shell -- personal terminator works, so doesn’t seem running command without shell is sufficient.

1 Like
8

And the “open console in qube” and trying to run command there complains, even before the keychain prompts, Cannot open display ":0", and trying to run xterm or whatever complains about the same.

1 Like
9

qvm-run definitely does “the right thing”.

qvm-run --pass-io afedoraqube 'echo "$-" '

returns “hBS”. There is no ‘i’, so it is non-interactive, and .bashrc should not be run. (Curiously, I see no explicit test in .bashrc, but bash must take care of it.)

Maybe terminator is blocking on an interactive shell startup that it does itself.

Do any other apps work, like Geany, or file manager?

10

Neither Vorta autostarted nor nextcloud desktop started from menu. Both installed from flatpak. I don’t remember if I tried file manager.

11

Non-flatpak programs don’t start either. Trying to start something from console displays the aforementioned cannot open display: :0

And yes, sudo systemctl status qubes-gui-agent.service claims everything is OK.

12

I played around and it’s keychain that’s the culprit.

1 Like