Issues with 4.0 rc4
Nuno Branco
know it is still not the final version and want to thank everyone that
worked hard on this and also want to report on some annoying things and
other more concerning things:
1) When installing Qubes 4.0RC4 from ISO I clearly selected to not
install any of the whonix templates, yet Qubes installed them anyway.
2) When restoring VMs from Qubes 3.2 the software does not seem to work
if you select more than one VM to restore at a time. By this I mean the
restore process launches and finishes and I do have a VM listed on Qubes
manager with the name of the VM I tried to restore however it reports
"disk size 0 MiB" - when I power on the VM and check /home it is empty.
If I restore the VMs one by one this does not happen and the VMs are
restored normally - this is obviously annoying (e.g. while writing this
email I had around 8 prompts for access)
3) When using split GPG I am constantly getting a popup message for
granting access from the VM with the mail app to the VM with the gpg app
- this popup completely disregards the authorization I gave the first VM
to access the second VM for "X minutes" and makes using split gpg a shore.
4) I am unable to create a proper HVM. I used the new command with
"qvm-create name --class StadaloneVM --label gray" and it works however
when i try to boot with "qvm-start name --cdrom=vm:/path/to/debian.iso"
nothing happens. I used qvm-prefs to set virtual mode to HVM and when I
try to start it this way the VM briefly boots but crashes before it
reaches the CDROM facility. The ISO file itself is fine as I used it for
the same purposes to create a 3.2 HVM and it booted.
5) This is probably been reported before but whenever you try to stop a
VM from qubes manager it errors out (the VM still stops).
6) When restoring a vm named "abcd" for some reason now i have a vm
named "xpto" and another vm named "disp-abcd" on my qubes manager that I
can't delete - says it is already in use. "abcd" is the only VM where
this happened and its only special feature is that it was a proxy VM in 3.2
If any logs are required to provide more information please let me know
what you need and I will try to provide.
--
Best regards,
Nuno Branco
Yuraeitha
Most of these things you listed can indeed be frustrating, but can be worked around until they are fixed. Feel free to ask for elaboration if I went over something not properly explained.
Below are my experiences from using Qubes 4 daily since early RC-2, in relation to your listed points. In other words I'm not an expert, but I have been using the Qubes 4 for a while now.
Reply to #1)
That's odd, it wasn't like t hat in the previous RC-X versions. I currently use RC-3 updated to RC-4 (no-reinstall required between these particular versions), and I did also not install Whonix/Debian-8 because I had to download newer versions anyhow, so it was redundant to install the older ones. So at least RC-3 did not install them. Perhaps this is a miss-step in the build of the RC-4? It may probably be corrected in possible final release, RC-5, or Qubes 4.1. later on, though it probably isn't on a high priority given the other issues to be fixed atm.
Reply to #2)
For now you may want to avoid using the GUI backup tools, it seems like it's not always perfect. Generally Qubes 4 has issues where either the terminal or the GUI works better, and usually one of the two is somewhat bug-free, while the other is buggy. Generally the terminal is the better choice, but not always. I imagine this will probably be fixed at some point soon once everything intended for Qubes 4 release works and the remaining issues are smoothing out issues like these. So my guess it will probably be updated later on. For backup and backup-restore recommend you use the dom0 terminal instead, from memory something like this qvm-backup-restore -d name-of-AppVM '/path-to-backup-inside-the-AppVM'.
Rememeber you can use '' on the path, like above, so it stays coherent as a single unit from the rest of the command. You can use "man qvm-backup" or "man qvm-backup-restore" for manuals, or check the guides on the Qubes doc page for further information.
ALso use "-x VM-name" to narrow down the VM's you do not want to restore, or alternatively instead just write the VM-name if you only want to restore a few VM's. For example "qvm-backup-restore -d name-of-AppVM '/path-to-backup-inside-the-AppVM' -x VM-Bob -x VM-Alice -x VM-and-so-on".
Also the Qube Manager does not currently update live, you need to shut it down and up again to see a new read-out. It may be easier to just have a dom0 terminal with "qvm-ls" and then just "arrow-up + enter" every time you need a new read-out.
Reply to #3
I'm not quite sure about what to suggest trying here. Maybe make a new one freshly made in Qubes 4. In my experience old Qubes 3.2. AppVM's just don't run very smoothly in Qubes 4. While this officially isn't the approach, I would recommend from my own anecdotal experience, that you transfer your files to new freshly made Qubes 4 VM's. This also fixes annoying bugs, like having to click on icons in dom0 menu's multiple of times before an app finally starts, which I've never seen happen on fresh Qubes 4 AppVM's. Also never use the Qubes 3.2. templates for anything reliable or important, better yet don't restore them. Though I don't think you're doing that, but just in case.
Reply to #4
Most things in Qubes 4 works better when using the dom0 terminal, because many things was done from scratch again to make the adminVM, a lot of new written python code, and so on. Funny thing is, creating new VM's actually works better with the GUI here, there always seems to be trouble when using the terminal when creating VM's, but I have never seen issues when using the GUI, not a single time. Try use the GUI instead found in the Qubes menu's, at least until it's fixed. Once you got the VM up, you can make changes to it. Ironically qvm-prefs seems more reliable than changing VM-settings too, for example PVH appears even though qvm-prefs reports HVM. It's my understanding that qvm-prefs is the one bug-free. So I recommend using the GUI to create VM's, and qvm-prefs to change VM settings. Qvm-block, qvm-usb, qvm-pci, also seems more smooth, although they are working somewhat fine via the GUI too.
Reply to #5
For now I would recommend avoiding the Qube Manager, from what I understand, they only barely managed to bring it back, it has not been fully worked out yet. From what I can see in some users post here and there, including my self, people tend to get used to not have the Qubes Manager. Now that the Qube Manager is back, I don't even need it anymore, I simply ignore it. If you can do the same, then you can avoid the problems involving the Qube Manager. Qubes 4 was not designed with the Qube Manager in mind, it's entirely an add-on solution to Qubes 4.
Resources are scarce, I'm sure it's not that they don't want to, but it's that they are quite busy. We may have to be patient on the things that are lower down the priority of things to be done, although it's still good to report issues like you did to increase awareness. What I mean here, is that it was never planned to bring back the Qube Manager, it was only brought back due to people asking for it to be brought back, but it's not as smooth as it was in Qubes 3.2. but worry not though, you can get by if you get used to the Qubes 4 ways of things, even if you once in a while have to touch the dom0 terminal a few times more, than you would normally do in Qubes 3.2.
Reply to #6 Try run "qvm-ls" in dom0 terminal, you'll see where your 'abcd' AppVM is tied down. Once you find the last tie, you should be able to delete it.
- - - - - -
Generally you can find ways to work around some of these frustrating things. There are often more than one way to do them, and currently often only a few or one of the ways to do them work, or work properly. Until the developers smooth out the alternative approaches to the various Qubes tools, we just have to find ways to make due. In my experience most things work, you just need to adapt for a while. For example always use terminal for backup until the GUI is fixed, always use the GUI to create VM's, always use the terminal to change VM settings, until the alternative has been updated and fixed. I believe the delay of these fixes are because one approach works, then it becomes lower priority until more important things work. So we just have to be patient, although still report issues in case they are not aware of them.
Hopefully this helped solving some questions (: Personally I love Qubes 4 and would at this point never consider going back to Qubes 3.2. Once you get used to the few quirks here and there which might be fixed soon at any rate, I'm sure you'll grow to enjoy it more too.
awokd
> On Sunday, February 4, 2018 at 1:10:59 PM UTC+1, Nuno Branco wrote:
In addition to what Yuraeitha wrote, check
https://github.com/QubesOS/qubes-issues/issues/3470.
> Reply to #4
qvm-prefs vmname kernel ""
Then do your qvm-start --cdrom.
Chris Laprise
> 2) When restoring VMs from Qubes 3.2 the software does not seem to work
> if you select more than one VM to restore at a time. By this I mean the
> restore process launches and finishes and I do have a VM listed on Qubes
> manager with the name of the VM I tried to restore however it reports
> "disk size 0 MiB" - when I power on the VM and check /home it is empty.
> If I restore the VMs one by one this does not happen and the VMs are
> restored normally - this is obviously annoying (e.g. while writing this
> email I had around 8 prompts for access)
restore -- it seems that backup was carefully constructed to work, but
restore was more thrown together from a patchwork of old and new code.
I just posted a fix for restoring dom0 specifically, which was still
broken when RC4 was released. If you don't exclude the dom0 home then
you'll almost certainly encounter errors; I expect the fix will get to
qubes*testing sometime in the next week or two. Also, restore is
currently best used in the CLI (its qvm-backup-restore) as the GUI still
has issues of its own.
I also decided to try a fresh RC4 install tonight and then restore an
R3.2 archive (minus dom0 home) to see how that goes. Maybe I'll be able
to recreate your issue...
--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
Chris Laprise
vms (did not have enough space to restore all) of small-medium size and
all of their data was restored intact, so I cannot reproduce your
problem. However I did use qvm-backup-restore in the dom0 CLI, not the GUI.