On Thursday, November 23, 2017 at 8:08:53 AM UTC, haaber wrote: > 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
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. -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/41e61f44-d8cc-4306-b5fd-ba00fcaa6556%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
