qubes 4.0rc2 install question

[haaber]

Hello,
I tried toinstall Q4.0-rc2 today. To my surprise the installer warns me
about hardware incompatibilities that should not exist, according to the
HCL : I have a i7-4600U cpu that has VT-x with EPT and VT-d as it should.
So I am confused ... qubes-hcl-report says "HVM not active", same for
"I/O MMU" and further "no HAP". Is this a maybe BIOS setting I have to
change? Or another (non-cpu) hardware incompatibility? Thank you,
Bernhard

[Tai...@gmx.com]

You gotta enable them in the BIOS configuration menu of course, assuming
your motherboard has implemented those features.

[Bernhard]

Thank you, that was all. I am astonished that features of the CPU must
be enabled by BIOS, this was out of horizon of imagination to me.

Best, Bernhard

[Bernhard]

Hello,
with your nice help I happily installed Q4.0rc2. Then I created a bunch
of debian-8 based appvm's, to copy my data back from the backup. But
they don't start, finishing with "Cannot execute qrexec-daemon" error. I
hate that error : no clue where it comes from. Any hints? Thank you!
Bernhard


P.S: First, I thought that this is the annoying but harmless
"after-tempate-change-xfce-menu-messy" bug (which forces to go to VM
settings, remove all Applications, save, go there again, put them back &
save again to get all symlinks right). But the problem is somewhere else.

[awokd]

On Mon, November 20, 2017 12:13, Bernhard wrote:
> Hello,
> with your nice help I happily installed Q4.0rc2. Then I created a bunch
> of debian-8 based appvm's, to copy my data back from the backup. But
> they don't start, finishing with "Cannot execute qrexec-daemon" error. I
> hate that error : no clue where it comes from. Any hints? Thank you!
> Bernhard

Check
https://github.com/QubesOS/qubes-issues/issues/3187#issuecomment-340440288
and the rest of this thread for other ideas:
https://mail-archive.com/qubes...@googlegroups.com/msg16026.html

[Yuraeitha]

I did not read through the link due to short of time atm, but here are some suggestions nontheless, as I've encountered similar issues once in Qubes 4.

- Make sure all your VM's are running in HVM mode, in particular if your system cannot run in PV mode. Paradoxially, some systems run PV mode just fine in Qubes 3.2., but PV stops working in Qubes 4. It doesnt matter anyhow, since HVM is the desired mode for now. So just make sure the VM is in HVM. Verify if "qvm-prefs VM-name virt_mode" is giving back PV or HVM. Try change it to HVM if it rapport back PV.

- Don't use any Qubes 3.2 templates, as they should not have the same Qubes tools code in them.

- Some AppVM's restored from Qubes 3.2. has in my experience been sluggish, laggy, and slow. I moved my data, bookmarks, thunderbird profile folder, etc. in traditional Linux backup sense, over to a new fresh Qubes 4 AppVM. It solved any lag I had, except, sometimes firefox was a bit laggy with 10 or so tabs, whereas before I could easily have 40 tabs open. The firefox browser update happened around same time, so not sure wihch was the cause. But cleaning old firefox data did not fix it, however a clean AppVM did fix it. The issue also extened outside firefox to other applications.

- If you cannot start an AppVM that you restored from the backup, assuming you still have the backup available in case anything goes wrong, then try change the Debian AppVM to a Fedora AppVM. Then see if you can trasfer your files out of the broken AppVM, either via Qubes tools, or passtrough an USB pen/drive and transfer it this way. Just be careful, I've been having issues where I was unable to disconnect my USB drive from within the old Qubes 3.2. AppVM, when I tried to salvage my data from it. Luckily it only caused damage to the last file from multiple of different transactions. In case you want to avoid this issue, it may be possible to do an extra transfer, with something pointless you dont mind loosing, just in case the last transfer made is destroyed when trying to disconnect the USB drive. USB works just fine in Qubes 4 AppVM's though, at least, that's my experience with it for now.

Hopefully you don't encounter the worst issues. At least I feel stable on Qubes 4 now, but its been a bit turbulent. Hopefully you'll be fine too.

Also, is it just me, or does Qubes 4 seem bloody fast in some areas after recent updates? Like shutting down VM's for example, it happens almost instantly, and various of other places that it seems much faster than Qubes 3.2. Perhaps its just my mind playing with me.

[haaber]

