Re: [qubes-devel] Panel widget indicating doesn't stop spinning
On Friday, March 16, 2018 at 10:50:47 AM UTC+1, awokd wrote: > On Fri, March 16, 2018 5:42 am, Elias Mårtenson wrote: > > Qubes 4, latest updates from testing. > > > > > > Sometimes (I'd guess perhaps 50% of the times) when I start a VM, the > > widget doesn't notice that the VM has finished starting, and instead the > > icon keeps spinning and the associated menu doesn't show the “shutdown” > > entry. > > > > However, the VM has successfully started and everything works correctly. > > ‘qvm-ls’ shows the VM as “Running” and all commandline operations works > > correctly. > > > > On the IRC channel other people mentioned they have the same issue, so it > > doesn't seem to be a problem that is unique to me. > > > > Is this a known problem with the widget? > > https://github.com/QubesOS/qubes-issues/issues/3660 looks related. btw awokd, are you having the issue too? I.e. does everyone get this bug? It seems many have it (including my self), but I wonder if it's perhaps triggered by something, or if everyone has it. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/06eeb32a-020a-4a42-8384-f61d612f8f88%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] What are we gonna do about Intel's move to kill off LegacyBios before 2020?
On Friday, March 16, 2018 at 4:52:47 PM UTC+1, awokd wrote: > On Fri, March 16, 2018 2:50 pm, taii...@gmx.com wrote: > > > As always I suggest encouraging the xen developers to accept help (from > > raptor and IBM) to port xen to POWER > > When I felt them out on it, I got the impression they were welcoming help > from anybody on porting Xen to POWER. > https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg08625.html > > Everyone's too busy now, but is there a long-term/blue-sky vision of Qubes > on non-x86 architectures, whether ARM, POWER or some other? Is that where > Qubes Air comes in? Staying true to the concept of isolating data from > exploited hardware seems to only be getting more difficult on x86. I've > read through some of the discussions on here about ARM, but (open)POWER > products are still pretty new. > > From Qubes' perspective, which arch. would make the most sense to pursue > long-term? Another futuristic perspective to think about in addition, is whether Qubes OS one day can function on the architectures of smartphones. For example, it might not be so much 're-inventing the wheel' work to get i.e. android working which already has all the needed phone software build into it, making it easier to get started. (And android can already boot in Qubes VM's). It would also be easy to switch the phone software, kind of like it's easy to switch the hyper-visor or templates in Qubes, so the concept isn't very foreign to what Qubes is already doing on pc hardware. It'd be quite interesting if it was possible to have something like a QubesPhone, or whatever it would be called. I do by no means have the right insight, but I imagine the biggest hurdles would be the hyper-visor architecture support on smartphone hardware, passing the second CPU chip (essentially the unwanted but forced spyware blobs) tunneled securely to the android AppVM, as well as building Qubes tools to function with touch-screen, etc. For example, the unwanted spyware second cpu blobs could be put in the phones equivalent to pc's sys-net, befind a sys-firewall. By all appearances we're moving towards an age where laptops one day not too far into the future will stop to exist altogether in favor of smartphone acting as a laptop, and instead connect to a bigger screen/keyboard/mouse with the smartphone. It'd be extremely interesting if this would one day be possible to do with Qubes. Smartphones are catching up too, at some point soon normal user wouldn't need all that computing power that can be put into phones, and for some users that's already the case already now. Qubes OS also seems more immune to failure here unlike Oracles Ubuntu phone failure, and the many others out there that failed. I mean, if small work can be done here and there, some day we might not need much to start installing Qubes on smartphones. Having the ability to shutoff microphone/camera/gps when not used is also extremely ideal, at the very least pulling it from android when not used (the second cpu spyware chip might be harder to block though). @tai...@gmx.com I can work with that, I'll call it BIOS instead on-wards. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/51a532c6-f7d1-446e-b702-e1c185fe7f3e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] What are we gonna do about Intel's move to kill off LegacyBios before 2020?
On Friday, March 16, 2018 at 2:07:09 PM UTC+1, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Fri, Mar 16, 2018 at 05:42:30AM -0700, Yuraeitha wrote: > > This is some months old news now from November 2017, and may already be in > > the plans to fix, however, I'm putting this forward as I'm not aware of any > > existing discussions on the matter, this is only an insurance so that we're > > not caught un-prepared for Intel's frustrating lock-in move. I apologize if > > it's already being discussed internally. Nonetheless, that being the case, > > this post can also serve as a heads-up to others in the community to be > > prepared for a new extra hardware issue angle. > > > > http://www.zdnet.com/article/intel-were-ending-all-legacy-bios-support-by-2020/ > > > > Articles like these, seem to point towards that Intel is making a move to > > remove LegacyBIOS completely. This by all appearances appear like it could > > become a major headache for many Qubes users on new hardware in the > > near-term future, considering some Intel devices are already taking this > > step to be ready by 2020 already now. > > > > Ignoring the otherwise important issue of the locked hardware/software > > blobs for a moment. Not solving this boot issue on time soon, seems like it > > might cause a big problem for many, many existing and new Qubes users > > getting new expensive hardware, if something isn't done to prevent or > > minimize it. > > > > Hardware compatibility is already an issue, Intel's move here just seems to > > make it worse. > > > > What can be done to solve this? Qubes/Xen would need better UEFI support? > > If answers have been found, is it something that possibly can be shared > > with us to ease the coming worries a bit? > > Generally Qubes OS and Xen do support UEFI, so this is not a blocker. > But there are some problems with various UEFI implementations, and also > with Xen inferior UEFI support. One of issue is combination of Grub(2) + > non-multiboot-compatible xen.efi. For Qubes OS 4.0, we've solved it by > removing grub from the picture[1]. But latest Xen version do support > multiboot, so better solution is on the horizon (Qubes OS 4.1?). > > [1] https://github.com/QubesOS/qubes-issues/issues/3505 > > - -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > -BEGIN PGP SIGNATURE- > > iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqlSIMACgkQ24/THMrX > 1yy0Twf/c2sxT6LG9k9mQw5M47CwGXsnvVRc+0JAgvnX/Ht9RLSl79ok9QQMvgps > u4RcmS4akv7YI1/vXKAt5ziUk6Jv2+Zd0Y8OIP8YPGHxxc0xF4CUS1AUt4yjrEh6 > amcAxW0X1PiCyiyCR9LnVktXVPV7MyDu6xUJ13jaQKFAaIddZjwJNovmW9ZqsA8H > vjvNdoJTbq8gVU10x64cYU7hECJDQgAJVWRlepsWKy6Trffn8+2zSuAXHaLRr2mj > UelBFGE0XspPlWHvWjLKuEeTS1ShsFvpRNPxCMfjEXFgUQFLLzGU28gV5ndVH/4Y > BkZxKQBBHcbPl6vPqEiL7TuBmHylOw== > =4Nf2 > -END PGP SIGNATURE- Thanks Marek, it's very comfortable knowing that you're still working on further improving the booting mechanisms, this puts worries for the future at ease. Greater UEFI compatibility certainly will help making it less expensive or risky in finding new unreported HCL hardware in the future, removing or reducing one of the new hardware complexities when hunting for Qubes hardware. As always, thanks for the amazing work you guys put into making Qubes OS. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/9393f8f1-7f3a-4513-ad55-1c716b6ec36f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] What are we gonna do about Intel's move to kill off LegacyBios before 2020?
This is some months old news now from November 2017, and may already be in the plans to fix, however, I'm putting this forward as I'm not aware of any existing discussions on the matter, this is only an insurance so that we're not caught un-prepared for Intel's frustrating lock-in move. I apologize if it's already being discussed internally. Nonetheless, that being the case, this post can also serve as a heads-up to others in the community to be prepared for a new extra hardware issue angle. http://www.zdnet.com/article/intel-were-ending-all-legacy-bios-support-by-2020/ Articles like these, seem to point towards that Intel is making a move to remove LegacyBIOS completely. This by all appearances appear like it could become a major headache for many Qubes users on new hardware in the near-term future, considering some Intel devices are already taking this step to be ready by 2020 already now. Ignoring the otherwise important issue of the locked hardware/software blobs for a moment. Not solving this boot issue on time soon, seems like it might cause a big problem for many, many existing and new Qubes users getting new expensive hardware, if something isn't done to prevent or minimize it. Hardware compatibility is already an issue, Intel's move here just seems to make it worse. What can be done to solve this? Qubes/Xen would need better UEFI support? If answers have been found, is it something that possibly can be shared with us to ease the coming worries a bit? -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/e84c3d5f-1acc-4a53-9a51-fd35e64d1771%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: Massive improvement in performance and battery life since switching to pvh
On Friday, February 16, 2018 at 4:05:56 AM UTC+1, pixel fairy wrote:
> On Tuesday, February 13, 2018 at 3:14:15 PM UTC-8, Jean-Philippe Ouellet
> wrote:
> > Thanks :)
> >
> > The ~10% cpu overhead for each linux-stubdom should still probably be
> > fixed for those who need HVMs (and for sys-{net,usb}), but still...
> >
> > My previously constantly-spinning laptop fans appreciate it.
> >
> > Cheers,
> > Jean-Philippe
>
> strange. i got the opposite, but given one of other replies, it may be
> specific to my motherboard. i realize its a stretch, but ill try it as soon
> as i get a chance. see
> https://groups.google.com/forum/?hl=en#!topic/qubes-users/YSeDcd91v-s
>
> its not just boot up times. some apps subjectively feel slower or jerkier,
> though watching movies in youtube in full screen still works in firefox, but
> not chrome.
My experience has been that creating new AppVM's sometimes smooth out AppVM
performance in Qubes 4, especially if that AppVM came from Qubes 3.2. or an
older RC Qubes 4 version (maybe I'm imaging things here, but it imho feels
noticeably smoother). You could try make a quick experiment by testing one of
those jerky apps in a new AppVM, before making any big changes, to confirm if
you can tell the difference or not.
Also in general I've felt big improvements in performance as well, though I did
not keep an eye on if the HVM --> PVH mode did it or not, but since Qubes 4
RC-2, todays Qubes 4 feels much more smooth and fast indeed.
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/4f341bfd-1a5a-40c1-afb7-cc5ba20c2a85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
On Friday, February 23, 2018 at 10:58:48 PM UTC+1, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Fri, Feb 23, 2018 at 01:27:41PM -0800, Yuraeitha wrote: > > On Thursday, February 22, 2018 at 9:26:42 AM UTC+1, Elias Mårtenson wrote: > > > On 22 Feb 2018 4:24 pm, "Yuraeitha" <yura...@gmail.com> wrote: > > > > > > Guess I'll draw the long straw, and just get rid of RC-3 and install RC-4 > > > without confirmation whether it'd any good to do so. I'll probably never > > > find out the reason, but it's starting to make me a bit uneasy whether it > > > could have been due to Qubes RC-3 or not. > > > > > > > > > I wouldn't bet on it. My system is based on rc4. My colleague who > > > installed rc3 did not have the problem. > > > > > > > > > Regards, > > > Elias > > > > > > While my qvm-copy issue is gone, what triggered the issue for me isn't, and > > by the looks of it, it looks like it could happen for another future update > > again, if it hasn't already happened in the past without showing signs of > > it. I believe this may be the reason the qvm-copy issue happend to me, > > although I can't be sure yet. There is also a chance it was the same that > > happened to you? But either way, this is what frequently happens on my > > setup, I started noticing it the last 14 days or so. > > > > Below is a recent example of the template's terminal output when it > > happens. I did the update after work followed up with sleeping, so I'm sure > > it was well beyond the default 6 hours for saving cache on repository > > updates. > > According to dnf.conf manual, "The default corresponds to 48 hours". > > Does it explains anything? > > > This also happened on the second template (fedora-26-apps), and not on the > > first template I ran the update (fedora-26). Could this be because the > > updates are handled in the same place and the cache wasn't cleared? It > > seems likely to be a legit explanation, although remains to be confirmed. > > > > There is also the issue I have with PGP checks, where I have to restart > > sys-net/sys-firewall to get proper PGP checks on updates. > > > > All these seem to be connected to each others. Cache doesn't seem to be > > cleared properly where Qubes handles the updates. I'm not sure if that is > > actually the explanation for the behavior though. It looks like this. > > > > This is from the latest update, the cache issue happens quite frequently > > despite the 6 hour window. > > > > > > [user@fedora-26-apps ~]$ sudo dnf update > > --enablerepo=qubes-vm-*-current-testing > > I'd recommend --refresh option, instead of separate "dnf clean all" > call. This will cause dnf to check if metadata on the server have > updated, and do not download (50+ MB) again if not. > > (...) > > > As it can be seen, in the first update it only checks the fedora > > repository, and no other repositories. > > I haven't observed the details yet, for example I'm not sure if it > > sometimes includes Qubes repository, but not the Qubes current-testing > > repository. I'm not sure if it's a all or nothing situation, or if it can > > be "mixed", for example if current-testing isn't included despite the > > --enablerepo=qubes-vm-*-current-testing flag. For now though, I just know > > it's at least an all or nothing issue, whether it can be mixed is too early > > to tell. > > > > At this point I might just re-install, unless it can be fixed. But it seems > > something is fundamentally broken, it seems safer to get a clean > > re-install. But I wonder if this could have explained the qvm-copy issue. > > Have you installed those updates now? The not-checking-updates issue > seems separate and in fact working as documented (but maybe not as > expected). Other issues, should be fixed in the update. > > - -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > -BEGIN PGP SIGNATURE- > > iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqQjoEACgkQ24/THMrX > 1yxKAQf8DZYI17fmswIFANu8osyFKhcV3JYVRVUcDbI68HN1r/bQHAdkx+Y68pep > 1oycNtiFYOGrPpzcWlbAVAMNdb/GJYhH/GxQSCRTuufxOFPljvNQtf7pMleeNh21 > dbfNsE8xZpbPTZ35j+baxjsb5jzLCcypUxzjU/1I3WfY9gmjQbXSoIvHacffGBex > nz+6rkFGMLDTULLvQWRkbwLM53oInkWxtU0BpAh6ZW2OyV4SMzFu+NkWnxve3Kw6 > Qx6wEPADErR+k3mVEVwEq0FNs
Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
On Thursday, February 22, 2018 at 9:26:42 AM UTC+1, Elias Mårtenson wrote: > On 22 Feb 2018 4:24 pm, "Yuraeitha" <yura...@gmail.com> wrote: > > Guess I'll draw the long straw, and just get rid of RC-3 and install RC-4 > without confirmation whether it'd any good to do so. I'll probably never find > out the reason, but it's starting to make me a bit uneasy whether it could > have been due to Qubes RC-3 or not. > > > I wouldn't bet on it. My system is based on rc4. My colleague who installed > rc3 did not have the problem. > > > Regards, > Elias While my qvm-copy issue is gone, what triggered the issue for me isn't, and by the looks of it, it looks like it could happen for another future update again, if it hasn't already happened in the past without showing signs of it. I believe this may be the reason the qvm-copy issue happend to me, although I can't be sure yet. There is also a chance it was the same that happened to you? But either way, this is what frequently happens on my setup, I started noticing it the last 14 days or so. Below is a recent example of the template's terminal output when it happens. I did the update after work followed up with sleeping, so I'm sure it was well beyond the default 6 hours for saving cache on repository updates. This also happened on the second template (fedora-26-apps), and not on the first template I ran the update (fedora-26). Could this be because the updates are handled in the same place and the cache wasn't cleared? It seems likely to be a legit explanation, although remains to be confirmed. There is also the issue I have with PGP checks, where I have to restart sys-net/sys-firewall to get proper PGP checks on updates. All these seem to be connected to each others. Cache doesn't seem to be cleared properly where Qubes handles the updates. I'm not sure if that is actually the explanation for the behavior though. It looks like this. This is from the latest update, the cache issue happens quite frequently despite the 6 hour window. [user@fedora-26-apps ~]$ sudo dnf update --enablerepo=qubes-vm-*-current-testing Fedora 26 - x86_64 - Updates2.3 MB/s | 20 MB 00:08 Last metadata expiration check: 0:00:12 ago on Feb Dependencies resolved. Nothing to do. Complete! [user@fedora-26-apps ~]$ sudo dnf clean all 44 files removed [user@fedora-26-apps ~]$ sudo dnf update --enablerepo=qubes-vm-*-current-testing Fedora 26 - x86_64 - Updates2.2 MB/s | 20 MB 00:09 Fedora 26 - x86_64 2.5 MB/s | 53 MB 00:21 Qubes OS Repository for VM (updates)106 kB/s | 55 kB 00:00 Qubes OS Repository for VM (updates-testing)291 kB/s | 182 kB 00:00 RPM Fusion for Fedora 26 - Free 1.0 MB/s | 519 kB 00:00 RPM Fusion for Fedora 26 - Nonfree 322 kB/s | 158 kB 00:00 Last metadata expiration check: 0:00:00 ago on Feb Dependencies resolved. Package Arch Version Repository Size Upgrading: python3-dnf-plugins-qubes-hooks x86_64 4.0.23-1.fc26 qubes-vm-r4.0-current-testing 8.9 k qubes-core-agent x86_64 4.0.23-1.fc26 qubes-vm-r4.0-current-testing 107 k qubes-core-agent-dom0-updates x86_64 4.0.23-1.fc26 qubes-vm-r4.0-current-testing 8.3 k qubes-core-agent-nautilus x86_64 4.0.23-1.fc26 qubes-vm-r4.0-current-testing 11 k qubes-core-agent-network-manager x86_64 4.0.23-1.fc26 qubes-vm-r4.0-current-testing 9.3 k qubes-core-agent-networking x86_64 4.0.23-1.fc26 qubes-vm-r4.0-current-testing 17 k qubes-core-agent-passwordless-root x86_64 4.0.23-1.fc26 qubes-vm-r4.0-current-testing 8.5 k qubes-core-agent-qrexec x86_64 4.0.23-1.fc26 qubes-vm-r4.0-current-testing 30 k qubes-core-agent-systemd x86_64 4.0.23-1.fc26 qubes-vm-r4.0-current-testing 22 k Transaction Summary Upgrade 9 Packages Total download size: 222 k Is this ok [y/N]: As it can be seen, in the first update it only checks the fedora repository, and no other repositories. I haven't observed the details yet, for example I'm not sure if it sometimes includes Qubes repository, but not the Qubes current-testing repository. I'm not sure if it's a all or nothing situation, or if it can be "mixed", for example if current-testing isn't included despite the --enablerepo=qubes-vm-*-current-testing flag. For now though, I just know it's at least an all or nothing issue, whether it can be mixed is too early to
Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
On Thursday, February 22, 2018 at 6:20:54 AM UTC+1, Elias Mårtenson wrote: > On Thursday, 22 February 2018 00:52:03 UTC+8, Yuraeitha wrote: > > > This is really weird indeed... there somehow seems to be a time or random > > factor involved? I believe there were a few before us too, who also had > > problems for a while even after a restart, but it was resolved eventually > > on > > its own? (At least that's the impression I got from reading those posts). > > Now > > the same happened to me, it just went away on its own. Then the question > > is, > > what is triggering this "delay"? > > > > Could it be some system cache of sorts? also did you install > > current-testing? > > That's the one I used today. I also sometimes have to do 'clean all' or > > restart sys-net and sys-firewall, for the updater to work properly, which > > either can't find the updates or return PGP check errors. Sometimes I need > > to > > do both, but typically the VM restart is just needed when PGP errors come > > up > > during downloads. if I don't do that once in a while, especially if the > > system has been running for a while, then I've frequently run into these > > issues the last 14 days or so. It may be a long shot, but you can try these > > things out too. For example I use qubes-dom0-update --action='clean all' > > and > > then clean all in the respective template too. > > I figured it out. > > The problem was indeed that the template had not been updated to testing. > This was caused by the repositories file being reverted back to its original > (non-testing) state. I believe this was caused by me executing the wrong Salt > state when I was experimenting with that previously. > > Thanks a lot for the help, both you and Marek. Good you got it working (: It's still frustrating me a bit though, I never found out what triggered the fix for me, besides the extra update that had no qubes-tools in it like the first one had. Either something is wrong with my system, or I did a user mistake. Guess I'll draw the long straw, and just get rid of RC-3 and install RC-4 without confirmation whether it'd any good to do so. I'll probably never find out the reason, but it's starting to make me a bit uneasy whether it could have been due to Qubes RC-3 or not. Either way, it may still have been a user mistake, but at least it wasn't the update command (I use arrow up to get the command from last time I updated, and when checking the last commands, it's still correct) or the lack of restarts (which I tried). I've verified both of these multiple of times over before the fix kicked in. This weird behavior makes me a bit uneasy, I wonder if RC-3 could have explained it or not. In the end it may just have been that I missed something and did a mistake, but not having an answer to this weird issue bugs me. But I probably won't be able to find answers though, so maybe it's best to just forget about it and move on (after I get rid of RC-3, just to be on the safe side, and maybe it fixes those annoying update cache issues I've experiencing recently). -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/6d985656-060f-4ca5-9592-6d0f3d08653c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
On Wednesday, February 21, 2018 at 4:59:39 PM UTC+1, Elias Mårtenson wrote: > On Wednesday, 21 February 2018 23:42:18 UTC+8, Yuraeitha wrote: > > > On another bright side or bonus, Qubes > > even seem more smooth now. It's like old > > creeky wheels has gotten some oil and > > it's running more smooth. It can > > definitely be felt, at least on my > > system. For example one noticeable > > difference is how fast VM's shutdown is > > after use. > > > > Can you reproduce this fix Elias? > > I did try to update and reboot today, but > the problem remained. > > I also noted that "open in dispvm" doesn't > work, but I presume that's a consequence > of qvm-copy not working. > > It is funny that qvm-copy-to-vm works. I > wonder what the difference is between > these. This is really weird indeed... there somehow seems to be a time or random factor involved? I believe there were a few before us too, who also had problems for a while even after a restart, but it was resolved eventually on its own? (At least that's the impression I got from reading those posts). Now the same happened to me, it just went away on its own. Then the question is, what is triggering this "delay"? Could it be some system cache of sorts? also did you install current-testing? That's the one I used today. I also sometimes have to do 'clean all' or restart sys-net and sys-firewall, for the updater to work properly, which either can't find the updates or return PGP check errors. Sometimes I need to do both, but typically the VM restart is just needed when PGP errors come up during downloads. if I don't do that once in a while, especially if the system has been running for a while, then I've frequently run into these issues the last 14 days or so. It may be a long shot, but you can try these things out too. For example I use qubes-dom0-update --action='clean all' and then clean all in the respective template too. Usually if the updater pulls down repository updates, and it returns no PGP errors during the update downloads, then there is no cache issue. Or so I believe, I can't tell the difference otherwise. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/b5ff17b9-6e46-414b-97de-24ca0d13719b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
On Wednesday, February 21, 2018 at 8:25:52 AM UTC+1, Elias Mårtenson wrote: > On Wednesday, 21 February 2018 02:26:16 UTC+8, Marek Marczykowski-Górecki > wrote: > > > qvm-copy command takes only filename, the VM name you give in qrexec > > confirmation prompt. > > After doing a full reboot of the system, and making sure that everything is > updated, qvm-copy-to-vm now works, but qvm-copy still gives me the permission > error. > > As the Nautilus integration uses qvm-copy (rather than qvm-copy-to-vm) it too > fails, in the same way as before. > > A colleague of mine who installed rc3 (and has updated everything from > testing since) just did a full update and he's not seeing the same problem. > > Regards, > Elias @Elias I got mine resolved, I'm not sure exactly how as it doesn't make sense, but the new updates that arrived (which seems to have nothing to do with this bug) somehow fixed this bug for me. It went like this. I tested if the bug was still there in these steps: - Rebooting multiple of times again, nothing helped, it didn't go away. - Testing if the bug was there right before new update today, it was still there. - Testing if the bug was there right after new update today, it was still there. - Rebooted after the above update and testing, and now it's "magically" gone. On another bright side or bonus, Qubes even seem more smooth now. It's like old creeky wheels has gotten some oil and it's running more smooth. It can definitely be felt, at least on my system. For example one noticeable difference is how fast VM's shutdown after use. Can you reproduce this fix Elias? -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/3bc005d3-e626-417f-8d65-a228228d44a0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
On Tuesday, February 20, 2018 at 7:26:16 PM UTC+1, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Tue, Feb 20, 2018 at 09:07:34AM -0800, Yuraeitha wrote: > > - The GUI copy to VM now works, but the terminal qvm-copy still doesn't > > work. > > qvm-copy command takes only filename, the VM name you give in qrexec > confirmation prompt. > > - -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > -BEGIN PGP SIGNATURE- > > iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqMaBcACgkQ24/THMrX > 1yxRQgf/YtF1OCeg/iwryngYe+4PI0tv6x9h+ZZISzL1ppVCTEyWa2PJouDZ9GeB > OVZSlGnu/0hmEd4CsXzGsu011PHRYK5dPeQFMq3EmywJQy9gXQh72ifkqZbYscO3 > WuXYHf8NK/OzxlUZHCKrpurjFtOLZpZTXa79UMd1lkscmnpS0PAI72Nqi0xd6mJf > DQ81u0tzh57QQmM3qJJSFBMMac6TR9i0zSvEWVacYVuzdIeFSMEf1v4GqPRG2lsQ > 3xNQvm76JQ/WU0s886qNCl0Q3M7kZ41OlH7gy1PhG9QINBUW1aacnxLXrKP3zNu6 > psvUm9UaEu2cFpLLRF5FV2FBE0xHNA== > =/if3 > -END PGP SIGNATURE- ah I see, that really simplifies the command compared to the old, or maybe it was always like that in VM's and I didn't realize. Either way though, the issue is still there without putting the VM name in the command, but now the "Request refused." is back in the place of the error. It strikes me as a little odd that it changed on its own this time without me doing anything new (I did nothing special except restarting the VM in question, perhaps it was that). It's the same changed feedback (from error to missing permission) if applying the VM name in the command. This is a peculiar oddball error. Multiple of full system restarts, and it just won't go away despite careful maintenance procedures, or so I would like to think anyway. (i.e. I don't just recklessly update with wrong repositories between dom0/templates, plug the power, etc.). This is not a personal issue for me though, not yet at least. I'll wait and see if something new happens, right now I don't think I can add anything new. Now that full 10-12 second long system-wide freeze that happened earlier today after the update, worries me a bit more. But it hasn't happened since then though. It wasn't too long after returning from suspend, and occurred immediately after starting a another VM. I had little spare RAM left at the time (8GB total) and more VM's running than normal, so maybe that's part of the issue, but normally it would just not start if not enough RAM is left and not cause a freeze like that. I don't expect a personal followup on this, I'm only mentioning this one time incident for awareness. At the time of the system-wide freeze, it had only been restarted once after the update. If a second restart could fix something like that, then maybe it's gone now *shrug* -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ca684ebb-c9e6-4d6f-80b8-2a0c2a9904c7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
On Tuesday, February 20, 2018 at 5:15:08 PM UTC+1, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Tue, Feb 20, 2018 at 08:08:54AM -0800, Yuraeitha wrote: > > On Tuesday, February 20, 2018 at 4:52:00 PM UTC+1, Marek > > Marczykowski-Górecki wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA256 > > > > > > On Tue, Feb 20, 2018 at 07:40:15AM -0800, Yuraeitha wrote: > > > > On Tuesday, February 20, 2018 at 4:38:26 PM UTC+1, Yuraeitha wrote: > > > > > On Tuesday, February 20, 2018 at 4:06:58 PM UTC+1, Marek > > > > > Marczykowski-Górecki wrote: > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > > > > Hash: SHA256 > > > > > > > > > > > > On Tue, Feb 20, 2018 at 02:24:22AM -0800, Elias Mårtenson wrote: > > > > > > > After doing the most recent qubes-dom0-update from the testing > > > > > > > repository, all RPC calls from one VM to another stopped working. > > > > > > > Calls from dom0 still works fine. > > > > > > > > > > > > > > By "not working" I mean that the call to qrexec-client-vm gives > > > > > > > me a "Request refused". > > > > > > > > > > > > Have you updated also templates? If not, install updates also there > > > > > > and > > > > > > restart all the VMs. Details here: > > > > > > https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-038-2018.txt > > > > > > > > > > Just tested qvm-copy (terminal) on both debian-9 and another fedora-9 > > > > > clone I've got. I've also tried debian-9 to debian-9 only. Same error > > > > > message across the board, in all 3 different templates. > > > > > > > > Apologies, fedora-26* not fedora-9. > > > > > > Looks like one more thing needs to be restarted: the tool handling > > > RPC calls confirmations: > > > > > > In dom0, as normal user: > > > > > > killall qrexec-policy-agent > > > qrexec-policy-agent >>~/.xsession-errors 2>&1 & > > > > It seems writing these commands solved half the problem? I now get the same > > error that Elias was talking about "Request refused" instead of the issue > > that it can't find the location. It's a pretty short message, just an > > outright permission denial. > > > > I got an odd feedback from the second command in dom0 though, maybe it's > > not normal? > > > > $ killall qrexec-policy-agent > > $ qrexec-policy-agent >>~/.xsession-errors 2>$1 & > > & not $ > > > [1] 16771 > > bash: $1: ambiguous redirect > > [1]+ Exit 1 qrexec-policy-agent >> ~/.xsession-errors 2> $1 > > > - -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > -BEGIN PGP SIGNATURE- > > iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqMSVsACgkQ24/THMrX > 1yyZigf+I/of4t9uufxPJd2bIe9GZB+B+U0GHaM7lsxXTe4ZUE+B8aw2kORpeB9K > JW2Yymvhwy1aT1xerfy0CZgk7pCCwddD9QUks+uapaxZ6gDi9eKu8FYN38W2nxu+ > ofLkmjOnMwXxs8rPTjjjZ9HKRScdBxHjDqUyiR7Vy4yYvYrIk3t+UvHYhYEBZ0VS > k9ly3yKSN3KombvPLtkUHzXHmsY0PW+CPlsmZ0Wv+K6b8EJEypshTtdbN0v1Ho1W > 7AwPwyS/a/SroGU6i1tCr7vR3CKb/FkyGjJm8MU0mcRUc57oGH+H1dic+tF3qPDg > eq1Wzmcdd0KUw1hGoHQAE7X2hQhWCg== > =QPhx > -END PGP SIGNATURE- Sorry about that. - I corrected my typo and ran both commands again, it now gives back a normal feedback in dom0. - The GUI copy to VM now works, but the terminal qvm-copy still doesn't work. - I did a full shutdown, then a start again. No changes, the GUI right click on file to copy to VM still works, but the terminal does not. - I attached a screenshot of how it looks when the terminal gives the error. It's the same error that came from before typing the 2 commands you gave. Correcting my typo returned the error message instead of the mentioned permission request. - I made sure to put the address correct, the one you can see in the screenshot, by drag and dropping the file, so that the path was auto-generated. There should therefore presumably be no typo's in the path address. It's also the same error from all the previous issues. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/75cd4728-4041-44d2-a758-4d2119f4cdbb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
On Tuesday, February 20, 2018 at 4:52:00 PM UTC+1, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Tue, Feb 20, 2018 at 07:40:15AM -0800, Yuraeitha wrote: > > On Tuesday, February 20, 2018 at 4:38:26 PM UTC+1, Yuraeitha wrote: > > > On Tuesday, February 20, 2018 at 4:06:58 PM UTC+1, Marek > > > Marczykowski-Górecki wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > > > Hash: SHA256 > > > > > > > > On Tue, Feb 20, 2018 at 02:24:22AM -0800, Elias Mårtenson wrote: > > > > > After doing the most recent qubes-dom0-update from the testing > > > > > repository, all RPC calls from one VM to another stopped working. > > > > > Calls from dom0 still works fine. > > > > > > > > > > By "not working" I mean that the call to qrexec-client-vm gives me a > > > > > "Request refused". > > > > > > > > Have you updated also templates? If not, install updates also there and > > > > restart all the VMs. Details here: > > > > https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-038-2018.txt > > > > > > Just tested qvm-copy (terminal) on both debian-9 and another fedora-9 > > > clone I've got. I've also tried debian-9 to debian-9 only. Same error > > > message across the board, in all 3 different templates. > > > > Apologies, fedora-26* not fedora-9. > > Looks like one more thing needs to be restarted: the tool handling > RPC calls confirmations: > > In dom0, as normal user: > > killall qrexec-policy-agent > qrexec-policy-agent >>~/.xsession-errors 2>&1 & > > - -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > -BEGIN PGP SIGNATURE- > > iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqMQ+4ACgkQ24/THMrX > 1ywD6QgAg5XOhohAUNjHlAzL3Ua4jqaBG+5JsIyGkbmwiPYL928E+COvYG8WRf02 > 7v1oJZIxGo+cN6SehM7psg8xkAx/XLVBOgjF2dBz2dLfhg+JihX6s1qHeGDLnHwi > 4RSV8iHyqGp38S+ujcx6yuY2+ufNbNBR3WHg9pA+cufBUsHDTp+xm9ZY4e2KB4P9 > RQ9TufAE9W3511poSRXejtjKY+qKqIzWY5S2mGpe2wnUWma5Ps4lLmMaDezewoh6 > +TVY+vcolKh9ZbDGzhKNSon4FygvSB190OQjYa+i3MmK1tCtqSDm4vONKDABLqAA > gDUz/H0mF6AXd/JrwBMtVP8pjZAjDg== > =s3Eo > -END PGP SIGNATURE- It seems writing these commands solved half the problem? I now get the same error that Elias was talking about "Request refused" instead of the issue that it can't find the location. It's a pretty short message, just an outright permission denial. I got an odd feedback from the second command in dom0 though, maybe it's not normal? $ killall qrexec-policy-agent $ qrexec-policy-agent >>~/.xsession-errors 2>$1 & [1] 16771 bash: $1: ambiguous redirect [1]+ Exit 1 qrexec-policy-agent >> ~/.xsession-errors 2> $1 Written over exactly as it looks in the dom0, I'm not sure if it's meant to give this reply back or if this is normal. I'll do a new restart and more testing once I get off the road. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/f565b3eb-730f-4b13-8b6c-7dfb12497f4f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
On Tuesday, February 20, 2018 at 4:38:26 PM UTC+1, Yuraeitha wrote: > On Tuesday, February 20, 2018 at 4:06:58 PM UTC+1, Marek Marczykowski-Górecki > wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > On Tue, Feb 20, 2018 at 02:24:22AM -0800, Elias Mårtenson wrote: > > > After doing the most recent qubes-dom0-update from the testing > > > repository, all RPC calls from one VM to another stopped working. Calls > > > from dom0 still works fine. > > > > > > By "not working" I mean that the call to qrexec-client-vm gives me a > > > "Request refused". > > > > Have you updated also templates? If not, install updates also there and > > restart all the VMs. Details here: > > https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-038-2018.txt > > > > - -- > > Best Regards, > > Marek Marczykowski-Górecki > > Invisible Things Lab > > A: Because it messes up the order in which people normally read text. > > Q: Why is top-posting such a bad thing? > > -BEGIN PGP SIGNATURE- > > > > iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqMOWIACgkQ24/THMrX > > 1ywCxAf/ad8xHLawtWPnwZxoBvc/ZT7PdfhOQjexUwcy03fRVDdvHUpSlAekfQ/2 > > mhdzxSyqYvZveeZkO3prKsEmYeNpG4bhOMXbh3cPqrcDS6jv7CAuQieaUlk1neyD > > T7P/3nSNU+Q/+eokXf40qg8rZhdHzz6JvY04lEg9kwkMD+jAHDZlzIJdeMb7ZJ6U > > 6ot9XUcYk+WC0a5FjzMHqRtDI9cTwzqqrgPMhp5bRANvLnyCdo7wL/m6C6s+yWKr > > Ny+p/18IoySwIz1+j6FMMRDU60YmFqKZlfqteHCIvxqwBdp+nSonQ6+SzehUF4bS > > xSU0Ff9LL6VOFLfjDdkz93gvRVY1Yw== > > =57Zw > > -END PGP SIGNATURE- > > Just tested qvm-copy (terminal) on both debian-9 and another fedora-9 clone > I've got. I've also tried debian-9 to debian-9 only. Same error message > across the board, in all 3 different templates. Apologies, fedora-26* not fedora-9. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/1f6c1248-017b-4492-ade2-3a6b9b3db3af%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
On Tuesday, February 20, 2018 at 4:06:58 PM UTC+1, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Tue, Feb 20, 2018 at 02:24:22AM -0800, Elias Mårtenson wrote: > > After doing the most recent qubes-dom0-update from the testing repository, > > all RPC calls from one VM to another stopped working. Calls from dom0 still > > works fine. > > > > By "not working" I mean that the call to qrexec-client-vm gives me a > > "Request refused". > > Have you updated also templates? If not, install updates also there and > restart all the VMs. Details here: > https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-038-2018.txt > > - -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > -BEGIN PGP SIGNATURE- > > iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqMOWIACgkQ24/THMrX > 1ywCxAf/ad8xHLawtWPnwZxoBvc/ZT7PdfhOQjexUwcy03fRVDdvHUpSlAekfQ/2 > mhdzxSyqYvZveeZkO3prKsEmYeNpG4bhOMXbh3cPqrcDS6jv7CAuQieaUlk1neyD > T7P/3nSNU+Q/+eokXf40qg8rZhdHzz6JvY04lEg9kwkMD+jAHDZlzIJdeMb7ZJ6U > 6ot9XUcYk+WC0a5FjzMHqRtDI9cTwzqqrgPMhp5bRANvLnyCdo7wL/m6C6s+yWKr > Ny+p/18IoySwIz1+j6FMMRDU60YmFqKZlfqteHCIvxqwBdp+nSonQ6+SzehUF4bS > xSU0Ff9LL6VOFLfjDdkz93gvRVY1Yw== > =57Zw > -END PGP SIGNATURE- Just tested qvm-copy (terminal) on both debian-9 and another fedora-9 clone I've got. I've also tried debian-9 to debian-9 only. Same error message across the board, in all 3 different templates. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/25c306fb-e22b-4e5a-a353-57ebc46bf448%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
On Tuesday, February 20, 2018 at 4:06:58 PM UTC+1, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Tue, Feb 20, 2018 at 02:24:22AM -0800, Elias Mårtenson wrote: > > After doing the most recent qubes-dom0-update from the testing repository, > > all RPC calls from one VM to another stopped working. Calls from dom0 still > > works fine. > > > > By "not working" I mean that the call to qrexec-client-vm gives me a > > "Request refused". > > Have you updated also templates? If not, install updates also there and > restart all the VMs. Details here: > https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-038-2018.txt > > - -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > -BEGIN PGP SIGNATURE- > > iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqMOWIACgkQ24/THMrX > 1ywCxAf/ad8xHLawtWPnwZxoBvc/ZT7PdfhOQjexUwcy03fRVDdvHUpSlAekfQ/2 > mhdzxSyqYvZveeZkO3prKsEmYeNpG4bhOMXbh3cPqrcDS6jv7CAuQieaUlk1neyD > T7P/3nSNU+Q/+eokXf40qg8rZhdHzz6JvY04lEg9kwkMD+jAHDZlzIJdeMb7ZJ6U > 6ot9XUcYk+WC0a5FjzMHqRtDI9cTwzqqrgPMhp5bRANvLnyCdo7wL/m6C6s+yWKr > Ny+p/18IoySwIz1+j6FMMRDU60YmFqKZlfqteHCIvxqwBdp+nSonQ6+SzehUF4bS > xSU0Ff9LL6VOFLfjDdkz93gvRVY1Yw== > =57Zw > -END PGP SIGNATURE- I can verify that the computer on my end had the template updated yes, also full system restart by shutting down the computer, then starting again. Everything was updated before restart. Commands that was used, checked by opening terminal and arrow up in history: dom0: sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing fedora-26: sudo dnf update --enablerepo=qubes-vm-*-current-testing It's not the issue this time, however I've experienced some issues with the update not going through properly where I had to run 'sudo dnf clean all' first before I could update. The first update today was like that too, but I believe I caught all of situations it happened in the different templates? I've seen it both in dom0 and in the fedora template. Upstream fedora dnf bug maybe? Time-span was last 14 days or so, but I'm not sure if it could have occurred longer back. I just did a clean all now again, no new updates was available afterwards. So I guess it isn't this cache issue. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/901559de-7dd6-44e7-bcfa-70a319f324c5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: Possible regression: vm-to-vm RPC calls stopped working
On Tuesday, February 20, 2018 at 3:37:54 PM UTC+1, Elias Mårtenson wrote: > I'm away from my computer at the moment so I can't try to reproduce all your > tests, but I did try to use copy-to-vm from Nautilus on a fedora-26 > template-based vm and it didn't seem to do anything. The menu just closed. > > I can't say if anything else in the Nautilus instance worked after that, as I > closed the window after that. It seems we both have the same, it would seem? It seems to behave slightly different, but the same bug by the looks of it. I found more odd behaviour after I decided to test a bit more. Used 2 different AppVM's, same template again. This time I used the terminal instead of the GUI, so nautilus was excluded in the equation. I did not know qvm-copy-to-vm/qvm-move-to-vm had been deprecated, the terminal told me just now. But funnily enough, the old deprecated qvm-copy-to-vm command worked just fine, while the new qvm-copy failed. I suppose the old deprecated qvm-copy-to-vm can be a short-term temporary solution if it's needed? If it's still there and not removed despite being deprecated, then I suppose it's still safe to use the deprecated version? - - - - - - Also, before I did any of the above, between my two posts here, I encountered a 10-12 seconds or so long system wide freeze, entire screen, all VM's, dom0, mouse, everything frooze. I've never had this before on this machine, and I've never seen it in Qubes 4. This was something very new, or so it seems at least. My laptop only has 8GB ram, so I guess it could be something related to RAM. But whether these two issues are related or not? I don't know. But it had never happened before today, and I've used this computer everyday for months, running Qubes 4 since RC-2. Could the RAM balancing between the AppVM's have been affected too, perhaps? -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/4d84619d-c2ff-4c66-9e14-1cdd2e709e9f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] qubes-firewall script error handling
On Monday, February 19, 2018 at 12:30:52 AM UTC+1, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Sun, Feb 18, 2018 at 01:10:44PM -0500, Chris Laprise wrote: > > I'm thinking about posting a PR to have qubes-firewall raise errors whenever > > a firewall script from qubes-firewall-user-script or qubes-firewall.d > > returns an error code. > > > > The object is to provide a way to make the qubes-firewall service fail when > > firewall scripts encounter an error. On failure, the result would be that > > forwarding (or networking) is disabled and any units bound to qubes-firewall > > would not run. > > > > Default behavior would be little different than it is now, given that shell > > scripts are fault-tolerant. But script authors will have the option of using > > "set -e" or "exit 1" etc. so the service goes into a failed state. > > Problems like crashed qubes-firewall are very annoying and it isn't easy > to find where such service have crashed. Also, script exiting with > non-zero code can happen for various reasons, including misusing "[ > condition ] && action" syntax. I've seen far to many errors like that. > > But if the script author know what he/she is doing, having option to > fail closed is a good idea. What about choosing en exit code that would > cause the effect you propose? And let that not be 1. This could allow > both: fail closed for conscious user, and harder to break the setup by > stupid error. The idea is inspired by Restart*ExitStatus= settings of > systemd.service and git bisect run. > > - -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > -BEGIN PGP SIGNATURE- > > iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqKDIMACgkQ24/THMrX > 1yxJKwf9FKb4Cl9aB1uW14PH1+O2G/6vfs0cDjLfcaxt6Rx6j58sotKflwhvL6l/ > XcQx/jorAqp+3NyH4+4Y4JK6cEVgind+EAP5PQ16PFKuLkV5UwrGvR6HBXAKzcf5 > i+tIXumYYPJ+rUXbkXccCRIddHcjLnViiWjOHwU9nPg3UTDi0/5om2wOTJPw3ciA > 8vCG78iJBnAWPFM8nx47pJMClbQUiyvm/FRq9lnWdasDuf3Edb10QaYHWf+1x9Sq > ptgjryQduGmvZpgxWA/O6m7b4AvawrIuH3gWAk6ssBzT3+LSgfCQHG48QMJnaOie > urmNZhh8cXmiHa/hfty2d9ZsnEIDkw== > =RXyO > -END PGP SIGNATURE- What are the prospects of using multiple of firewalls on Qubes, if the intention is to run something that is "unique", or if VM's talk to each others, or if hosting a server on Qubes? Each of these, representing a need for a seperate firewall. Would this be useful from a security point of view? For example I've always wanted to host a mini-server on my Qubes laptop, but I'm worried modifying the firewall can cause system-wide issues that can be exploited, or just flat out cause errors like the ones mentioned here. As such, in terms of having a default firewall for non-changed Qubes, and a modified firewall for special modifications? Kind of like everything else in Qubes work by not having a single point of failure. Would this be feasible? and would it make errors less likely to happen in the default firewall, if special use-cases are kept on seperate firewall AppVM's? -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/df60091e-7ba4-4a09-91ed-bed55e9566a3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: Qubes 4.0 - there will be rc5
On Thursday, February 15, 2018 at 3:00:10 PM UTC+1, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi, > > Looking at the state of rc4, we're still not satisfied with the quality > - - there will be rc5. Updated schedule here: > https://www.qubes-os.org/doc/releases/4.0/schedule/ > > - -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > -BEGIN PGP SIGNATURE- > > iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqFkk0ACgkQ24/THMrX > 1yxc8Af/WprY336X/xF1z7mhaxDX3F0UmIzM+G6uDsorYRi8MOr+/dQrIhPiekAl > BOcvicCJVsIDu7CKy7KNjxceEYFTnhqqCqxKOeehfKrCM8a856jfyVzLFJGmH2o4 > V9j0SwF6ThdrolTkINZt3A8Hrh7Nr26h7Wbsj58LkBKMcWe7+7HzY7+jyR98kgGb > 8kEwFnLbAjiF1AKWA+4BStT+JPUc1GCb0plfg+m6Fh+8PZxhr1F6WlHiSWQORWUD > 9uutxosrMfUKtuCU4zo1KdOplIhQVz8Ev5MGOkp2pJk9vtCQ9IP1C7zyphz9D7pH > Tk0+4jL96dV6gHhZI+Lbz7/zGNLBIg== > =u2Uk > -END PGP SIGNATURE- I second 7v5w7go9ub0o's notion, please take your time. I believe others feel the same, but I can only speak for my self; I really appreciate the touch of quality you guys put into this amazing project! Hoping you guys eventually get larger donations/income to reward all this work and effort you're putting into Qubes OS and its mission. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/475f0331-a42a-47c5-abe7-cc5b6601f687%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: Display blank / won't refresh image after suspend/resume
On Sunday, February 11, 2018 at 5:36:12 AM UTC+1, joev...@gmail.com wrote: > [No responses from qubes-users, trying here next!] > > https://github.com/QubesOS/qubes-issues/issues/3558 > > In RC4.0... After suspend/resume > Any monitors that were inverted or rotated, will be black. > > The mouse does move across the screen... but no objects move on this screen. > Refreshing the configurations by toggling to another terminal (ctrl-alt-f2) > then back again (ctrl-alt-f1), or changing the resolution/position of screens > in xrandr/arandr/etc/... will restore the last known image on the affected > monitors. > > Reconfiguring the affected screen to remove invert/rotate settings does > restore the image refreshing ability. The monitors behave normal, but I need > them inverted. > > Logging off or restarting X server does not fix the issue. > A reboot is needed to restore the desired behavior of having a working and > inverted screen. > > Very problematic as I do need to suspend resume a lot. Did you try restart LightDM in TTY2 terminal? As I understand it, it's a layer below the x-server because LightDM will start/stop the x-server whenever it's starting or stopping. You probably can't fix this issue which seems heavily XFCE4 related, by just restarting the x-server. You most likely need to go deeper, and restart the LightDM. Plenty of guides on the internet on how to do that btw, in case you need an approach. It's not uncommon for XFCE4 to loose configuration files. Hard reset can for example mess-up the Whisker-menu XFCE4-panel plugin configuration files. Updates to the packages can cause old custom settings not to be loaded. And probably suspend/hibernate too. Also it may be driver related, if some people can't reproduce your issue, then it's likely driver/hardware related issue, and perhaps blacklisting hardware so that a driver is unplugged before suspend/hibernate, and then automatically brought back after suspend/hibernate, may very well fix issues. But you need to know which driver that is causing the issue. If its driver related, which it may very well be, then it can be as simple as changing your kernel version, or even xen version. If older versions do not work, then you may need to wait for a newer version. It's my understanding possible that sometimes other code can trigger driver bugs, which were otherwise dormant. So it may not entirely be driver related, however, it does look like it's XFCE4/driver related. Maybe it's the graphic/screen driver. I'm not sure if a blacklist before/after suspend/hibernate of a graphic driver is feasible, but it may be another clue you could try look further into. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/9138463c-532f-4161-b25d-34efe26388ad%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Are there currently anyone assigned to update Qubes-Windows-Tools?
On Friday, February 9, 2018 at 6:58:24 AM UTC+1, Ivan Mitev wrote: > > FYI I've just added a "Fresh install on R4" section. It's still a work > > in progress though: I get a cryptic msg in guest-win7-dm.log file a bit > > after the first part of the setup reboots the VM. > > > > qemu: /home/user/qubes-src/vmm-xen-stubdom-linux/build/qemu/exec.c:1187: > > cpu_physical_memory_snapshot_get_dirty: Assertion `start + length <= > > snap->end' failed. > > > For anybody following the thread - searching the web for a similar error > shows that it could be related to a problem with qemu's VGA [1] (if > that's indeed the problem here, there's a patch from Aug. 2017 [2], > maybe it's not yet in the xen stubdomain source used by qubes). > > Thinking it could be related to issue #2488 [3] I tried to use cirrus > instead of (std)vga but the instructions in the issue are specific to > R3.2 and it wasn't immediately clear where to change the configuration > (nothing in `virsh dumpxml vmname` either). Maybe there's simply no way > to use cirrus with the more modern stubdomain used by R4. > > Veering way off-topic from the OP - I'll open an issue once I manage to > do more tests. > > > [1] https://nvd.nist.gov/vuln/detail/CVE-2017-13673 > [2] https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg04685.html > [3] https://github.com/QubesOS/qubes-issues/issues/2488 Speaking of graphic errors, there is another one I noticed that was around in Qubes 3.2. but I noticed it's now also be present in Qubes 4. I did not realize earlier since until last few days, I had not used Windows my self at all on Qubes 4. The behavior is the interface locking and becoming immune to mouse clicks only (left and right mouse buttons), but keyboard and moving the cursor around still works fine, it's essentially only left+right mouse-buttons that stops working by the looks of it. The odd thing is it's relatively easy to quick-fix, since every time it's happened, clicking the middle mouse-button (or scroll-wheel mouse-button for those few mouses that have this ability), seems to fix this issue, 100%, always. The problem here is not so much the annoying thing that it happens, especially when it's this easy to fix. But more so if people using Windows are not aware of this quick-fix, and moreover, perhaps not everyone have a mouse with a middle-button or other mouse-button that resets the bug. Worse yet, may be laptop mouse-pads. Perhaps there are sufficient clues to track another quick-fix for people without a mouse with a middle-button to reset this bug? It'd also be interesting to see how common this issue is. I've seen it on three vastly different hardware setups running Qubes+Windows. So far if including past Qubes 3.2. installations where the bug also was present, this bug seems common? Does it happen to you as well? I've seen this issue at least once every Windows start over longer extended use (10+ minutes, and only happens if you click on the Windows interface menu's like folder and menu navigation buttons). -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/666349e2-45b9-4904-899d-343a80cc06b3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Are there currently anyone assigned to update Qubes-Windows-Tools?
@Ivan On Thursday, February 8, 2018 at 1:22:06 PM UTC+1, Ivan Mitev wrote: > >> - I think it's great if you post your guide for others to see :) You > >> can always leave a disclaimer, such as no code has not been audited in > >> this particular case, however that it worked for a few of users who > >> tried it (it worked for me on my first try, more to come though). If > >> people have all available information, including the disclaimer, then > >> they can make calls for themselves, so that responsibility is not put > >> on you if something should go wrong. > > > > Well, strictly speaking there's no "guide" yet :) - only bits and parts > > in notes, ML posts or from the official qubes documentation. Marek's > > last post also provided a lot of informative stuff. > > > > Ideally there should be a wiki page with those tests and pieces of info, > > with more relaxed "commit" rights than the official Qubes docs so that > > users can freely change/fix the instructions until things settle down - > > at which point they could maybe be included in the official documentation. > > > > I see there's a handful of free wiki sites on the web, I'll try to setup > > a page on one of those. But as usual, not ETA - I have very little free > > time ; if you'd like you can go ahead and publish what you already > > have/found out and I'll definitely help with the content and tests. > > so, I found some time and created this: > > https://github.com/taradiddles/qubes-notes/wiki/Windows-VM > > It's a bit of a hodgepodge from various ML posts and my own notes. The > edit policy is open to everyone, so anyone - feel free to add your own > stuff. > > (I hope it's not a problem to create such an unofficial wiki; If it is > I'll delete it and I'll try to make the doc a bit more pretty and send a > PR for inclusion in the official doc; alternatively, such a wiki could > be created in the qubes-doc repository). > > Ivan It's looking really good, it looks like you got every currently confirmed Windows issues on there in a well-written and easy to read page. This will definitely be helpful to point to for those switching from Q3.2. to Q4.0. and are asking about Windows support. I like your idea about an official Wiki page too for Qubes, in the fashion you described it. I imagine an easy to find link to such a Qubes wiki on the www.qubes-os.org website might be really good, so that more people may discover it and use it. And considering it's available on github, which seems like a big plus as well. It'd be interesting to know what the Qubes developers/staff feel about your wiki suggestion. Also the current doc section on the official website is becoming a bit over-cluttered as its growing over time. A wiki indeed seems like it might make good sense at this point, especially if more doc's are to appear on-wards. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/f8f6e1b9-cc56-481e-85bf-ff7770c30e02%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Are there currently anyone assigned to update Qubes-Windows-Tools?
@awokd On Thursday, February 8, 2018 at 12:10:18 AM UTC+1, awokd wrote: > On Wed, February 7, 2018 10:38 pm, Yuraeitha wrote: > > > > > > Have you ever experienced crashes while running search files on disk from > > the Windows menu? If so, maybe we can turn off the search function to > > avoid any issues? > > Disk activity seems to trigger it for me too. I still get the occasional > crash when anti-virus scan runs for example, but it's been rare enough I > haven't looked into it any further. I already have search disabled so yes, > try it out too! Will do, hopefully it'll make a difference. It's frustrating that anti-virus does it too though. Maybe we can disable it on the AppVM, but only keep it enabled on the template of Windows? I never got around to get Windows template to work though, but I imagine it might be a way to bypass the anti-virus issue on daily use-cases. I'm pondering about the Superfetch service too, I recall from earlier days that Windows Superfetch could give issues, but as far as I remember it was never truly verified, at least not as an official note. Situations seem to be when having too little RAM on a hardware Windows install, perhaps it causes issues too with too little RAM on a VM install? I'll try disable mine, but I'm not sure if it will change anything related to the stability, other than its intended function of a bit faster application-start of course. Another issue I found, which I'm not yet sure is a problem or not, seems to be when closing Windows via the Qubes 4 widget, that it happens a lot, lot faster, compared to if you close Windows with the Windows own shutdown button, which is slow, but will eventually shutdown entirely in Qubes as well. I haven't verified it yet, but it does look like the Qubes 4 doesn't give room for updates to tick. Perhaps the intention here is that Qubes 4 widget is meant for AppVM versions of Windows, while the template should be shutdown with Windows's own shutdown command? It's fortunate that seamless mode doesn't have to be enabled on the Windows template to make use of the AppVM seamless mode. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/3907a2ac-49b7-4486-be57-85055a880458%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Are there currently anyone assigned to update Qubes-Windows-Tools?
On Thursday, February 8, 2018 at 2:13:42 AM UTC+1, Marek Marczykowski-Górecki
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Wed, Feb 07, 2018 at 02:18:59PM -0800, Yuraeitha wrote:
> > @Ivan
> >
> > On Monday, February 5, 2018 at 7:50:30 AM UTC+1, Ivan Mitev wrote:
> > > On 02/04/18 19:26, Yuraeitha wrote:
> > > > On Sunday, February 4, 2018 at 6:00:15 PM UTC+1, Ivan Mitev wrote:
> > > >>> Also it seems like some functions "might (maybe)" work as intended,
> > > >>> for example I can copy files between VM's and Win7, on a Win7 that
> > > >>> was installed on Qubes 3.2., but backup restored on Qubes 4. Others
> > > >>> seem like they can do this too. Also it seems it's a common problem
> > > >>> not to be internet in the restored Q3.2-Win7, perhaps the code is
> > > >>> different in regards to how it ties networking with Qubes 4? I have
> > > >>> no idea about the rest of the mechanics from a users perspective
> > > >>> though, and most certainly not as a developer as I unfortunately
> > > >>> don't have such skills, I wish I could help more.
> > > >>
> > > >> I just spent a bit of time restoring my windows VM from 3.2, here are a
> > > >> few notes that might be helpful to work around some bugs that you're
> > > >> probably hitting too (I haven't filed any issues yet):
> > > >>
> > > >> - PVH/HVM: in the VM's settings gui, PVH is always displayed whatever
> > > >> the real pref value. -> use qvm-prefs vmname virt_mode to make sure
> > > >> you're really in HVM mode.
> > > >>
> > > >> - Networking: the PV network adapter was stuck at "Identifying" ;
> > > >> pinging an *ip* works but ping a host fails. tcpdump on sys-firewall
> > > >> shows that the requests were sent to the gateway's ip and were
> > > >> rejected.
> > > >> The reason seems to be that in R4.0 VMs are now using the exposed
> > > >> "/qubes-{primary,secondary}-dns" values, while in R3.2 the DNS server
> > > >> was the same as "/qubes-gateway" (see [1]). In my setup,
> > > >> "/qubes-{primary,secondary}-dns" are 10.139.1.{1,2} and /qubes-gateway
> > > >> is 10.137.0.6. DNS requests are rejected because they're sent to
> > > >> 10.137.0.6 instead of 10.139.1.{1,2}
>
> Yes, exactly. Actually /qubes-primary-dns entry is present on R3.2 too,
> but is the same as /qubes-gateway.
>
> > > >> workaround 1-> manually set the DNS servers to
> > > >> /qubes-{primary,secondary}-dns ips. Ping and Internet Explorer worked,
> > > >> but the PV adapter was still suck at "identifying" and my Amazon Kindle
> > > >> for PC app complained about finding no network (it seems there's a
> > > >> windows "connectivity" API/flag that some apps use). However you will
> > > >> have to do this each time after boot since Qubes tools will reset the
> > > >> network settings.
> > > >>
> > > >> workaround 2-> in Program Files/Invisible.../Qubes.../bin/..., rename
> > > >> network-setup.exe to network-setup.exe.bkp to prevent Qubes tools from
> > > >> messing with your network settings, and manually set the VM's IP and
> > > >> DNS
> > > >> servers in the PV adapter network setting. Everything should then work
> > > >> OK, the only problem being that you'll have to make sure you keep your
> > > >> network settings synced (esp. the IP when you clone the VM).
> > > >>
> > > >> - Copying to/from the Win VM: works perfectly - you just have to type
> > > >> twice the destination VM (once in Windows, once in Qubes/dom0), since
> > > >> Qubes Tools aren't updated to reflect R4.0 new "way".
>
> I guess this should be easy to fix, just need to skip the first prompt
> and provide "$default" as destination name in qrexec call.
> Looks this file is relevant:
> https://github.com/QubesOS/qubes-core-agent-windows/blob/master/core-agent-windows.wxs
>
> Compare "Copy to other VM" and "Edit in DispVM" entries.
>
> > > >> note: before finding what was causing the connectivity problem I tried
> > > >> to update xen's windows PV drivers [2] but it broke the VM (ie. it
> > > >> wasn't starting
Re: [qubes-devel] Are there currently anyone assigned to update Qubes-Windows-Tools?
@awokd On Sunday, February 4, 2018 at 8:44:31 PM UTC+1, awokd wrote: > On Sun, February 4, 2018 5:23 pm, Yuraeitha wrote: > > > Another user in another Qubes 4 Win7 thread somewhere in Qubes-users > > mail-list, suggested to reduce the page-file for Windows SWAP inside the > > Windows VM. It worked for him, and when I tried it out, it worked for me > > too. It's possible this is what you encounter, try reduce the Windows > > page-file and see if it works? > > That was yours truly. I think it's more the act of setting the swap file > to a fixed size (of 1GB) that helped stabilize mine, but maybe you're > right and it's actually the size reduction. ohh, I apologize for forgetting your name at that time, back then most people were still strangers to me, and it takes a while for me to remember names. But I know I won't forget your name again now as I already remember it since a few topic discussions between back then and now ^.^ About the page-file size, I'm not sure either. I tried to restore a new Windows 7 backup again, and I tried giving the page-file 1.1GB as well as 2GB, to see if it would become unstable. It seems it was unstable on the first restart for the lower one (the one I started with), but after the second restart it became stable. This may also be due to the change of AppVM RAM which was 4GB before changing, and was given 2GB after changing the page-file. Which further complicates it. But after these two restarts, it was pretty smooth again, like the other Win7 I have tried it on before that. However, it once again became unstable during Windows updates + using the Search-files feature in Windows 7 start menu. Perhaps this instability is related to the drive's file-system (NTFS) of different and various sorts? It seems the page-file can remove the most frequent crashes by far, but a few others can cause it too, like searching the file-system while the system is busy with something else perhaps? I have a weak CPU on this laptop though, it's an Intel Core M-5Y10c @ 800Mhz. 8GB RAM. So I haven't used a strong system to test Win7 on. Although Windows 7 aside, everything in Qubes which is within normal-use runs more or less smoothly, and Windows 7 can run almost smoothly on this poor laptop. Although I'm not yet sure if running it on a stronger machine may make Win7 more smooth, or cause less crashes. Have you ever experienced crashes while running search files on disk from the Windows menu? If so, maybe we can turn off the search function to avoid any issues? -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/82bff806-e3b7-4465-b1c0-a84e3251cd83%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Are there currently anyone assigned to update Qubes-Windows-Tools?
@Ivan
On Monday, February 5, 2018 at 7:50:30 AM UTC+1, Ivan Mitev wrote:
> On 02/04/18 19:26, Yuraeitha wrote:
> > On Sunday, February 4, 2018 at 6:00:15 PM UTC+1, Ivan Mitev wrote:
> >>> Also it seems like some functions "might (maybe)" work as intended, for
> >>> example I can copy files between VM's and Win7, on a Win7 that was
> >>> installed on Qubes 3.2., but backup restored on Qubes 4. Others seem like
> >>> they can do this too. Also it seems it's a common problem not to be
> >>> internet in the restored Q3.2-Win7, perhaps the code is different in
> >>> regards to how it ties networking with Qubes 4? I have no idea about the
> >>> rest of the mechanics from a users perspective though, and most certainly
> >>> not as a developer as I unfortunately don't have such skills, I wish I
> >>> could help more.
> >>
> >> I just spent a bit of time restoring my windows VM from 3.2, here are a
> >> few notes that might be helpful to work around some bugs that you're
> >> probably hitting too (I haven't filed any issues yet):
> >>
> >> - PVH/HVM: in the VM's settings gui, PVH is always displayed whatever
> >> the real pref value. -> use qvm-prefs vmname virt_mode to make sure
> >> you're really in HVM mode.
> >>
> >> - Networking: the PV network adapter was stuck at "Identifying" ;
> >> pinging an *ip* works but ping a host fails. tcpdump on sys-firewall
> >> shows that the requests were sent to the gateway's ip and were rejected.
> >> The reason seems to be that in R4.0 VMs are now using the exposed
> >> "/qubes-{primary,secondary}-dns" values, while in R3.2 the DNS server
> >> was the same as "/qubes-gateway" (see [1]). In my setup,
> >> "/qubes-{primary,secondary}-dns" are 10.139.1.{1,2} and /qubes-gateway
> >> is 10.137.0.6. DNS requests are rejected because they're sent to
> >> 10.137.0.6 instead of 10.139.1.{1,2}
> >>
> >> workaround 1-> manually set the DNS servers to
> >> /qubes-{primary,secondary}-dns ips. Ping and Internet Explorer worked,
> >> but the PV adapter was still suck at "identifying" and my Amazon Kindle
> >> for PC app complained about finding no network (it seems there's a
> >> windows "connectivity" API/flag that some apps use). However you will
> >> have to do this each time after boot since Qubes tools will reset the
> >> network settings.
> >>
> >> workaround 2-> in Program Files/Invisible.../Qubes.../bin/..., rename
> >> network-setup.exe to network-setup.exe.bkp to prevent Qubes tools from
> >> messing with your network settings, and manually set the VM's IP and DNS
> >> servers in the PV adapter network setting. Everything should then work
> >> OK, the only problem being that you'll have to make sure you keep your
> >> network settings synced (esp. the IP when you clone the VM).
> >>
> >> - Copying to/from the Win VM: works perfectly - you just have to type
> >> twice the destination VM (once in Windows, once in Qubes/dom0), since
> >> Qubes Tools aren't updated to reflect R4.0 new "way".
> >>
> >>
> >> note: before finding what was causing the connectivity problem I tried
> >> to update xen's windows PV drivers [2] but it broke the VM (ie. it
> >> wasn't starting anymore) so I had to restore it again. Anyway IIRC R3.2
> >> Qubes Tool's drivers were at the same version as Xen's (8.2), so no need
> >> to fiddle with this.
> >>
> >> I was thinking about posting those steps on qubes-users@ but I don't
> >> feel I had done enough testing on my VM yet. I see you're quite active
> >> on qubes-users so feel free to redact/post some of my remarks if you
> >> think they'll help.
> >>
> >> [ an unofficial wiki would be a helpful bridge between the MLs and
> >> Qubes' official documentation: it's difficult to skim through all the
> >> related ML posts and IMO Qubes' official documentation shouldn't include
> >> crappy workaround hacks like the ones I've described above ].
> >>
> >>
> >> [1] https://www.qubes-os.org/doc/vm-interface/
> >> [2] https://www.xenproject.org/developers/teams/windows-pv-drivers.html
> >
> > @Evan
>
> Ivan :)
>
> > Thanks Evan! This really looks promising, I will go and try it out tomorrow
> > if I can scrap some free-time to try it out. I'll post here the moment I've
> > tried it, hopefully
Re: [qubes-devel] Are there currently anyone assigned to update Qubes-Windows-Tools?
On Sunday, February 4, 2018 at 6:00:15 PM UTC+1, Ivan Mitev wrote:
> > Also it seems like some functions "might (maybe)" work as intended, for
> > example I can copy files between VM's and Win7, on a Win7 that was
> > installed on Qubes 3.2., but backup restored on Qubes 4. Others seem like
> > they can do this too. Also it seems it's a common problem not to be
> > internet in the restored Q3.2-Win7, perhaps the code is different in
> > regards to how it ties networking with Qubes 4? I have no idea about the
> > rest of the mechanics from a users perspective though, and most certainly
> > not as a developer as I unfortunately don't have such skills, I wish I
> > could help more.
>
> I just spent a bit of time restoring my windows VM from 3.2, here are a
> few notes that might be helpful to work around some bugs that you're
> probably hitting too (I haven't filed any issues yet):
>
> - PVH/HVM: in the VM's settings gui, PVH is always displayed whatever
> the real pref value. -> use qvm-prefs vmname virt_mode to make sure
> you're really in HVM mode.
>
> - Networking: the PV network adapter was stuck at "Identifying" ;
> pinging an *ip* works but ping a host fails. tcpdump on sys-firewall
> shows that the requests were sent to the gateway's ip and were rejected.
> The reason seems to be that in R4.0 VMs are now using the exposed
> "/qubes-{primary,secondary}-dns" values, while in R3.2 the DNS server
> was the same as "/qubes-gateway" (see [1]). In my setup,
> "/qubes-{primary,secondary}-dns" are 10.139.1.{1,2} and /qubes-gateway
> is 10.137.0.6. DNS requests are rejected because they're sent to
> 10.137.0.6 instead of 10.139.1.{1,2}
>
> workaround 1-> manually set the DNS servers to
> /qubes-{primary,secondary}-dns ips. Ping and Internet Explorer worked,
> but the PV adapter was still suck at "identifying" and my Amazon Kindle
> for PC app complained about finding no network (it seems there's a
> windows "connectivity" API/flag that some apps use). However you will
> have to do this each time after boot since Qubes tools will reset the
> network settings.
>
> workaround 2-> in Program Files/Invisible.../Qubes.../bin/..., rename
> network-setup.exe to network-setup.exe.bkp to prevent Qubes tools from
> messing with your network settings, and manually set the VM's IP and DNS
> servers in the PV adapter network setting. Everything should then work
> OK, the only problem being that you'll have to make sure you keep your
> network settings synced (esp. the IP when you clone the VM).
>
> - Copying to/from the Win VM: works perfectly - you just have to type
> twice the destination VM (once in Windows, once in Qubes/dom0), since
> Qubes Tools aren't updated to reflect R4.0 new "way".
>
>
> note: before finding what was causing the connectivity problem I tried
> to update xen's windows PV drivers [2] but it broke the VM (ie. it
> wasn't starting anymore) so I had to restore it again. Anyway IIRC R3.2
> Qubes Tool's drivers were at the same version as Xen's (8.2), so no need
> to fiddle with this.
>
> I was thinking about posting those steps on qubes-users@ but I don't
> feel I had done enough testing on my VM yet. I see you're quite active
> on qubes-users so feel free to redact/post some of my remarks if you
> think they'll help.
>
> [ an unofficial wiki would be a helpful bridge between the MLs and
> Qubes' official documentation: it's difficult to skim through all the
> related ML posts and IMO Qubes' official documentation shouldn't include
> crappy workaround hacks like the ones I've described above ].
>
>
> [1] https://www.qubes-os.org/doc/vm-interface/
> [2] https://www.xenproject.org/developers/teams/windows-pv-drivers.html
@Evan
Thanks Evan! This really looks promising, I will go and try it out tomorrow if
I can scrap some free-time to try it out. I'll post here the moment I've tried
it, hopefully I can get the internet working.
It's also very ensuring to hear that it's safe to copy files between Win7 and
other VM's. I was a bit stressed out over this one due to worry of bit-rot.
I'll get back to you when I've tried this out, thanks!
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/dff8fb8f-fb54-4b60-8ca3-4ad15d0744ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Are there currently anyone assigned to update Qubes-Windows-Tools?
On Sunday, February 4, 2018 at 1:57:26 PM UTC+1, Elias Mårtenson wrote: > On Sunday, 4 February 2018 03:09:41 UTC+8, Yuraeitha wrote: > > > Also it seems like some functions "might (maybe)" work as intended, for > > example > > I can copy files between VM's and Win7, on a Win7 that was installed on > > Qubes > > 3.2., but backup restored on Qubes 4. Others seem like they can do this > > too. > > Also it seems it's a common problem not to be internet in the restored Q3.2- > > Win7, perhaps the code is different in regards to how it ties networking > > with > > Qubes 4? I have no idea about the rest of the mechanics from a users > > perspective though, and most certainly not as a developer as I > > unfortunately > > don't have such skills, I wish I could help more. > > I have tried this, and in my case, the win7 VM crashed hard (with the VM > immediately disappearing with not error message to be seen) after a few > seconds > of use. > > While it was running, things worked fine (i.e. fast graphics updates etc) > which > leads me to believe that the graphics drivers are fine. It does seem to die > as > soon as I open the Explorer window, which somewhat narrows down the set of > potential causes. @Elias I think I encountered this issue too, without error logs it's hard to be sure though, but by the description it sounds a lot like it. Another user in another Qubes 4 Win7 thread somewhere in Qubes-users mail-list, suggested to reduce the page-file for Windows SWAP inside the Windows VM. It worked for him, and when I tried it out, it worked for me too. It's possible this is what you encounter, try reduce the Windows page-file and see if it works? Also if not reducing the page-file, more giving the VM more RAM works too, but it's a lot of wasting resources, especially on low RAM hardware. For example I have to give Win7 4GB RAM when I did not change the page-file in Windows. When it has 3GB or 3.5GB, then it crashes like your description. Once the page file has been reduced, counter-intuitively the RAM can now be 2.5GB without any crash so far. It seems a bit odd since the page-file SWAP should only be related to the drive space, but the relation between host VM allocated RAM, and guest drive SWAP page-file, somehow, indeed seems to be related to each others... I lack the understanding ,but it seems very counter-intuitive to me, yet it still worked. Hopefully this can fix your crash issues. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/200413aa-03c0-41c2-9a11-743af2e274d6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Are there currently anyone assigned to update Qubes-Windows-Tools?
On Saturday, February 3, 2018 at 2:16:15 PM UTC+1, Elias Mårtenson wrote: > On Saturday, 3 February 2018 12:06:20 UTC+8, Andrew David Wong wrote: > > > As far as I know, Qubes Windows Tools continues to remain on > > indefinite hold. We welcome anyone from the community with the > > requisite skills to take over development (or just pitch in here and > > there). > > I wanted to be that person, and I did take an initial look. However, being an > experienced Unix developer was not much help in figuring out the issues with > the Windows tools. > > Is there some source of information that helps explain what the problem could > be, and where to start looking for it? > > Regards, > Elias @Elias It would be amazing if you can get the needed information and have a second look at it. I'm only speculating here, but could it be possible that the code is more or less the way it's supposed to be, but has just not been tested, verified, and then distributed on Qubes 4? If the precedent for release requirements is the expectation of quality before release, then perhaps the hindrance is just testing and verifying if it works? Also it seems like some functions "might (maybe)" work as intended, for example I can copy files between VM's and Win7, on a Win7 that was installed on Qubes 3.2., but backup restored on Qubes 4. Others seem like they can do this too. Also it seems it's a common problem not to be internet in the restored Q3.2-Win7, perhaps the code is different in regards to how it ties networking with Qubes 4? I have no idea about the rest of the mechanics from a users perspective though, and most certainly not as a developer as I unfortunately don't have such skills, I wish I could help more. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/fac5da5a-a17b-444d-bc6a-7e24956954be%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Are there currently anyone assigned to update Qubes-Windows-Tools?
On Saturday, February 3, 2018 at 5:06:20 AM UTC+1, Andrew David Wong wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 2018-02-02 17:19, Yuraeitha wrote: > > > > It seems omeg who has been maintaining Qubes-Windows-Tools the last > > few years, has gone inactive > > He is instead working on other projects for ITL's corporate clients, > so "inactive" is not quite accurate. > > > https://github.com/QubesOS/qubes-installer-qubes-os-windows-tools > > and thus far, it looks like no one else has picked up the project. > > > > Correct. > > > If it is not planned to be done any time soon, then that's alright, > > I can live with that. I'm already immensely grateful for everything > > the Qubes team has done. But it's not so easy for everyone though, > > some people are more heavily reliant on Windows than others for > > certain applications. > > > > This post is NOT a complaint or anything of the sorts, but instead > > a question to settle expectations on the correct path, instead of > > looking every day for a new update, which can be a lot of > > uncertainty or for some people even anxiety and frustrations, when > > on Qubes 4 without a means to get Windows 7 installed. Essentially > > people who need Windows and would love to get Qubes 4, are caught > > in-between without any idea when or even if Windows 7 will be > > supported anytime in the near-term future. > > > > In other words, just knowing it won't be anytime soon is in a way > > also very good news, because it puts expectations in the right > > place instead of uncertainty. Any such news-update on what is going > > on with it and what to expect, would be appreciated. > > > > As far as I know, Qubes Windows Tools continues to remain on > indefinite hold. We welcome anyone from the community with the > requisite skills to take over development (or just pitch in here and > there). > > > Also, I'm not entirely sure regarding the code itself, but it > > should be somewhat close to Qubes 4 in the current > > Qubes-Windows-Tools? For example the Qubes 3.2. Win7 restored from > > backup in Qubes 4, seems to more or less work, somewhat smoothly, > > but not perfect. If so, maybe someone else can help with bringing > > Qubes-Windos-Tools to Qubes 4? Unfortunately I have no coding > > skills of this sort though, otherwise I'd give it a shot. > > > > Sorry, I don't know. > > - -- > Andrew David Wong (Axon) > Community Manager, Qubes OS > https://www.qubes-os.org > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlp1NS0ACgkQ203TvDlQ > MDCZYw//X/AlrUieQTF4ebMSab60xahi5erwpQc87Yzvb7WLLYBEnmY19d60M8IT > oOr6p3zroDc+VvwBW4vIcp4S7RUNIDbIyppulW+6eiFunQK8kZGpks+RKfntxwEq > Z8MCFeVNCedn43AGc6DCOLFrSsQVUR0LKVGIcI/Lhoe60zdvoMofnlF2hHRzWqvb > 9UYuu/Kiqyy8RVyNq1LSNJ4/5jIIFDoxk12Wngc3s22OU5/u6I2vlnUHHwDC/X6n > kbWSa8ltdKIOpglWxf34G7G60kdQVLfqw88mFzGUMk02EOeGkErMuG39wzCCGWyA > 0Yp+KWeUaTH7mzUVTHR4G0uuWlFx7IaXUWOSJVmuSjItCQ4s7qbZ8A78ajN1aLYd > JhhVnM8jzDF8zkrAd6Ez+zRVa9im/m1puck3uNb8Ou6VD0FnRWowl6iz0ijRhXsF > A6qgr4jiGqqp3OSvxActu32KbW2ogxrDQThztcJgY1DuhDF/Y6YBHRI9I92udQ6r > +A5OKoIKe3cskntkF5lrSawqVtyD+lxuT00gwwJrolj1ixdHt8ufyezvJxDYZJac > UIu4y95w4H28YoxCY5bmoMIB5ncl4kskKs7qFpNbVHs4d8GsW1NcT2fxNzslGtsV > D7muRf9n/gX3Ui5wNwwjP0gVMD6RrsY4wRdt4Jzk87VVdJIEiXM= > =LLLN > -END PGP SIGNATURE- Thanks Andrew, this was exactly what I was looking for, much appreciated. I'm gonna settle in for a plan B as listed below, although it looks really interesting if Elias will be looking into it. Maybe Marek or someone else with insight into the code can help a little bit to get started? But for the time being, I might try install Qubes 3.2. as a plan B to create some temporary unlicensed clean Win7 Qubes backup's, and see if I can transfer them to various of other Qubes 4 systems. This is mostly needed for my friends though, and I still need to figure out if this is allowed within the use-cases of the Windows 7 license or not, they will use their own licenses. This method is a bit cumberstone if the code inside the Win7 installed on Qubes 3.2. is buggy and creates unreliable issues, like unreliable transfer of data integrity. Hopefully nothing bad will happen. Also need different types of Windows 7 copies for different types of licenses, which is a bit problematic, but not impossible. For now this temporary plan B, this might be a work around to get a new clean Win7 on multiple of different Qubes 4 systems, although a bit cumberstone, and uncertain possibility of data integrity risk. -- You received this message because you are subscribed to the Goo
[qubes-devel] Are there currently anyone assigned to update Qubes-Windows-Tools?
It seems omeg who has been maintaining Qubes-Windows-Tools the last few years, has gone inactive https://github.com/QubesOS/qubes-installer-qubes-os-windows-tools and thus far, it looks like no one else has picked up the project. If it is not planned to be done any time soon, then that's alright, I can live with that. I'm already immensely grateful for everything the Qubes team has done. But it's not so easy for everyone though, some people are more heavily reliant on Windows than others for certain applications. This post is NOT a complaint or anything of the sorts, but instead a question to settle expectations on the correct path, instead of looking every day for a new update, which can be a lot of uncertainty or for some people even anxiety and frustrations, when on Qubes 4 without a means to get Windows 7 installed. Essentially people who need Windows and would love to get Qubes 4, are caught in-between without any idea when or even if Windows 7 will be supported anytime in the near-term future. In other words, just knowing it won't be anytime soon is in a way also very good news, because it puts expectations in the right place instead of uncertainty. Any such news-update on what is going on with it and what to expect, would be appreciated. Also, I'm not entirely sure regarding the code itself, but it should be somewhat close to Qubes 4 in the current Qubes-Windows-Tools? For example the Qubes 3.2. Win7 restored from backup in Qubes 4, seems to more or less work, somewhat smoothly, but not perfect. If so, maybe someone else can help with bringing Qubes-Windos-Tools to Qubes 4? Unfortunately I have no coding skills of this sort though, otherwise I'd give it a shot. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/5bb1700e-c818-4fc5-9e16-8ab09bf7e677%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] storage domain in qubes.
On Saturday, November 11, 2017 at 8:25:37 PM UTC, Jean-Philippe Ouellet wrote: > > On Fri, Nov 10, 2017 at 4:44 PM, Yuraeitha <yura...@gmail.com > > wrote: > > On Friday, November 10, 2017 at 9:04:38 PM UTC, Jean-Philippe Ouellet > wrote: > >> On Fri, Nov 10, 2017 at 3:56 PM, Yuraeitha <yura...@gmail.com> wrote: > >> > On Friday, November 10, 2017 at 8:09:30 PM UTC, Jean-Philippe Ouellet > >> > wrote: > >> >> On Fri, Nov 10, 2017 at 9:22 AM, Yuraeitha <yura...@gmail.com> > wrote: > >> >> > On Friday, November 10, 2017 at 11:38:47 AM UTC, blacklight wrote: > >> >> >>> As long as that is the case, it's not worth the complexity IMO. > >> >> >>> Note > >> >> >>> however that the storage subsystem API for R4 has still been > >> >> >>> designed > >> >> >>> to be compatible with moving storage out of dom0 in the future. > >> >> >> > >> >> >> > >> >> >> In https://github.com/QubesOS/qubes-issues/issues/1293 @Marek > >> >> >> mentions > >> >> >> that it would protect against malicious disk firmware, since this > >> >> >> could > >> >> >> own > >> >> >> Dom0 via an DMA attack, is Qubes currently still vulnerable > against > >> >> >> this > >> >> >> type of an attack? > >> >> > >> >> Yes, that's correct. > >> >> > >> >> > You could install a template with a microkernel and slim it down > so > >> >> > it > >> >> > barely has nothing installed. For example a minimal template. Then > >> >> > pass > >> >> > through your entire USB controller, assuming you got more than one > >> >> > controller. Typically, many systems have at least two controllers, > >> >> > even > >> >> > laptops, but many also only have only one USB controller. Most > modern > >> >> > day > >> >> > motherboards have minimum two controllers by default, without > adding > >> >> > extra > >> >> > PCI USB cards with one or more USB controllers. > >> >> > > >> >> > Basically, if you pass the entire USB controller, then it > shouldn't > >> >> > be > >> >> > able > >> >> > to reach dom0 through firmware DMA attacks. But I'm no expert, > it's > >> >> > just > >> >> > my > >> >> > understanding of it. > >> >> > > >> >> > Furthermore, if the USB controller / Card has no PCI reset, then > >> >> > malware > >> >> > may > >> >> > survive when switching between domains. So it may be a good idea > to > >> >> > keep > >> >> > this USB controller strictly for that domain only and never move > it, > >> >> > if > >> >> > it > >> >> > has no PCI reset feature. > >> >> > > >> >> > BadUSB? I guess this one can't be avoided even with PCI reset.. at > >> >> > which > >> >> > case, again, keep the same USB controller on the same domain, > forever > >> >> > and > >> >> > ever, and you should be okay. Remember to block it in the USB > >> >> > controller > >> >> > from the booting process, as well as in dom0 once booted, so it > never > >> >> > touches anything outside the domain, ever. > >> >> > > >> >> > I'm not sure if each USB controller has their own firmware or if > they > >> >> > share > >> >> > firmware with other USB controllers, i.e. on the motherboard or on > >> >> > the > >> >> > same > >> >> > PCI card with multiple USB controllers. Someone who knows more > will > >> >> > have > >> >> > to > >> >> > answer that one, if they are separate or not on the firmware > level. > >> >> > >> >> The purpose of an untrusted storage domain is not to guard against > USB > >> >> devices - those are already isolated via sys-usb. > >> >> > >&
Re: [qubes-devel] qvm-open-in-vm (Q4.0rc2)
On Tuesday, November 7, 2017 at 7:27:48 PM UTC, Marek Marczykowski-Górecki wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Tue, Nov 07, 2017 at 04:33:27AM -0800, Frédéric Pierret (fepitre) > wrote: > > Hi, > > I'm experiencing something strange in Qubes 4.0rc2: when I try to > > qvm-open-in-vm several images in the same vm it seems to does not work. > For > > e.g. from work appvm: > > > > qvm-open-in-vm '$default' appel.jpg (then I choose e.g. personal), It > opens > > great and I keep the image open in personal, and then I do the same with > > appel2.jpg but the image does not appear and does not exist in > /tmp/work-* > > > > Doing this with two differents targets VM or with e.g. PDF or TXT works > > great. Can someone test it please (just before trying to eventually > deeply > > debug...)? > > I can confirm this behavior. (I guess) it is because the opening the > second file in fact open it in the same viewer/editor instance. And that > command exit immediately after sending a message to main (first) > instance. So qvm-open-in-vm (in fact, /usr/lib/qubes/vm-file-editor) > thinks you already closed the file and remove it from the target VM. > This is very similar to more general issue we have with gnome-terminal > in DispVM - the command you use to open app/file do not wait until you > close app/file. > > - -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJaAgksAAoJENuP0xzK19csi/AH+gOZ1aUZVuLv6cKAjNBSckdK > o7hwZBhdwwyeeBJ3NYdl0R1VDXWOSK+RMdh5jPXnXVdJHjJb2CXJ2nwrofWwP8C0 > Kv4O3scER6Iq7iFOns/0C9pvXAVs9FI0T9rZ98kGy9isIugDDIJJR2ie7hvKBhg1 > BeSXLFIBNPv3TERRxOqiZpOkWh7+YmDZWsIpTX1nldsEZDzWxvkbKbOK+fg7RhY1 > AkBJFjNTbNPIhwIqXVBIBBB7Ygu4J0TNP6k7f9eWYqCJrGgc4ykAglK/UhUf4Cwx > 4lyhRWveNt4td5bGBOCslnIQNQYdztViIN/ubxAcQMcIk4kaXHaqR19zc1MxNEE= > =M00S > -END PGP SIGNATURE- > Marek, I possibly found a way to reproduce some of the issues here regarding the Qubes tools issues in the templates/AppVM's that is causing haywire on some Qubes 4 systems out there (and a way to solve it too). It's a user mistake, and quite frankly, quite an embarrassing one at that. Nonetheless, perhaps it might be a good idea to help make it harder for other users to repeat the same mistake, if feasible or desired of course. It's triggered by restoring Qubes 3.2. templates in Qubes 4 (face-palm moment, I know), which without knowing the code I'm guessing is different between the Qubes 3.2. and Qubes 4 releases. I did not think much of it at the time, and it was easier to just restore everything, like go take a break or sleep while it works, instead of typing -x AppVM -x Template, etc. exceptions into the command line. I mean, if the computing time is irrelevant and you got plenty of disk space, it may be tempting to just restore it all while you go and do something else. Perhaps it'd be good to have something that stops the restoration of Qubes 3.2. templates, or a message that warns people in place before it goes out to people that might make same user mistake. Somewhere down the line, one of the old Fedora templates from my 3.2. system was not deleted after restoration, and same user mistake happened on more than one machine. After I re-linked all my AppVM's over to Qubes 4 fedora templates, it has for now worked pretty smoothly for several hours now. I'm not sure if having to delete the old template was part of the solution, or if it made any difference, but I deleted it right away before testing that, perhaps I should have, but you probably know if it matters or not. Creating shortcut issues in the Xfce4 menu is still for some AppVM's broken, but I'm suspecting creating a new AppVM and manually transfer userdata over might be able to fix that (Will try when I have the time). Seemingly old backup AppVM's are the ones with broken shortcuts? I haven't had time to test this, but it appears like that. Also, Chris Laprise over at https://groups.google.com/forum/#!topic/qubes-users/Dxe8-0vaIuk found an easy way to solve the re-install of debian-8 issue. But this did not solve the qvm-run or qvm-open-in-vm issues for debian, at least not for my system, and possibly maybe others out there. In short. - Deleting 3.2. fedora templates and re-linking to Qubes 4 fedora templates only, appears to fix the qvm-run / qvm-open-in-vm issues in fedora templates. - Re-installing Debian works with provided solution in the link from Chris Laprise posts over at the link above, but qvm-run or qvm-open-in-vm are still broken in debian. - Some systems have a working debian template, while other systems do not. Is this hardware specific issue perhaps? Random? or different setting during Qubes 4 install maybe? -- You received this message
Re: [qubes-devel] storage domain in qubes.
On Friday, November 10, 2017 at 9:04:38 PM UTC, Jean-Philippe Ouellet wrote: > > On Fri, Nov 10, 2017 at 3:56 PM, Yuraeitha <yura...@gmail.com > > wrote: > > On Friday, November 10, 2017 at 8:09:30 PM UTC, Jean-Philippe Ouellet > wrote: > >> On Fri, Nov 10, 2017 at 9:22 AM, Yuraeitha <yura...@gmail.com> wrote: > >> > On Friday, November 10, 2017 at 11:38:47 AM UTC, blacklight wrote: > >> >>> As long as that is the case, it's not worth the complexity IMO. > Note > >> >>> however that the storage subsystem API for R4 has still been > designed > >> >>> to be compatible with moving storage out of dom0 in the future. > >> >> > >> >> > >> >> In https://github.com/QubesOS/qubes-issues/issues/1293 @Marek > mentions > >> >> that it would protect against malicious disk firmware, since this > could > >> >> own > >> >> Dom0 via an DMA attack, is Qubes currently still vulnerable against > >> >> this > >> >> type of an attack? > >> > >> Yes, that's correct. > >> > >> > You could install a template with a microkernel and slim it down so > it > >> > barely has nothing installed. For example a minimal template. Then > pass > >> > through your entire USB controller, assuming you got more than one > >> > controller. Typically, many systems have at least two controllers, > even > >> > laptops, but many also only have only one USB controller. Most modern > >> > day > >> > motherboards have minimum two controllers by default, without adding > >> > extra > >> > PCI USB cards with one or more USB controllers. > >> > > >> > Basically, if you pass the entire USB controller, then it shouldn't > be > >> > able > >> > to reach dom0 through firmware DMA attacks. But I'm no expert, it's > just > >> > my > >> > understanding of it. > >> > > >> > Furthermore, if the USB controller / Card has no PCI reset, then > malware > >> > may > >> > survive when switching between domains. So it may be a good idea to > keep > >> > this USB controller strictly for that domain only and never move it, > if > >> > it > >> > has no PCI reset feature. > >> > > >> > BadUSB? I guess this one can't be avoided even with PCI reset.. at > which > >> > case, again, keep the same USB controller on the same domain, forever > >> > and > >> > ever, and you should be okay. Remember to block it in the USB > controller > >> > from the booting process, as well as in dom0 once booted, so it never > >> > touches anything outside the domain, ever. > >> > > >> > I'm not sure if each USB controller has their own firmware or if they > >> > share > >> > firmware with other USB controllers, i.e. on the motherboard or on > the > >> > same > >> > PCI card with multiple USB controllers. Someone who knows more will > have > >> > to > >> > answer that one, if they are separate or not on the firmware level. > >> > >> The purpose of an untrusted storage domain is not to guard against USB > >> devices - those are already isolated via sys-usb. > >> > >> The goal is to mitigate attacks coming from your internal disk (SSD) > >> controller or disk firmware, as well as potential attacks against the > >> storage layers used by Qubes (e.g LVM, etc.). > >> > >> These are orthogonal. > > > > > > > > oh, I had completely misunderstood, thanks for clarifying. > > > > But then, by that logic, all VM images should be lifted up into a VM, > and > > not only a storage VM. > > The idea of the storage domain *is* that it would handle all VM > images. You should read the architecture spec if you haven't already. > > > Even just once exposing the drive and it'd be risk an > > infected, I suppose, in ways similar to the BadUSB. Such security > > requirements, or hygiene practice if one may, certainly would ban any > > dual-booting with other operation systems. > > Hence why I said this being useful depends on a good trusted boot > scheme, which we do not yet have in widespread availability. > > > Still, this only solves online or threats from files and applications > from > > within the
Re: [qubes-devel] storage domain in qubes.
On Friday, November 10, 2017 at 8:09:30 PM UTC, Jean-Philippe Ouellet wrote: > > On Fri, Nov 10, 2017 at 9:22 AM, Yuraeitha <yura...@gmail.com > > wrote: > > On Friday, November 10, 2017 at 11:38:47 AM UTC, blacklight wrote: > >>> As long as that is the case, it's not worth the complexity IMO. Note > >>> however that the storage subsystem API for R4 has still been designed > >>> to be compatible with moving storage out of dom0 in the future. > >> > >> > >> In https://github.com/QubesOS/qubes-issues/issues/1293 @Marek > mentions > >> that it would protect against malicious disk firmware, since this could > own > >> Dom0 via an DMA attack, is Qubes currently still vulnerable against > this > >> type of an attack? > > Yes, that's correct. > > > You could install a template with a microkernel and slim it down so it > > barely has nothing installed. For example a minimal template. Then pass > > through your entire USB controller, assuming you got more than one > > controller. Typically, many systems have at least two controllers, even > > laptops, but many also only have only one USB controller. Most modern > day > > motherboards have minimum two controllers by default, without adding > extra > > PCI USB cards with one or more USB controllers. > > > > Basically, if you pass the entire USB controller, then it shouldn't be > able > > to reach dom0 through firmware DMA attacks. But I'm no expert, it's just > my > > understanding of it. > > > > Furthermore, if the USB controller / Card has no PCI reset, then malware > may > > survive when switching between domains. So it may be a good idea to keep > > this USB controller strictly for that domain only and never move it, if > it > > has no PCI reset feature. > > > > BadUSB? I guess this one can't be avoided even with PCI reset.. at which > > case, again, keep the same USB controller on the same domain, forever > and > > ever, and you should be okay. Remember to block it in the USB controller > > from the booting process, as well as in dom0 once booted, so it never > > touches anything outside the domain, ever. > > > > I'm not sure if each USB controller has their own firmware or if they > share > > firmware with other USB controllers, i.e. on the motherboard or on the > same > > PCI card with multiple USB controllers. Someone who knows more will have > to > > answer that one, if they are separate or not on the firmware level. > > The purpose of an untrusted storage domain is not to guard against USB > devices - those are already isolated via sys-usb. > > The goal is to mitigate attacks coming from your internal disk (SSD) > controller or disk firmware, as well as potential attacks against the > storage layers used by Qubes (e.g LVM, etc.). > > These are orthogonal. > oh, I had completely misunderstood, thanks for clarifying. But then, by that logic, all VM images should be lifted up into a VM, and not only a storage VM. Even just once exposing the drive and it'd be risk an infected, I suppose, in ways similar to the BadUSB. Such security requirements, or hygiene practice if one may, certainly would ban any dual-booting with other operation systems. Still, this only solves online or threats from files and applications from within the operation system itself. It does supposedly not solve an attacker to shutdown the Laptop/PC, and then inserting an infected firmware attack purposed USB before Qubes even boots, and then infecting the firmware before encryption levels? I'm not sure if that is feasible. But a stateless hardware as suggested by Joanna, start to sound even more appealing given all the hassle this would bring to secure against, and one cannot go all the way, unless its stateless. If I understood it correctly. I mean, an encrypted drive, still should still have its firmware exposed right? Thereby stateless drive is the only known approach to properly work all the way? -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/0e11164a-b5f9-45d5-a235-8814af3b3891%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] qvm-open-in-vm (Q4.0rc2)
On Wednesday, November 8, 2017 at 8:12:14 AM UTC, Frédéric Pierret (fepitre) wrote: > > Thank you for your feedback > > Le mercredi 8 novembre 2017 06:20:12 UTC+1, Yuraeitha a écrit : >> >> Does that mean the qvm-run issues run on freshly started AppVMs and >> Templates, isn't related to the original topic issue with qvm-open-in-vm? >> >> All the VM domains start just fine, and even if shutting down and >> starting again, it rarely fixes the issue, some never even work despite >> restart. It's also really, really weird and puzzling that this only applies >> to some Templates and AppVMs. >> >> My apologies if this isn't related to the original topic, at which case >> my post was off-topic. But if there is any chance its related information, >> then I'll post it here. >> > No problem, for me it is related. I also experience "random" behavior and > such problems you described in your previous post. So there is something to > dig in. > >> >> I've just tried running Qubes 4 on my other hardware system, which seems >> not to have this issue. Perhaps it's hardware specific or software >> condition specific. Either way, just attempting to add information to the >> original post, not to hijack it. >> >> >> On Tuesday, November 7, 2017 at 7:27:48 PM UTC, Marek >> Marczykowski-Górecki wrote: >>> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA256 >>> >>> On Tue, Nov 07, 2017 at 04:33:27AM -0800, Frédéric Pierret (fepitre) >>> wrote: >>> > Hi, >>> > I'm experiencing something strange in Qubes 4.0rc2: when I try to >>> > qvm-open-in-vm several images in the same vm it seems to does not >>> work. For >>> > e.g. from work appvm: >>> > >>> > qvm-open-in-vm '$default' appel.jpg (then I choose e.g. personal), It >>> opens >>> > great and I keep the image open in personal, and then I do the same >>> with >>> > appel2.jpg but the image does not appear and does not exist in >>> /tmp/work-* >>> > >>> > Doing this with two differents targets VM or with e.g. PDF or TXT >>> works >>> > great. Can someone test it please (just before trying to eventually >>> deeply >>> > debug...)? >>> >>> I can confirm this behavior. (I guess) it is because the opening the >>> second file in fact open it in the same viewer/editor instance. And that >>> command exit immediately after sending a message to main (first) >>> instance. So qvm-open-in-vm (in fact, /usr/lib/qubes/vm-file-editor) >>> thinks you already closed the file and remove it from the target VM. >>> This is very similar to more general issue we have with gnome-terminal >>> in DispVM - the command you use to open app/file do not wait until you >>> close app/file. >>> >>> - -- >>> Best Regards, >>> Marek Marczykowski-Górecki >>> Invisible Things Lab >>> A: Because it messes up the order in which people normally read text. >>> Q: Why is top-posting such a bad thing? >>> -BEGIN PGP SIGNATURE- >>> Version: GnuPG v2 >>> >>> iQEcBAEBCAAGBQJaAgksAAoJENuP0xzK19csi/AH+gOZ1aUZVuLv6cKAjNBSckdK >>> o7hwZBhdwwyeeBJ3NYdl0R1VDXWOSK+RMdh5jPXnXVdJHjJb2CXJ2nwrofWwP8C0 >>> Kv4O3scER6Iq7iFOns/0C9pvXAVs9FI0T9rZ98kGy9isIugDDIJJR2ie7hvKBhg1 >>> BeSXLFIBNPv3TERRxOqiZpOkWh7+YmDZWsIpTX1nldsEZDzWxvkbKbOK+fg7RhY1 >>> AkBJFjNTbNPIhwIqXVBIBBB7Ygu4J0TNP6k7f9eWYqCJrGgc4ykAglK/UhUf4Cwx >>> 4lyhRWveNt4td5bGBOCslnIQNQYdztViIN/ubxAcQMcIk4kaXHaqR19zc1MxNEE= >>> =M00S >>> -END PGP SIGNATURE- >>> >> > It's good to know I'm not alone with this issue, although at the same time I wish it was only my machine so no one else had to experience this stressing issue. I feel like its frankly the most annoying Qubes 4 bug to date, nothing else I experienced is as annoying as this one >.< It's like putting a big yummy carrot in front of you on a stick, it's allmst working, but nope, not getting it. Frustrating when that close after hours of trying to fix it, and it fails at the last step, especially, and indeed, given its random nature, haha No disrespect meant to the developers, I'm aware this is a big job, a lot of fundamental code was changed between 3.2 and 4, and that Qubes 4 is still in testing phase as well. Obviously bugs like these are natural to happen, and I'm definitely not complaining (if anything, Qubes 4 is an amazing job done), it's just a natural to expect, but frustrating kind of bug to encounter. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/d9510db9-e2f8-445c-9911-d9086467c497%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: python security announcements
On Monday, November 6, 2017 at 2:41:41 AM UTC, Jean-Philippe Ouellet wrote: > > To any who may care, I've opened an issue in the Python bug tracker in > the hopes that we might have a guaranteed way of being made aware of > security issues in Python before Qubes users get owned by them. > > See here: https://bugs.python.org/issue31953 > > My hope is that a guarantee of receiving such news means Qubes has a > higher change of making a timely QSB and "update dom0 ASAP!" > announcement if the time ever comes. Many of us follow news in the > security world anyway and might hear of such a potential issue > regardless, but still... > > Regards, > Jean-Philippe > Please correct me if I'm wrong, but python security issues should only apply for the Qubes Admin, right? and the Qubes Admin only has internet access, if you opt-in to it, correct? These things are good to know as well, and it doesn't seem to be documented anywhere easy to find yet, albeit I've seen it briefly discussed here and there, but nothing conclusive. I do not like the idea of having extra attack surface to worry about when I personally do not need the Qubes Admin on my personal machine. Albeit I do think Qubes Admin is an awesome addition to Qubes, as long as it's possible to opt-in or opt-out, and all the security issues that follows goes with it in or out accordingly. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/5804fb53-7522-4a4a-84dc-93b85dc5c0fc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] storage domain in qubes.
On Friday, November 10, 2017 at 11:38:47 AM UTC, blacklight wrote: > > > > >> >> As long as that is the case, it's not worth the complexity IMO. Note >> however that the storage subsystem API for R4 has still been designed >> to be compatible with moving storage out of dom0 in the future. >> > > In https://github.com/QubesOS/qubes-issues/issues/1293 @Marek mentions > that it would protect against malicious disk firmware, since this could own > Dom0 via an DMA attack, is Qubes currently still vulnerable against this > type of an attack? > You could install a template with a microkernel and slim it down so it barely has nothing installed. For example a minimal template. Then pass through your entire USB controller, assuming you got more than one controller. Typically, many systems have at least two controllers, even laptops, but many also only have only one USB controller. Most modern day motherboards have minimum two controllers by default, without adding extra PCI USB cards with one or more USB controllers. Basically, if you pass the entire USB controller, then it shouldn't be able to reach dom0 through firmware DMA attacks. But I'm no expert, it's just my understanding of it. Furthermore, if the USB controller / Card has no PCI reset, then malware may survive when switching between domains. So it may be a good idea to keep this USB controller strictly for that domain only and never move it, if it has no PCI reset feature. BadUSB? I guess this one can't be avoided even with PCI reset.. at which case, again, keep the same USB controller on the same domain, forever and ever, and you should be okay. Remember to block it in the USB controller from the booting process, as well as in dom0 once booted, so it never touches anything outside the domain, ever. I'm not sure if each USB controller has their own firmware or if they share firmware with other USB controllers, i.e. on the motherboard or on the same PCI card with multiple USB controllers. Someone who knows more will have to answer that one, if they are separate or not on the firmware level. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/428e62a5-7ea4-4ccc-a26f-5b1f69fbc6ed%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] qvm-open-in-vm (Q4.0rc2)
On Tuesday, November 7, 2017 at 7:27:48 PM UTC, Marek Marczykowski-Górecki wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Tue, Nov 07, 2017 at 04:33:27AM -0800, Frédéric Pierret (fepitre) > wrote: > > Hi, > > I'm experiencing something strange in Qubes 4.0rc2: when I try to > > qvm-open-in-vm several images in the same vm it seems to does not work. > For > > e.g. from work appvm: > > > > qvm-open-in-vm '$default' appel.jpg (then I choose e.g. personal), It > opens > > great and I keep the image open in personal, and then I do the same with > > appel2.jpg but the image does not appear and does not exist in > /tmp/work-* > > > > Doing this with two differents targets VM or with e.g. PDF or TXT works > > great. Can someone test it please (just before trying to eventually > deeply > > debug...)? > > I can confirm this behavior. (I guess) it is because the opening the > second file in fact open it in the same viewer/editor instance. And that > command exit immediately after sending a message to main (first) > instance. So qvm-open-in-vm (in fact, /usr/lib/qubes/vm-file-editor) > thinks you already closed the file and remove it from the target VM. > This is very similar to more general issue we have with gnome-terminal > in DispVM - the command you use to open app/file do not wait until you > close app/file. > > - -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJaAgksAAoJENuP0xzK19csi/AH+gOZ1aUZVuLv6cKAjNBSckdK > o7hwZBhdwwyeeBJ3NYdl0R1VDXWOSK+RMdh5jPXnXVdJHjJb2CXJ2nwrofWwP8C0 > Kv4O3scER6Iq7iFOns/0C9pvXAVs9FI0T9rZ98kGy9isIugDDIJJR2ie7hvKBhg1 > BeSXLFIBNPv3TERRxOqiZpOkWh7+YmDZWsIpTX1nldsEZDzWxvkbKbOK+fg7RhY1 > AkBJFjNTbNPIhwIqXVBIBBB7Ygu4J0TNP6k7f9eWYqCJrGgc4ykAglK/UhUf4Cwx > 4lyhRWveNt4td5bGBOCslnIQNQYdztViIN/ubxAcQMcIk4kaXHaqR19zc1MxNEE= > =M00S > -END PGP SIGNATURE- > I spoke too soon, it's not fixed on the Qubes 4 install on the second hardware machine. Again, this is just adding information to the original post, I'm not seeking a solution in this thread. Rather, everything is still working (which is a big improvement to the first machine in my first post with similar but much more aggravating version of the issue on the first Q4 machine), but eventually stops working too on the second Q4 machine after a shutdown or two of the same AppVM, similar to what you described, yet slightly different too. What is different however, this is on entire VM domain level and not app/file level inside a VM (macro vs. micro, yet similar issue it seems). Both the Qubes widget, 'xl list' rapport that the VM domain has shutdown, but if entering the VM Settings, it says in the device menu for example, that the VM still has not shutdown. Basically, Qubes thinks the VM has shutdown, but it doesn't seem to have been, not properly at least. No crash either, it was shutdown normally when it was running. Only quick fix to this, seems to be restarting Qubes itself altogether, and every non-working AppVM can start again. Isn't all this possibly related? Maybe there is something deeper going on? -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/04014ba1-6018-4a79-92ec-6c51d3d75e49%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] qvm-open-in-vm (Q4.0rc2)
Does that mean the qvm-run issues run on freshly started AppVMs and Templates, isn't related to the original topic issue with qvm-open-in-vm? All the VM domains start just fine, and even if shutting down and starting again, it rarely fixes the issue, some never even work despite restart. It's also really, really weird and puzzling that this only applies to some Templates and AppVMs. My apologies if this isn't related to the original topic, at which case my post was off-topic. But if there is any chance its related information, then I'll post it here. I've just tried running Qubes 4 on my other hardware system, which seems not to have this issue. Perhaps it's hardware specific or software condition specific. Either way, just attempting to add information to the original post, not to hijack it. On Tuesday, November 7, 2017 at 7:27:48 PM UTC, Marek Marczykowski-Górecki wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Tue, Nov 07, 2017 at 04:33:27AM -0800, Frédéric Pierret (fepitre) > wrote: > > Hi, > > I'm experiencing something strange in Qubes 4.0rc2: when I try to > > qvm-open-in-vm several images in the same vm it seems to does not work. > For > > e.g. from work appvm: > > > > qvm-open-in-vm '$default' appel.jpg (then I choose e.g. personal), It > opens > > great and I keep the image open in personal, and then I do the same with > > appel2.jpg but the image does not appear and does not exist in > /tmp/work-* > > > > Doing this with two differents targets VM or with e.g. PDF or TXT works > > great. Can someone test it please (just before trying to eventually > deeply > > debug...)? > > I can confirm this behavior. (I guess) it is because the opening the > second file in fact open it in the same viewer/editor instance. And that > command exit immediately after sending a message to main (first) > instance. So qvm-open-in-vm (in fact, /usr/lib/qubes/vm-file-editor) > thinks you already closed the file and remove it from the target VM. > This is very similar to more general issue we have with gnome-terminal > in DispVM - the command you use to open app/file do not wait until you > close app/file. > > - -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJaAgksAAoJENuP0xzK19csi/AH+gOZ1aUZVuLv6cKAjNBSckdK > o7hwZBhdwwyeeBJ3NYdl0R1VDXWOSK+RMdh5jPXnXVdJHjJb2CXJ2nwrofWwP8C0 > Kv4O3scER6Iq7iFOns/0C9pvXAVs9FI0T9rZ98kGy9isIugDDIJJR2ie7hvKBhg1 > BeSXLFIBNPv3TERRxOqiZpOkWh7+YmDZWsIpTX1nldsEZDzWxvkbKbOK+fg7RhY1 > AkBJFjNTbNPIhwIqXVBIBBB7Ygu4J0TNP6k7f9eWYqCJrGgc4ykAglK/UhUf4Cwx > 4lyhRWveNt4td5bGBOCslnIQNQYdztViIN/ubxAcQMcIk4kaXHaqR19zc1MxNEE= > =M00S > -END PGP SIGNATURE- > -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/e9eb3a1f-4396-462c-9ef5-d5db25be0ce0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: Qubes R3.2 - Severe graphics issues/glitches ? (HCL Report included)
Be very careful when updating untested kernels unless, you should have the ability to recover in case it goes wrong, i.e. switching back updates and switching back to older kernels, should it happen to fail. At the very minimum backup everything before you proceed. Beyond that, yes upgrading the kernel might certainly fix it. It's most likely an issue in the templates kernel or it's associated driver modules, upgrading the kernel would potentially upgrade your drivers and modules. Upgrading the Qubes kernel, also upgrades your template kernels. The below here is a long shot, but here is something I'd try my self before trying to fix the kernel, if I were in your situation. It's safe, as long as you make the proper precautions and don't experiment on something you don't want to loose. Also is it mostly after standby, such as suspend or hibernate, or is always after these states? Knowing this will make it easier to verify if the solution works or not. It sounds to me, without knowing with any certainty, like some kernel modules did not close or start up properly before or after suspend/hibernate. You can typically avoid the issue by making the modules forced to shutdown before the system goes to standby. The driver or module, whichever is causing this, seems to work, but breaks when the VM is put into sleep mode during Qubes suspend or hibernate. Right? I've only done with with Wi-Fi and other similar devices, I've never done it with graphics before. Frankly, I don't know if it'll work, but it seems like its worth a shot. https://www.qubes-os.org/doc/wireless-troubleshooting/ Look for the last headline at the bottom in particular, but also the ones up above regarding how to locate modules. Granted your issue is not W-Fi issues, however it may be worth trying this, so that graphics are properly shutdown before suspend/hibernate, and properly started up again when returned. Since I don't know if this works, or even if it'd break anything, I'd recommend you first try this out on a testing AppVM, or testing Template, before you make anything permanent to your current Templates. I.e. make a qvm-clone copy of a template for experimentation, and make a test AppVM. Then put your system in suspend or hibernate while only your testing AppVM based on your modified testing Template is running. There are easier methods to test, but at least making full fledged dummy copies that can't cause harm to your data, is more safe if you haven't done this before. On Thursday, November 2, 2017 at 5:13:46 PM UTC, Marek Jenkins wrote: > > Dear users and devs, > > I really like Qubes and hope I can make it work. > > I have severe graphics glitches that happen at random intervals. > If they happen I must reboot the system to fix them temporarily (potential > data loss). > Unfortunately, those issues make Qubes 3.2 unusable for me because I need > reliability. > > Glitch #1: https://imgur.com/a/fkAjW > Looks like a green screen to me. Happens mostly when the system was idle / > stand-by and I get back to it. > > Glitch #2: https://www.youtube.com/watch?v=sIaOWpFsdTM > Weird screen glitch - also green but with some kind of flickering. Appears > randomly. > > HCL REPORT: > > (Also attached the files !) > > --- > layout: > 'hcl' > type: > 'desktop' > hvm: > 'yes' > iommu: > 'no' > slat: > 'yes' > tpm: > 'unknown' > brand: | > Gigabyte Technology Co., Ltd. > model: | > Z97X-UD5H > bios: | > F9 > cpu: | > Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz > cpu-short: | > FIXME > chipset: | > Intel Corporation 4th Gen Core Processor DRAM Controller [8086:0c00] > (rev 06) > chipset-short: | > FIXME > gpu: | > Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated > Graphics Controller [8086:0412] (rev 06) (prog-if 00 [VGA controller]) > gpu-short: | > FIXME > network: | > Intel Corporation Ethernet Connection I217-V > Qualcomm Atheros Killer E220x Gigabit Ethernet Controller (rev 10) > Qualcomm Atheros AR93xx Wireless Network Adapter (rev 01) > memory: | > 32550 > scsi: | > Samsung SSD 840 Rev: BB6Q > DT HyperX 3.0Rev: PMAP > > versions: > > - works: > 'FIXME:yes|no|partial' > qubes: | > R3.2 > xen: | > 4.6.1 > kernel: | > 4.4.14-11 > remark: | > FIXME > credit: | > FIXAUTHOR > link: | > FIXLINK > > --- > > > -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/6601233e-6aac-4ef5-8a5e-3921f01be3bb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Where can I find the clocksync script?
Is there possibly a security reason not to enable the module for network based time-sync, Marek? I'm primarily wondering about potential risk of increased attack surfaces on the sys-net VM domain. While there still is a firewall after the sys-net, couldn't an attacker use an exploit attack on the sys-net, i.e. while a user is online on Whonix/TOR, in order to keep track of them via an exploit in sys-net? I know such attacks are washed away every time sys-net is restarted though. But if there is such an attack vector risk i.e. for Whonix/Tor --> sys-firewall --> sys-net, and a time sync server is online, would it then increase a potential attack surface in sys-net? For now until more is known, I've gone with the manual method *user@sys-net: timedatectl set-time "Year-Month-Day Hour:Minute:Second"* followed up with *user@dom0: qvm-sync-clock * It's a bit cumberstone to do this manually though, as it isn't as updated as those very accurate atomic based online server clocks. Though, in short, is it worth it to update the clock manually to keep security higher? or is it potentially irrelevant to security? On Monday, October 30, 2017 at 7:27:28 AM UTC, Marek Marczykowski-Górecki wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Sun, Oct 29, 2017 at 09:27:55PM -0700, lok...@gmail.com > wrote: > > On Friday, 27 October 2017 19:10:46 UTC+8, Marek Marczykowski-Górecki > wrote: > > > > > > > Here is how it works: > > > > > > 1. sys-net runs some standard clock synchronization service (ntpd, > > > systemd-timesyncd - depending on template); it is enabled by setting > > > 'clocksync' service (qvm-service tool in dom0). > > > > > > > > 2. Then every VM, including dom0, synchronize its time directly from > > > there. In case of VMs, it is done by qvm-sync-clock (called from > > > qubes-time-sync.service in the VM), controlled by two things: > > > - absence (or disabling) of 'clocksync' service (qvm-service) > > > - qrexec policy, where actual VM used for time sync is set > > > (/etc/qubes-rpc/policy/qubes.GetDate) > > > For dom0, also qvm-sync-clock is used (slightly different one for > dom0), > > > and the VM is set by 'clockvm' global setting (qubes-prefs). > > > > > > > I'm using the default sys-net based on the fedora-25 template. > > > > There is a systemd service called time-sync.target that is "loaded > active > > active". Is this the one you were referring to? > > No systemd-timesyncd.service. And indeed on my system it is _not_ > running, even though systemctl says it is "enabled". Manually starting > the service also synchronize the time there correctly. > > > sys-net does indeed have the clocksync service enabled, and no other > VM's > > do. > > > > If I manually run "ntpdate 0.fedora.pool.ntp.org", the time gets > correctly > > set in sys-net, and manually calling "qvm-sync-clock" in dom0 updates > the > > time in dom0. > > > > The weird thing is that if I reboot the computer, the date is wrong > again. > > Does a time update in sys-net not update the hardware clock? If that's > the > > case, then this issue could be explained by the systemd-time-sync > service > > not actually updating the time. > > qvm-sync-clock in dom0 do update hardware clock. But maybe with wrong > localtime/UTC value? Try calling `sudo hwclock --systohc --utc` > manually and see if that helps. Theoretically hwclock should record > utc/localtime value and use it next time. You can check that by calling > qvm-sync-clock again and rebooting again. > > - -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJZ9U9aAAoJENuP0xzK19csDxwH/jmFBBiAZwLxFjy3jfU5nOlr > ybAqH46FL5HqgHbYtHxCaBWdZwf1Mi3yeCCFxgooII1oene18mzbsNwo6sxhLtv2 > juzQoCNvzAaQPPQ3FrvpNk+uJg4BTWh0HGXmPOWfv+/4FcKdy1L8MDXXGvw8tqR8 > b9esKXezxMJDfXZyOwTMXhqty/el+Q/KzyBPeQ3IlH2a4BTAACSvtf+uD7VDEtVh > Njt7OWWBp/AQpqu8Mx/yN9hCb8VwrNNUfoogQsE5kHcNB567CrUgsoEV8pSuIy3B > dSsaFMud9ovOWh4M3syFl/IS6LU8DZ4GrB5hMTY4g6cU1soX6NZRH6fQZacI7NA= > =DASy > -END PGP SIGNATURE- > -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/a6c3d356-22c8-4f28-81df-63b3f62d1f09%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: Remove SWAP file on SSD systems / provide option in installer
On Tuesday, September 26, 2017 at 7:43:32 AM UTC, tai...@gmx.com wrote: > > It increases SSD wear and decreases privacy by writing temporary data to > disk (no bueno!), I believe an option should be provided in the > installer for this. > > Developers thoughts? Would you accept a patch for this? > I forgot to mention, I believe this partitioning tool is made by the Fedora Project? So even if requesting Qbues to fix this, it isn't feasible to do so, since it's not their repository. Perhaps this is better asked in a Fedora forum. Maybe it is even fixed in the newer Fedora versions already, however I did not check. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/f268dd82-05d8-4e7e-b1fb-cbdf51507ef5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: Simon Gaiser (aka HW42): "MSI support for PCI device pass-through with stub domains"
Really nice that you guys managed to fix this issue before the RC2 release. Had some worries since your earlier statement about issues with USB and other PCI passthrough issues with HVM, but now no more. Qubes 4 looks exciting. How does this translate into GPU pass-through though, now that we can use HVM and XL in the mini stub OS? Anything known to have changed here with the PCIe and graphic cards? If this is still untested territory, could it then hypothetically "*perhaps*" make GPU pass-through more feasible? or is it partly or totally unrelated areas? I'm getting out into deep water territory here now, so bare with me if I speak nonsense. But if there is a communication like between scenario 1 and scenario 2, in the OP above, where PCIe GPU's gets blocked for security reasons (since GPU's are complicated PCIe devices). So, if scenario 2 is used due to "Just in case, to minimize potential attack surfaces", then, if something here blocks PCIe GPU Graphic card communication, is it then possible to make an opt-in flag for these specific requirements? In case it is unrelated, I apologize in advance. I'm strictly only asking in case this update is in some ways related to the PCIe GPU passthrough issues. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/875100d6-3675-4538-a38b-c5670b4ebc97%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Installation issue with Qubes 4, can't find similar issue or bug report
Heya,
I have a weird issue during the installlation of Qubes 4-RC1. I do not know
whether this belongs in the Qubes-Development mailing-list or not, however
I can't find other people with a similar issue. I'm suspecting it therefore
is on-topic to post it here.
I've Been trying to install Qubes 4-RC1 a bunch of times now, but it never
manages to get past the package 733 out of the total 900ish packages.
Sometimes it instead get stuck at 732. The little animated installation
circle freezes too, it stops moving. I've let it wait overnight, some 10
hours, multiple of times, it never manages to get past 732 or 733.
What I've tried already:
- Qubes 3.2 works flawlessly on this machine.
- The machine appears to meet all the Qubes 4 system requirements, see
specs further below.
- I've confirmed the Hash values and signature key of the downloaded ISO
file.
- I use "sudo dd if=Qubes-4.iso of=/dev/my-usb-flash-drive bs=4MB"
- I've done the dd command multiple of times on different USB flash drives.
- I've successfully run the Qubes media integrity check at boot, works
every time. Appears to be no errors at this point.
- I've updated my BIOS (UEFI), which made no difference, still same
behaviour.
- This sub-section is slightly off-topic, but I include it for the sake of
the full picture. My BIOS (UEFI) refuses to accept manaul UEFI update, it
only accepts automatic updates directly of the internet from within UEFI.
Newest manual UEFI is 3501, while the newest automatic update version is
only 3402. The automatic version is not found on the manual download
either. It's weird, and I have no idea if the issue installing Qubes is
related to this or not, since apparently there has been some stability and
CPU fixes in a few versions up to the current 3501.
https://www.asus.com/us/Motherboards/Z170-PRO-GAMING-AURA/HelpDesk_BIOS/ My
board also has no Aura marketed on it, which seems to be a newer "3D
printed friendly" model of the very same motherboard. However there are no
non-aura versions in the support, so I can't confirm if this is the reason
the manual update won't be accepted. I did extract the .cap file from the
.zip file, just in case you wonder about that. So I'm currently on UEFI
version 3402.
- I've tried on different drives too, from a slower SATA Samsung SSD's, to
a high speed NVM Samsung SSD, exactly the same result with both.
System specs:
- CPU: i5-6500 64-bit
https://ark.intel.com/products/88184/Intel-Core-i5-6500-Processor-6M-Cache-up-to-3_60-GHz
- Motherboard: Asus z170 Pro Gaming
https://www.asus.com/us/Motherboards/Z170-PRO-GAMING/
- 24 GB RAM.
- 250 GB SSD (Uses entire drive, and all other data drives are
disconnected).
ASUS UEFI settings:
- VT-D with EPT (Enabled).
- Intel Virtualization Technology {in CPU settings} (Enabled).
- Above 4GB Decoding (Enabled).
- TPM Device Selection "Set to Discrete" (Enabled).
I'm unable to find any clues regarding existing reports on this issue, I
haven't found other people with similar experiences. Therefore I do no not
know if this will be fixed in Qubes-4 RC2 or not. If this is something new,
then I'll be happy to share any information you might need to locate a
potential bug. Assuming, of course, that it is indeed a bug, and not a
hardware/user issue.
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/b3564297-d15f-452f-a8bf-6140745c2e3c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: Safest way to halt the system
In my experience the slow-down is usually related to PCI-Passthrough, for example of the Network device in Sys-Net, or other VM's that have PCI-Passthrough or variouus kinds. It's not always slow to shutdown with PCI-Passthrough, and also not always caused by PCI-Passthrough either. Perhaps some code to easier let go of the PCI-devcies or some kind like that would speed things up? I.e. if you shutdown Qubes and have 3-4 different VM's with PCI-Passthrough, it can takes ages to shutdown. Of course not all slowdowns are caused by PCI-Passthrough, but in my anecdotal experience, most of them are. Also this is possibly different or maybe even fixed in Qubes 4 with the HVM PCI-Passthrough? (I'm still on 3.2 atm). Also HVM isn't the last stop either as far as I understand it, so any such code would probably have to be either temporarily fix or forward looking to be moved between virtualization states? I'm not a programmer though, but this is what I observed thus far using Qubes for a year abouts. On Friday, September 15, 2017 at 3:30:07 PM UTC, linode...@tuta.io wrote: > > Hi, > > I'm coding a qubes service (On Qubes 3.2) that will allow some vms to > issue a halt command that should shutdown the system as quick as posible > (p.e if sys-usb detects an unknown peripheral) but hopefully without > corrupting its state. > > Currently running just "poweroff" on dom0 takes around 2 minutes to > shutdown because of some slow systemd units. I was wondering if there's a > safe way to halt the system letting the VMs minimal time to flush caches > and such... > > Thanks you. > -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/113dd324-9fac-41f2-9e76-806fad019674%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: Delay of Qubes 4.0rc2
I would like to third that suggestion, it's a good for the community to be more welcoming and informative for the people who don't want to, or don't have time to dig into forums. It also serves as a way to hype Qubes a bit more in a positive way, or promote if you may. Don't get me wrong, I understand Qubes try to be modest as it is evident by your actions, which is to be applauded, it's a characteristic I like in others. However many times, Qubes comes across as being a bit too modest, or too silent for that matter. Essentially at times leaning over towards the other opposite extreme. A little bit more of hype or motivated community involvement wouldn't hurt, actually it might do Qubes quite some good to get some well deserved attention out there in the world. Considering what you guys archived, it's stunning that not more people are getting into Qubes yet. Perhaps this increased attention is unwanted? Although I don't think it is, but it sometimes does seem like Qubes just want to be left alone from any outside attention. Maybe I'm just overthinking it, though others might or might not come to the same conclusion. Still, you guys are doing an amazing job! Also I have no problems with the delays either, I know a good job is being done. What I feel is a bit lacking though is the lack of information, lack of Qubes community culture, involvement, etc. It fees like it needs more hype, Adrenalin if you may. But not over-hyped, rather a sort of realistic hype, staying natural, and not over-natural or under-natural. Being proactive, rather than reactive, when it comes to the community. Qubes is really amazing, so it's not the biggest issue in the world even though it may risk to come across as being written as such. But perhaps the bigger question is, are we allowed to bottom-up engage and build in the community ourselves without clear laid out community leadership and guidelines from the Qubes team? Otherwise finding someone who might be up for that job, or more, could perhaps be another solution. Of course only if you find it being an issue as well. I also have no idea if others see it the same way either. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/fd79f2cd-35c3-4ca3-b9ea-d3445a615d47%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: Suggestion: touchscreen support for guests
While I cannot answer on the feasibility part (in terms of security feasibility), I do however think it's a really good idea. Devices are getting smaller, touchscreens are right now spreading year by year at a faster and faster phase. We are seeing small raders, lasers and cameras which tracks hand or body movements. Google glasses and similar technology had a fallback as the tech wasn't ripe in society yet (privacy concerns, lacking apps, too weak at the time, etc.), however it will most likely soon be back. I just want to ask the question, what will happen when our phones are strong enough to effortlessly run any workstation or any job a desktop computer can do, and combined with the technology mentioned above, and the Linux world is behind? To me, it looks like Linux (and Qubes for that matter) will be heavily disrupted in the near future, if we do not take these emerging technologies seriously. Qubes might still have its security strengths to rely on, but in the face of awesome new convenient technologies like these, that will be the only thing keeping it alive. We need proper touch, VR and graphics support in Qubes (and Linux in general for that matter). It may not be important right now, but it will be in the near future. It's a long-term investment (in time and coding) to build the infrastructure of tomorrow. We might risk having the ground shaken under us as these new disruptive technologies will kill off laptops and tablets (and desktops for that matter). Think of it like how Apple disrupted all the traditional mobile phones, and how naive everyone were back then. Try google them up, how arrogant these people were mocking Apple's first iPhone. Yet the very same people who mocked them, came to fail tremendously because of Apple's disruption. I'm no Apple fan-boy btw, I stay clear of Apple devices, however it's a nice example. Another similar example is Kodak and the digital kamera, ironically Kodak invented the digital camera, but didn't believe in the technology and shelved it. Then they were disrupted by the very technology they created by other companies. The visionaries will always win the game, because they are always several steps ahead of everyone else. Linux (Qubes) need to pick up our game, or yeah, it's gonna be some tough years just trying to catch up. Perhaps I see the coming years wrong, but the way I see it stands right now, we definitely lack development in this area. The year of the Linux never comes, because we always, always play the catch up game rather than taking any leading positions. Where is our visions? -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/1c7553bf-c4ad-46bd-a2b1-a3f8fa73fb52%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
