@tzwcfq Thank you.
Here’s what happens. After an hour, the system says
Cannot connect to qrexec agent for 3600 seconds, see /var/log/xen/console/guest-debian-11.log for details.
Then the window running qvm-console-dispvm spits out:
dispvm:default-mgmt-dvm: Cannot connect to qrxexc agent for 3600 seconds, see /var/log/xen/console/guest-disp6628.log for details
Traceback (most recent call last):
File "usr/bin/qvm-run", line 5, in <module_>
File "/usr/lib/python3.8/site-packages/qubesadmin/tools/qvm_run.py", line 335, in main
File "/usr/lib/python3.8/site-packages/qubesadmin/vm/__init__.py", line 410, in cleanup
File "/usr/lib/python3.8/site-packages/qubesadmin/vm/__init__.py", line 126, in kill
File "/usr/lib/python3.8/site-packages/qubesadmin/app.py", line 74, in qubesd_call
return self.app.qubesd_call(dest, method, arg, payload)
File "/usr/lib/python3.8/site-packages/qubesadmin/app.py", line 748, in qubesd_call
File "/usr/lib/python3.8/site-packages/qubesadmin/base.py", line 109, in_parse_qubesd_response
raise exec_class(format_string, *args)
qubesadmin.exc.QubesVMNotFoundError: No such domain: 'disp6628'
Ok. This looks like the qvm-console-dispvm command calls an intermediary disposable qube to do whatever it’s doing. . . and unless I’m mistaken, that qube is based on debian-11 and so is affected by the crash and so whatever is going on remains opaque.
So let’s check the log files and see if there’s anything different. And there is! There’s actually stuff in guest-disp6628.log. Here’s what seems relevant:
[2022-06-14 21:26:24] [.[0;1;31mFAILED.[0m] Failed to start .[0;1;39mLSB: Xen daemons.[0m.
[2022-06-14 21:26:24] See 'systemctl status xen.service' for details.
[2022-06-14 21:26:24] [.[0;1;31mFAILED.[0m] Failed to start .[0;1;39mQubes base firewall settings.[0m.
[2022-06-14 21:26:24] See 'systemctl status qubes-iptables.service' for details.
[2022-06-14 21:26:24] Starting .[0;1;39mQubes misc post-boot actions.[0m...
[2022-06-14 21:26:25] [.[0;1;31mFAILED.[0m] Failed to start .[0;1;39mXen driver domain device daemon.[0m.
[2022-06-14 21:26:25] See 'systemctl status xendriverdomain.service' for details.
What’s interesting, is that the boot continues in the log. There’s even a line that makes me hopeful the new driver sees my wifi card. The end of the log is a “localhost: login:”
So that tells me the Qube IS booting, but that the Xen services are crashing / failing to start, so of course dom0 can’t talk to it!
This also seems weird that installing a Wifi kernel module would cause the Xen services to fail. . . but the kernel is witchy black magick as far as I’m concerned.
Is that iptables failure a clue though? Networking is borked so Xen can’t listen on local tcp/ip ports maybe?
NOW. . . HOW in the name of the swirling chaos at the Center of All Creation, do I pull syslog from a Qube that’s not running? Or from a Qube that IS running but that Xen can’t talk to?