On 11/23/17 00:14, Yuraeitha wrote:
> On Monday, November 20, 2017 at 12:14:16 PM UTC, Bernhard wrote:
>> Hello,
>> with your nice help I happily installed Q4.0rc2. Then I created a bunch
>> of debian-8 based appvm's, to copy my data back from the backup. But
>> they don't start, finishing with "Cannot execute qrexec-daemon" error. I
>> hate that error : no clue where it comes from. Any hints? Thank you!
>> Bernhard
>>
>>

> I did not read through the link due to short of time atm, but here are some suggestions nontheless, as I've encountered similar issues once in Qubes 4.
>

> - Some AppVM's restored from Qubes 3.2. has in my experience been sluggish, laggy, and slow. I moved my data, bookmarks, thunderbird profile folder, etc. in traditional Linux backup sense, over to a new fresh Qubes 4 AppVM. It solved any lag I had, except, sometimes firefox was a bit laggy with 10 or so tabs, whereas before I could easily have 40 tabs open. The firefox browser update happened around same time, so not sure wihch was the cause. But cleaning old firefox data did not fix it, however a clean AppVM did fix it. The issue also extened outside firefox to other applications.

Thank you for the detailed answer. This is my way too. I keep the data,
but change all of the software. I am used to cryptsetup, losetup and
rsyncing data.

> - If you cannot start an AppVM that you restored from the backup, assuming you still have the backup available in case anything goes wrong, then try change the Debian AppVM to a Fedora AppVM. Then see if you can trasfer your files out of the broken AppVM, either via Qubes tools, or passtrough an USB pen/drive and transfer it this way. Just be careful, I've been having issues where I was unable to disconnect my USB drive from within the old Qubes 3.2. AppVM, when I tried to salvage my data from it. Luckily it only caused damage to the last file from multiple of different transactions. In case you want to avoid this issue, it may be possible to do an extra transfer, with something pointless you dont mind loosing, just in case the last transfer made is destroyed when trying to disconnect the USB drive. USB works just fine in Qubes 4 AppVM's though, at least, that's my experience with it for now.
>
> Hopefully you don't encounter the worst issues. At least I feel stable on Qubes 4 now, but its been a bit turbulent.
> Hopefully you'll be fine too.

I got through it, essentially via a full current-testing upgrade of
dom0. AppVM's work not both in pv and hvm, and also my mysterious rsync
errors (claiming out of space although there is plenty) disappeared
after the upgrade. Sometimes I don't try to understand the "why" if an
upgrade solves the issue :)

> Also, is it just me, or does Qubes 4 seem bloody fast in some areas after recent updates? Like shutting down VM's for example, it happens almost instantly, and various of other places that it seems much faster than Qubes 3.2. Perhaps its just my mind playing with me.

Well, boot is slow for me (> 1 min!), shutdown or reboot (of qubes)
finishes by a hang after log minutes (that is an issue! I have to power
off electrically in the moment). On the other side, I admit that AppVM
shutdown inside running qubes is almost immediate, and appvm-starts are
reasonably quick as well.

Thank you, Bernhard

[Yuraeitha]

Glad to hear you're getting towards a stable system :)
And indeed, too many "whys" asked even though when succeeded, and we'll end up growing old in front of the pc haha, I try to do the same, it can be such a thief of time.

Regarding the slow boot, I can think of a few different things. For example if you got ant auto-start on any VM's. Also currently, Qubes is not error/bug free during boot, you can see this if you run a 'journalctl --boot' and scroll down ( the long list is shortest right after a fresh boot). For exaple if you deled some old VM's, the boot process still tries to start them, but fails. I don't know how much time is wasted on it, but in my case, I have 3 old removed VM's trying to start during boot (now deleted, properly with qvm-remove at that).
Then in addition, any current existing VM's, which is set to start during boot.

Also, I believe this one was recently fixed, but at some point at least, there was an issue with which order VM's started. For example a VM that needed networking, tried to start before sys-net and sys-firewall, in the booting process, further delaying it. But I think its fixed now? At least simi-fixed if anything.

Also if you got Ryzen, or another new CPU or other new central hardware, then the kernel might have issues booting fast. For example Ryzen CPU's are a bit slower to boot on the 4.9~ kernels. It'll probably be faster once on 9.12+ and 9.15+ respectively, when Ryzen becomes better supported.

Also I found that ""some"" old AppVM's from my Qubes 3.2. were slow to start/shutdown (not all of them, only some). But this was before many of the current fixes was applied, so I dont know if it makes any difference anymore. However I more or less got rid of any old AppVM's from Qubes 3.2., and moved all my data, bookmarks, mails, etc. over to a new fresh Qubes 4 AppVM. It's much more smooth now. Also especially get rid of any old templates from Qubes 3.2., if any is laying around.