Neat! Using --prefs, one can skip some “grep” invocations, as well as forgo “qvm-check” because the qube name is always in the “name” preference:
_qube="sys-net"; [[ "" != $(qvm-ls --no-spinner --running --raw-list --prefs=name="${_qube}") ]] && echo True || echo false
(by True it means that the qube is running)
Secureblue template in Qubes would be great as well.
(Can vote on the issue here: SecureBlue template · Issue #9755 · QubesOS/qubes-issues · GitHub)
Did you manage to get s0ix/s2idle working on your machine?
Relating to the thread, I think s2idle suspend is a current paint point, particularly because OEMs usually provide no fallback to S3 suspend or good documentation for s2idle under Xen.
There is a thread about this Support for the S0ix sleep state · Issue #6411 · QubesOS/qubes-issues · GitHub
Related to this, maybe this is an AMD specific issue, but power management seems worse on newer platforms than older. Tend to get higher thermals on recent machines than older ones, performance is slightly better but it’s incredibly easy to get to over 90C with a 5+ VMs.
Sometimes, when I want to spawn a Qube, I will click multiple apps (for example, Firefox, Mousepad and File Manager). If I’m not quick enough, the menu will disappear as soon as the VM boots, so I can’t click everything at once. I will have to hover again over the qube and continue clicking.
This also happens to me when I kill a qube and start opening apps in other qube. If the qube dies before I reach the click, the menu will disappear and I will have to hover again and click.
This starts to get annoying when it happens a lot of times. I’m having this issue in Qubes 4.2.6, I haven’t upgraded to 4.3.0 yet, but if this isn’t done yet, it would be sooooo nice. It would make the user experience smoother and more responsive.
I mean, this issue is not the end of the world, but I would love if this got fixed 
I think that has something to do with notifications stealing focus. I have a similar issue on my XFCE machine.
Thanks, @Euwiiwueir @Atrate @solene! I’ll have to use those, but I hope it can be part of the qubes-app-idle package in the future.
Perhaps we should consider to support also the major kernel version included in the previous major release, if possible. When Qubes 4.4 is released, support the major kernel version of Qubes 4.3, and so on.
Here is one such case, where if a workaround was not found, the user would be in limbo:
That link is not stating the truth, as Whonix 17 is still supported for R4.2 until R4.2.4’s out of support date in June 2026!
The biggest problem I have is with the length of the AppVM/Template VM names. I like to give a thorough description of each template/AppVM including which Template it was cloned from, so i have reference. But putting in a short description takes up valuable space in a limited character name.
Request
Either allow many more characters (56? 128?) in a template/AppVM name, or allow a Notes/Info box in Qubes Manager, that allows us to quickly see information about where our Qube/Template came from and how it was designed.
You might want to upgrade to 4.3
qvm-features <template> provides information such as the original template (eg fedora-42) it’s EOL date, and other such info.
Hm, but the EOL date doesn’t seem to be accurate, for some reason. For example, my Debian 12 template reports os-eol 2026-07-11, but the actual EOL date will be 2026-06-10, according to DebianReleases - Debian Wiki. I wonder where these dates come from. @marmarek?
That’s what distro-info-data package says:
$ grep '^12\|^v' /usr/share/distro-info/debian.csv
version,codename,series,created,release,eol,eol-lts,eol-elts
12,Bookworm,bookworm,2021-08-14,2023-06-10,2026-07-11,2028-06-30,2033-06-30
If that date is wrong, it’s a bug in debian package.
It wouldnt be the first time, and isnt fixed in testing. 2026-06-10 is
to be found on the Debian site, Debian -- Debian Releases
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Open new windows in whatever workspace I clicked the app in. For example, if I open Firefox in workspace 2, on a non-running VM, it takes 5-10 seconds for the AppVM to launch and firefox to open. Now if during those 5-10 seconds I switch to a workspace 1, Firefox will open in workspace 1. I wish it’d open in workspace 2 so that way I can switch back to workspace 1 and do stuff for a few seconds, instead of having to just sit and wait until firefox opens in workspace 2.
When i start a DVM (disp0000) i would like Qubes tell me what is the #1 window so i do not accidentally close the window and loose my data.
DispVM need to inform the user which window can shutdown the dvm
You can do this yourself with some devilspie2 automation. A launch script that generates some temporary devilspie2 lua code to tie the chosen AppVM to the current workspace, then reloads devilspie2 to process the new code. You go on to other things for the next 5-10 seconds, the AppVM window/s get shifted to the appropriate workspace as they pop up.
This is trickier. You can hack up some code with wmctrl/xwininfo/xdotool etc. to correlate a window ID with its parent/ancestor processes, but I think it would require scripting in both dom0’s X and the dvm, and it will probably always be unreliable. It might be a case of a 70% solution that is less value than no solution at all.
So Qubes dev can’t do anything about that ?