Installing Debian template 4.0rc2
JPL
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.
Yuraeitha
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.
JPL
Chris Laprise
> On Saturday, November 11, 2017 at 12:23:28 PM UTC, JPL wrote:
>> For some reason the debian template didn't install when I installed Qubes, even though I selected it. No matter I thought, I'll do it manually.
>>
>> 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).
The first thing to try is 'sudo dnf remove qubes-template-debian-8' to
get the package out of there.
Another option is trying the current Debian release, version 9. There is
one issue (2913) where it takes 90sec to boot, but this should be
corrected soon and its easy to fix: After 90sec run a terminal and enter
'sudo rm
/etc/systemd/system/multi-user.target.wants/wpa_supplicant@.service'.
(Make sure you include the at-sign.)
--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
Yuraeitha
> Thanks for the detailed reply. I have an i7 machine, installing to a USB stick. Strangely, last time I tried (this is my second installation on the same USB having borked the first) debian-8 *did* install so it's obviously a very quirky bug. Whonix installed OK although it seems very slow (everything, not just Tor browser). I don't see this issue reported on Github. Is it worth reporting or are Axon, Marek et al aware?
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.
Yuraeitha
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?
JPL
>get the package out of there.
That gives an error: qvm-template-preprocess: qube with this name does not exist
Yuraeitha
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?
JPL
>Try run "dnf search qubes-template-*" in dom0, it'll give you a list of all >installed Qubes templates.
Yes I can confirm debian-8 is there. I'll ignore for now and wait til the next update. Thanks for your help.
Chris Laprise
the name 'debian-8' but of course you already removed those with
qvm-remove (which unfortunately allows this in R4.0). A way to work
around this is to clone any template to the name 'debian-8', therefore
providing the expected lvm volumes... then removing the template package
should work.
qvm-clone fedora-25 debian-8
sudo dnf remove qubes-template-debian-8
Then you can install the template again:
sudo qubes-dom0-update qubes-template-debian-8
>
>
> Also is doing the 'sudo rm /etc/systemd/system/multi-user.target.wants/wpa_supplicant@.service' instrumental to the success?
startup delays.
JPL
> sudo dnf remove qubes-template-debian-8
> Then you can install the template again:
> sudo qubes-dom0-update qubes-template-debian-8
Thanks Chris. That worked
Yuraeitha
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.