However following the instructions here:
https://www.qubes-os.org/doc/templates/debian/
namely:
[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-debian-8
I get "Nothing to do. Complete"
qvm-ls reveals that debian-8 is absent.
Is this instruction out of date or do I need to enable something first? Any tips appreciated.
The template re-install is currently broken, and requires fixing in a future patch. I've had/seen mixed results with the plain template install too (rather than re-install), so I suspect it's at least partly broken too? Either way it's not you, this is something that likely needs patch fixing. Possibly you can re-install Qubes and hope debian installs (sometimes work?, see below), or you could try move debian from one of your 3.2. backup archives, and then update it in Qubes 4 (hope for the best that the 3.2. template Qubes tools won't get in the way).
Also, in my own experience, I've installed Qubes 4 RC-2 on now 4-5 different hardware machines, including various different CPU architecturs, from the Intel i5 line, Intel M line, and Ryzen 3 1200. I've experienced different results.
For example, I never got debian working on my Intel i5 or Intel M architectures, but for what seems like a paradoxial twist of fate, my Ryzen architecture installs all templates perfectly fine, including debian-8. Everything just work here.
But on my Intel i5 or M processers, all which support minimum Qubes 4 specs btw, and HVM works just fine, however debian-8 just doesn't work.
I've had mixed results with Whonix-ws and Whonix-gw on the Intel architectures too, however fedora worked mostly on all systems.
Frankly I do not know if its caused by different CPU archtectures, however, from what I anecdotally experienced, it seems like what made the difference.
Also if you encounter python errors during the very last stage of Qubes 4 install, immediately reinstall, no second thoughts. Apparently this happens for no easy to observe reason too, but I'm able to make the last stage Qubes configuration work properly by re-installing a few times, try different settings, mess and push the system a little around, trial and error. Eventually I got a clean install, with no last stage python errors. I do not know exactly what made it work, or what caused it, except trial and error, and trying different install settings, seemed to work.
Also seen install and system stability outcomes between legacy BIOS and UEFI, however I did not test it extensively, nor can I confirm if it truly is so. It's just something I took slight notice of, and in my case, legacy BIOS seemed to fix my Ryzen system, which now runs Qubes templates flawlessly, except for the missing CPU features in this kernel, but at least it works.
Hopefully you can use any of this, but as said, nothing conclusive. But merely some experience and observation from many Qubes 4 RC-2 installs, on various different hardware systems.
I believe the debian template issue is somewhat related to the qvm-run or qvm-open-in-vm issues, but I'm definitely not sure if they are related. it just feels like that they are. Assuming they are indeed related, then Marek is at least partly confirmed to be aware of the issue. I'm not sure if he's fully aware of it yet, at least it doesn't seem like he was able to reproduce the problem, not at the time of his posting at least.
You can read a discussion here https://groups.google.com/forum/#!topic/qubes-devel/0wQftZSmYRY where Marek replied on a similar issue regarding the qvm-open-in-vm where I posted about qvm-run as well in addition to the original poster. I'm frankly also pretty frustrated with this template/AppVM issue, as you can read in those posts. But nevertheless, nothing to complain about, it's still in testing phase and not released yet, so its understandable. But my, it's one frustrating bug haha
I believe it to be related, also because on my Ryzen 3 1200 (legacy boot based) Qubes 4-rc2 system, everything works,
- all templates, including debian and whonix.
- qvm-run and qvm-open-in-vm also worked fine here.
However when it goes wrong, similar symptoms across both issues emerge on same systems, it seems?
I did not test the Ryzen system extensively, but I used it enough to feel it was a significant improvement over my own daily Intel M and Intel i5 system.
I'm really not sure if I was just lucky on Ryzen or if it's got anything to do with the architecture.
I had little luck with that approach on my system, perhaps others can make it work? But it might be because I did qvm-remove the template in dom0, before I did the dnf remove in dom0. Perhaps I messed it up this way, it certainly won't allow me to dnf remove the debian packages now.
Also is doing the 'sudo rm /etc/systemd/system/multi-user.target.wants/wpa_supplicant@.service' instrumental to the success?
That gives an error: qvm-template-preprocess: qube with this name does not exist
Try run "dnf search qubes-template-*" in dom0, it'll give you a list of all installed Qubes templates. It won't fix it, but it'll confirm if you got it currently installed or not. If the package is already installed, it'll explain why the install command in the first commend did not work. But in contrast it won't explain why you cannot reinstall/uninstall though.
Perhaps the next approach would be to manually remove the debian template? I'm a little unsure how to go about it though, especially in Qubes 4.
Anyone out there thinks its a good idea, and have suggestions on how to go about it?
Also I rapport that I tried installing debian-9, with little success, it has similar behavior as debian-8. But maybe your debian-9 install would work?
Yes I can confirm debian-8 is there. I'll ignore for now and wait til the next update. Thanks for your help.
> Then you can install the template again:
> sudo qubes-dom0-update qubes-template-debian-8
Thanks Chris. That worked
Indeed, I can confirm this too, it worked. Thanks a lot Chris! this was a pretty satisfying hack you suggested.
Unfortunately it did not solve my issues regarding starting up applications in the debian template, however at the very least it can now uninstall and install cleanly, and it also starts up cleanly, no apparent errors or bugs until it has fully started.
Seemingly, the Qubes tools need update in the template and re-released? or could it possibly by something else causing it? The Qubes tools just appear completely unresponsive in the debiam template.
JPL, what about you, can you start anything in your debian template?
I can do it on my Ryzen pc, but I can't do it on my Intel systems atm. So I know debian works for some people out there, I wonder what tricker this odd behaviour on some systems.