After updating dom0, my kernel went from 7.0.14-1 to 7.1.6-1, and now no qube will start. This might be unrelated to the kernel update, but the timing lines up closely enough that I suspect it is.
Symptom 1: Clicking “Start qube” in Qube Application Menu does nothing no error message, no popup, nothing. It’s as if the button has no functionality at all.
Symptom 2: Running qvm-start <qube> from a terminal does return an error:
internal error: libxenlight failed to create new domain '<qube>'
The detailed log (/var/log/libvirt/libxl/libxl-driver.log) shows:
libxl: libxl_dm.c:2857:stubdom_xswait_cb: Domain X:Stubdom Y for X startup: startup timed out
libxl: libxl_create.c:2018:domcreate_devmodel_started: Domain X:device model did not start: -9
What I’ve tried so far, none of which fixed it:
-
Rebooted into the previous kernel (7.0.14-1) via GRUB’s Advanced Options. The qube did start this time through Qube Manager, but none of its applications launch, and the standard app launcher doesn’t work either.
-
Added spec-ctrl=ibpb-entry=no-pv to GRUB_CMDLINE_XEN_DEFAULT no change.
System info:
-
Xen version: 4.19.5
-
dom0 kernel: 7.1.6-1 (also tested on 7.0.14-1 with partial results, see above)
-
Hardware: ASUS ROG Zephyrus G16, Intel Core Ultra 9, RTX 5070
Has anyone else hit this exact combination stubdom timeout on domain creation, plus apps failing to launch even when the qube itself does start on the older kernel? Trying to figure out if this is a kernel regression, a Xen/stubdomain package issue, or something else in dom0 that got touched in the same update. Willing to post more logs if useful.
This part may have more details in /var/log/xen/console/guest-<qube>-dm.log, especially near the end when QEMU is started. But, it shouldn’t really depend on kernel version, I suspect the issue is elsewhere… Is net qube of that <qube> running? Maybe it’s in some weird state (frozen or such)? Can you open terminal there (it might be sys-firewall, or sys-whonix, or something else depending on your settings) and check for errors in journalctl?
No like nothing works when i start sys-net or any Qube with the Qube manager and try to open the terminal or file manager or whatever nothing happens even though the Qube is running
Also this bash doesnt work either
qvm-start sys-net
bash: /usr/bin/qvm-start: cannot execute binary file: Exec format error
Do you see anything when looking in appvm log as suggested by marmarek?
General causes I have seen for that error:
- It really just needs more time (I’ve had this when rootfs needs resizing on startup). If so increasing
qvm-prefs sys-net qrexec_timeout can help.
- Misbehaving (passthrough of) PCI device on sys-net. If you
qvm-prefs some-other-appvm-without-attached-devices netvm none, can such other appvm start? If yes then that looks possible.
Found the fix, posting in case anyone else runs into this.
Problem: My screen froze completely, but I could still reach a terminal with Ctrl+Alt+F2. I ran sudo systemctl restart sddm to recover, which worked, but later when shutting down I saw some watchdog-related text flash before the screen went black. Next boot, nothing would start — no error, qubes just wouldn’t launch. After fixing that, qubes would start but nothing would open inside them (no terminal, file manager, or apps, in any qube).
Cause: Restarting sddm while Qubes was still fully running killed the graphical session abruptly instead of shutting things down cleanly. Whatever was mid-write to disk at that moment got corrupted/truncated, and the watchdog message afterward points to the underlying freeze forcing a rough reset. This broke a few small dom0 files, including the tools for starting/stopping qubes, and separately broke the autostart entry for qvm-start-daemon (the process that draws each qube’s windows).
Fix:
- Reinstall the corrupted admin tools:
sudo dnf reinstall qubes-core-admin-client
- Manually restart the GUI daemon process:
qvm-start-daemon --all --watch --kde
Windows for running qubes should appear immediately.