On Friday, November 24, 2017 at 3:15:06 PM UTC, Ray Joseph wrote: > Yuraeitha, > > > Thank you. That was great detail. > > > I think I will redirect output to one continuos file to collect all VM info > and use that file to record my progress. > > > My biggest obstacle is that when the machine boots up, I do not always get a > keyboard (laptop). Plugging in a USB keyboard and mouse does not always work > > Maybe this is related to the VMs. My fist install of V4 was with a docking > station attached. Keyboard and mouse functionality was intermittent but if > the embedded set did not work, I could plug kbd into the laptop USB slots or > docking station. To fix this, I reinstalled V4 without the docking station. > The kbd is less predictable/controllable. > > > In both cases, I have found that repeated reboots sometimes production es a > functioning keyboard. I have also found that letting the laptop sit for a > while will sometimes provide the keyboard. This latter feature is what leads > me to consider that service VMs may be at play. > > > I have "newly" loaded the latest two versions of Debian over 30 times and 3 > installs of Qubes-os. I am open to experimenting. My challenge with Debian > was getting wireless to work with Xen bridging. > > > On Nov 24, 2017 4:02 AM, "Yuraeitha" <yura...@gmail.com> wrote: > On Friday, November 24, 2017 at 2:01:18 AM UTC, Ray Joseph wrote: > > > Yuraeitha, > > > > > > 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 > > > > Good to hear you got stable WiFi :) > > > > 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 :) > > > > -- > > 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...@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.
oh, that's a pretty cool idea to collect it all in such a method. If it works well, consider sharing with the community if you feel like it :) You can also publicize a guide page to the QUbes docs on github on how to do this, I'm sure there must be other Qubes 4 users who'd appreciate it. 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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/afca52f0-14a9-4e30-a7dc-a4279639dda7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
