How to Setup Wireless
Ray Joseph
Where would I find this type of information. Searching the Qubes-OS doc, I only found one reference to wireless and that was how to unload and load the wirel drivers.
BTW, I had cloned sys-net vm to experiment. But it would not start. Andrew pointed to developer docs where it was stated that a vm that would use a device already in use will not start.
https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+label%3A%22C%3A+doc%22
Just for the record, since I will probably forget that.
Thanks,
Ray
donoban
Did you check if your wireless card is attached to your sys-net? Try
running "sudo lspci" on sys-net and look something like:
00:01.0 Network controller: Intel Corporation Wireless 7265 (rev 61)
If you don't see it try to attach it using the Qubes VM Manager (on
version 3.2).
If the device is right, check your dmesg log (running "sudo dmesg") on
sys-net and check if you are missing some proprietary firmware or it
complains about another problem.
Ray Joseph
Thank you. It is now running in dom0. I changed to v4.0RC1. My vms start intermittently so it is a challenge to test further.
I guess I could practice in v3.2 until v4 matures.
Yuraeitha
Actually, if you managed to get that far, you can probably manage to get Qubes 4 to run more or less smoothly. Albeit still may be unlucky to encounter a nasty bug of course, but in my own experience it runs pretty smoothly with newest updates and fixed user mistakes.
Qubes 4 user (or semi-user) mistakes that I encountered, that have a big impact on a working Qubes 4:
- Not making sure ALL VM's, i.e. from restored backup, are set to HVM instead of PV. This can mess up your VM's, as some systems can no longer run PV VM's properly in Qubes 4, despite having done so just fine in Qubes 3.2.
- Using any older Qubes 3.2. templates. A lot of changes was made to the Qubes tools, so the Qubes tools code probably changed in the VM templates too. Be sure you are mindful of this, if you insist on using an older Qubes 3.2. VM template.
- A bug in the AppVM templates, seem to mess up icon update in the XFCE4 menu, or somehow even preventing apps to start in VM's. If you encounter a bad AppVM, check if it was restored from Qubes 3.2. If so, then manually transfter your files, bookmarks, etc. out of it and over into a new Qubes 4 freshly made AppVM.
- VT-D and similar, is now required for a fully working system, instead of just recommended as it was in Qubes 3.2. and back. You may be able to install, but it won't run smooth without VT-D or similar supported tech.
- Newest Qubes (Testing update) has a drawback of Hibernate/Suspend breaking Wi-Fi, and various of other VM functionality. For example all your VM apps may be gone and cannot start. Only solution is either restart ALL your VM's, or in the worst cases, having to restart all of Qubes. Still, this is a testing update, and a user mistake for using a testing update. The developers will probably get it fixed eventually. Staying with regular updates should be safe, I assume of course. If you get the bug, then just be sure you save important work if you use suspend/hibernate. This is likely a pass-through issue (I think), but its definitely not a driver/module issue, like those we otherwise often saw in the past after hibernate/suspend. Either way, my guess is its probably soon fixed before it becomes a normal update.
I'm not saying to go Qubes 4 for stability or critical data production, though, in my experience the user (or semi user) mistakes above can have a huge impact on if Qubes 4 works properly or not.
There are still other issues, but they are getting more rare, and mostly everything seems to work now. Personally I'd rate Qubes RC-2, fully updated to this date, as late stage beta testing. But that's just my look at it.
If you got important work, then it's probably better to stay on Qubes 3.2. for a while yet. If not, and you want to play with Qubes, then you can probably get it work reasonably on supported hardware.
Ray Joseph
Thank you. All of that was news. The need to run all VMs as HVM is the only one that seems to be a concern. When I get wifi working, I never lose it.
This was a fresh install and I am testing with this machine.
I haven't been able to find how to convert existing VMs to HVM. Please suggest where I might find this. I've been going through docs and have not found it.
Ray
Yuraeitha
Almost all (if not all) the docs are currently out-of-date when it comes to Qubes 4, but up-to-date when it comes to Qubes 3.2.
This is why there is currently no doc for changing PV to HVM, or vice versa. HVM is prefered for security in Qubes 4, however both modes can give different hardware trouble. For example I personally get issues running PV, despite having PV working flawlessly back in Qubes 3.2. Others from what I can read might have issues with HVM, and need to fall back to PV instead.
That's why you can switch to whichever mode is preferred. But in terms of security HVM is better than PV. However HVM is not perfect either, but nontheless an improvement over PV. From what I've seen the developers discuss, it seems like the plan is to move towards PVH in a future Qubes release. This is in turn an improvement over HVM. So PV < HVM < PVH. So you want HVM for now, but can change to PVH in a future Qubes release, probably with the same command by then.
Unfortunately there is no easy way to print out which VM is in PV or HVM. At least, I haven't found it if there is any. The usual 'qvm-ls' command, usually used to print VM information like disk usages, network use, template use, etc. still appears to be in Qubes 3.2. version. For example a PV/HVM print in qvm-ls would seem like something extremely useful to add into the qvm-ls tool, so my guess is it's still something that needs fixing. Especially when PVH is added to the mix in a future Qubes release. the format, for example 'qvm-ls --format-help' doesn't give any PV/HVM information either in any of the various flags to print more details of different kinds. (btw, the qvm-ls --format disk' command is useful if you want to know how much each VM is using disk space, now that the Qubes Manager has been removed in Qubes 4. It can be troublesome if one of your VM's is eating up a lot of disk space and you can't find which one, especially on small SSD drives. That command can help with that.
Anyway, back to the PV/HVM issue. The command to print PV/HVM, if you're not familiar with the command already, then it can also give other VM information, try type 'qvm-prefs vm-name' on whichever vm you want to check VM preferences on. You'll see the virt_mode in here for the PV/HVM, along with various other VM specific preferences for that VM.
Optionally; for less terminal spam, you can type in this instead:
qvm-prefs vm-name virt_mode
If it gives you back PV print in terminal chat, then use keyboard arrow-up, so you can re-use the same command again, and then add HVM afterwards, so it becomes like this
qvm-prefs vm-name virt_mode HVM
Then repeat, go through all your VM's that might be in a PV state, be it TemplateVM's, AappVMs, ServiceVM's, DisposableVM's, etc.
Probably all your VM's originating from Qubes 4, are already set to HVM, but almost certainly, any VM you got from a Qubes 3.2. backup are in PV state. As far as I know, the Qubes team made it so the Qubes installer might default back to PV if it cannot install with HVM, if true, then there is a risk some of your original Qubes 4 VM's are in PV as well. If you want to be absolutely sure, spend a few minutes running through all your VM's to verify. Technically you don't need to print out, and can just use the change command on every VM, but it might be good to know if you corrected any, so making a print in chat first before changing, might be informative, especially if on a VM that previously has given trouble, or if the VM will give you trouble after changed to HVM. So it's a good idea to keep an eye out for changes you make instead of just rolling it out on all.
Also if some of the original VM's after install or VM's created in Qubes 4, are PV. Then it might be because your hardware doesn't like HVM and falls back to PV instead. Might be a good idea to keep in mind, start slow and verify if it can run HVM before changing all the other VM's if that's the case.
Personally I had to delete some of my AppVM's after changing from PV to HVM, as while it was an improvement, it wasn't enough in my situation to fix all of the issues. So I transfered my data and files from the few bad behaving AppVM's to a new Qubes 4 VM. The only AppVm's that missbehaved, were Qubes 3.2. backup AppVm's. Oddly, it was only some of them, and not all of them that misbehaved. To this day, I still don't know why that was the case. However, now most things works smoothly on my hardware at least.
Hopefully that should fix any issues if you got any :)
Ray Joseph
--
You received this message because you are subscribed to a topic in the Google Groups "qubes-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-users/k3dnlOt7Hfs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qubes-users+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/fc05cd6e-7bff-4945-9ba2-50e0dcd1bec9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Yuraeitha
> To post to this group, send email to qubes...@googlegroups.com.
>
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/fc05cd6e-7bff-4945-9ba2-50e0dcd1bec9%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
As for your keyboard problem, I might know the reason, though I'm not entirely sure, but I highly suspect it's something to do with bugs in the current booting process that affects seemingly all current Qubes 4 systems that are updated. Everyone have them atm it seems like, however not everyone use USB keyboards in a USB qube.
Whether everyone has it is a bit of a anecdotal guesswork based on how the bug behaves, though it does seem like being an universal issue. At the very least I have it too, but unlike you I don't use a usb qube for my keyboard/mouse.
It's pretty random for me as well, when I look in my "sudo journalctl --boot", sometimes my Qubes 4 even starts up with only the sys-firewall and the sys-net never started up. But on other boots, they're both there and works as they are supposed to. These very same VM's also gets messed up after suspend/hibernate, though that's less of a concern and just more annoying than a big problem.
Possibly we need some updates from the developers to ensure that the sys-firewall can't start without sys-net, and I suspect, sys-usb is having the exact same problem here.
Is your USB qube in a VM without networking? Maybe it can work better this way, so it's not relying on sys-net/sys-firewall which seem to be at random booting in wrong order or not at all.
I don't have much experience with the USB qube since I'm forced to not use it on my current primary Qubes system, because my touchscreen is tied to the USB controller. If I remove it, my screen will freeze. So I can't be entirely sure where the Qubes qube is supposed to be located, it's tied somewhere between sys-net/sys-firewall, or after sys-firewall?
What I imagine might help is a USB qube without networking though, since then at least the "order" VM's are started won't matter anymore, as long as it starts up.
Yuraeitha
> To post to this group, send email to qubes...@googlegroups.com.
>
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/fc05cd6e-7bff-4945-9ba2-50e0dcd1bec9%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
I'm not sure, generally it just seems like a problem for the high profile security, or for the more average user in a future where these attacks might become more commonplace.
btw, if you decide to mess around with the USB qube, be very careful not to loose USB keyboard. I hear it can be such a pain to restore USB keyboard/mouse functionality in Qubes, once it's lost. Thankfully I had an ps/2 port the one time it happened for me, however, it does seem a bit juicy if not having a way around without a keyboard. Backups before playing with it, might be a good backup plan too.