On Sunday, February 4, 2018 at 1:10:59 PM UTC+1, Nuno Branco wrote:
> So I decided to take a gamble and see if I could make the jump to 4.0. I
> 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
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
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
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
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.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.