[qubes-users] "No such file or directory" when restoring backup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm trying to restore a VM backup (created with Qubes 3.0, restoring to Qubes 3.2), and I'm getting this error: ERROR: [Errno 2] No such file or directory: u'/var/tmp/restore_yoGbl2/vm11' (I transcribed the message from dom0 by hand, hopefully I didn't make any typos.) Any idea what this might indicate? Cheers, - -- - -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmob...@airmail.cc Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C Send non-security-critical things to my Mobile with OpenPGP. Please don't send me unencrypted messages. My business email jer...@veclabs.net is having technical issues at the moment. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJZW3dBAAoJELPy0WV4bWVwFrkQAJlSoPk94j6yXdIT51+poWtt iL3kTLX48s3n0PQOw80mBJUPy3l2wESvFhjz7/xAmXZAGLVzTcNTAPOC3RuLLxhb WKKNuWJiIY5my38PY97RoDy+YqmU3fxu+b7XkDG7+7b51Gn7NU1dFtNlmgKpnwBi SbFvTDucl3RagA/OyfhRKMsmy009e4ZWNWB9MtA72S4VVaP8wN7Fb2w8vwPy+d5K LoMa7lmiK6hcXA7N7X4YEmc1V3YJCqZcXd2P7vVSLC2Os+HWkEOOp1uZUFxTVBZL Ei2A6Js2wXAabnZxq0VkwyiOO59Rir+7dIgD+xMPnq+VmxjlwUErBxVF0VBtnPVk IS6F3j93QrDX65PtHv78pt59xdaoYij0yY/L6yMvQKgCIFUM17w5ryYZDKXahpc/ mzViiFJv7yF/6MYWT9Z5MIZM2j7XM1iK4uqYwMXpF6wPUt8W7C5VouZIzcQua2nS kac2lNwDsOMWrhX39Glw4axIJqiNz5K5W+DAkIzRuj/Mpcd6t/4mJuqF6JSrs5ff suVG3j7Hi3DqPGy2weD/GofvaHejEHnGv66+Ckhh618y6H0/+u3MTcBbh3wcriqc Wx5Jq/kjTs15FsFFFc98dyPrH2Im9MlCs6Htos8KVmsfumMyOsVEPlte+5frA/9W 6DUYN4zLcdaRlV1+Q449 =vaAC -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ce61a311-7981-c898-6ae7-abc6ff270d85%40airmail.cc. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: off topic - invite codes to 'riseup'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 kamaliko...@gmail.com: > need invite code for riseup.net email account pls help me Aside from the fact that Riseup is probably compromised for months, it's very bothersome seeing these spammy requests on a public mailing list. Please stop sending them; they have nothing to do with Qubes. There are other email hosts that don't demand invite codes; you can use one of them. - -Jeremy Rand -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYl7j+AAoJELPy0WV4bWVwa5oP/2axmIdHHGjWpQv3wV7J4/6q TP7ZTA8zt4ywcMVTCjePn0mbVi/7wNNnoYT8XA2iYxnOILEubUZHpbhgDDjD+KTH Hc1faSv3Pmpi+rXW4ciU42s/jRL6xANOfpLfZXDzHt4kEJnxfrwUfPpVkm87sUOs RzsaeHfOPG3HCLMrLTUMJuOkZkJKPuR/WqQ2xXwPOyFcKXiWFT6FjGp0zPUQe2nu pl2IbDyZucMbzCehb2cvZUfLJEavvtExEATZkrLBus8/GCIwkhYupekC9c2xwUp1 HBU1hgkkeWgynrcPKoCBSMtATH4/6FPvlrRk1NaXpoHTUuaSMHnzNYRD22HQC5wG 6iMDF38e/vj8Wa7tyo7eQXFoSciXieTYo2++we4BhUJqytuXr2eLIW/STbji1Kae okCvmOimNHZeRsRhTloazlcKNYwSZXHPYesre2BBjm76OVYSDszK0ljMooHFc1Gm YJ2ty/WBkNpQALp2uL3pGN62gk0Mb/fw/wePiNBJ+N+lCEpUYfZ4x3DCxPD05yW1 /tYYi7ukKzCsA9fpcd6kadso2cRYOV/PweL+KHihTULxQPSAM2FeH9pagPNRMYzC OlgJdG4sMvRXK9GFgpd7JkICQD3ndp5SuiauYpH9Bi8HWT5FRj+J0K4jH63d8JVS DB7/gtW5io3i+glqSZDg =Qzzs -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0e73affa-1e29-5450-a5a1-b9f792986909%40airmail.cc. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Inconsistent Screen Resolution for Fedora VMs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Jeremy Rand: > xmee...@gmail.com: >> I just did a clean install of Qubes 3.2. For some reason the >> resolution off apps in Fedora VMs is wildly inconsistent. The >> borders of the windows, dom0, and the Debian VMs are correct but >> the apps in Fedora VMs range from consistent with the others to >> so low as to be almost unusable. I can't figure out what causes >> them to change and xrandr outputs the same thing no matter what >> the displayed resolution is. > > I think this occurred for me a few weeks ago. If I recall > correctly, the HiDPI settings in GNOME had somehow been set to 0. > No magnification is 1, double magnification is 2. 0 gets > interpreted as 2, for reasons that only the GNOME people are likely > to understand. The standard GNOME procedures for changing HiDPI > settings fixed it for me (I restored it to 1). > > Sorry I don't have more details for you, I don't believe I wrote > down the fix at the time. > > -Jeremy For future reference of anyone stumbling across this thread, you can disable HiDPI in your Fedora VM's by running this terminal command in each of your Fedora VM's and then rebooting those VM's: gsettings set org.gnome.desktop.interface scaling-factor 1 Until you reboot those VM's, their GUI will have weird glitches. Hope this helps anyone who runs into this. - -Jeremy -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYgvO2AAoJELPy0WV4bWVwCtcQAIAGPsjKZzgKeisa67AHaYtE kd21Ham1w6WNDQnweDmjOSPsalJfgA+vQ6jaTUJZoW6FAmgui91PDF0bTDjQYuIe fVv4LzZNFFSbNAbnaySHdU3fZMOqV5qN1jZpYkC8tyExUfCUTzTNGdudZLIrqtYz 0bsPNAzC0zLoGZorqki52qMFR81Z4oztmAd2RMQRBUgxQF6f6YzZIUUIWCU7KLwx ZuSL+kyw6wvVWUsEA5XesdGbguG8KzREyLr1YsZM02ARLf5aH+uWpuhWtey2ERGp t+2ZbviKtHyeVKcrASfxaPCzYhlcIDLCS9y3v6Cp9G4CCy5RBnpa366WwXBpKn0l flmswfXmtrfLSDlTgzi37huKOH0upMEb1CHfeVVUHm9ZfvSzySEvVu4KDJcc5rFr RlgZ0HzPeNTtVvbpdIugj/isWwaQU6mmSLe96zmG9aeMt1vqYDqnjoNqnZaQ7/0Y uBA+ukN91YRoG9RTMmJzfT3AVJvasyyt4giCKWRI/HmJkqrqAh1N6DcvlzNGfrZ7 2s7Rn5V1fJtQe3AsVeMVxgPqrqZ4fyXtW1poVHTp4dK9NNfngjj2tuVnNH3udwxP xPX7GZQDve5G3M+1wzX+QtQnVYAUshxothhPVTRVciySJcNtZcpohAeFYSgI/u46 UJmSLOlXGYgMKBYnQGoX =YBlP -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/cb80c92b-79cd-2923-d2cd-840ff4d1f48f%40airmail.cc. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Possible to get usable Win7 gui?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Robert Fisk: > On 12/30/2016 01:33 AM, Jarle Thorsen wrote: >> torsdag 29. desember 2016 13.14.25 UTC+1 skrev Grzesiek Chodzicki >> følgende: >>> W dniu czwartek, 29 grudnia 2016 13:07:44 UTC+1 użytkownik >>> Jarle Thorsen napisał: Currently my Windows 7 StandaloneVM feels a bit sluggish. Moving windows (no phun intended) is a pain. Is it possible to have a Windows VM without any lag, or is this just a part of the deal with Qubes OS? What tweaks should I do to get my Windows VM as responsive as possible? I have no problems with lag in dom0 or any of the Linux VMs. My display is 2560x1440, maybe a large display is part of my problem? >>> >>> VM Performance is largely dependent on the CPU and RAM so >>> ensure that your Windows VM has enough vCPUs and RAM assigned >>> to it. >> >> Throwing more vCPUs and RAM at it hasn't made a big difference so >> far, but I'm moving my system to a way more powerful system the >> next couple of days, hope that will make a difference. >> >> Can anybody please confirm that it is indeed possible to have a >> lag-free Windows experience under QubesOS? >> > > I run a Win7 VM on a i5 gen 4 ULV machine. I have always had > problems with lag increasing over time. On bootup the VM is fast, > but after 20 min it is unusable with each screen redraw taking ~4 > sec and associated high CPU usage. This has happened both on R3.0 > and R3.2. > > I work around the issue by using Remmina (or other RDP client) in > an appVM, and allowing IP forwarding in the firewall vm. This > solution does not suffer from increasing lag, and should be usable > for everything except gaming. See instructions here: > > https://www.qubes-os.org/doc/firewall/ > > > Regards, Robert I'm curious, are you using Qubes Windows Tools in that VM? My Windows VM's do not have Qubes Windows Tools. (I'm trying to figure out what might explain why you've run into this issue and I haven't.) Cheers, - -Jeremy -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYaWeLAAoJELPy0WV4bWVwUC8QALYQQA3bznqd2DS7HqGiBExR PTvzBify76HRLA3IQh/W4oyNdQOFuv9Trb4P6eSeFIwo2TXakKhupV8xTeR3z00w 5L7CDfU7O61AFLPwdJyOTTVd3fR5JDajXuiDeUca8j3gdSnAJepMqwvpc7Tal/vo YUWtZZWH6wEhH9MztB+/tZN3XUTKkZvedP7h8cjKkzkLQDNxmbmgc8YAuny16F1c izo95kYqfQJyBfgOpbIoTldrXRAO70OUyOuNEjNPbYmd3paXZkSgyZ4yeg07YnhR NiUNhvdyLqjwCVzyvRKEkPdMleop1SrgQxNjvOXhfULXwm+y3CHLQhFT1LYepeEc +yHsBCfJ0bNKjcSz8mwAs0BjKrVdVtGrXRDHH4e5VNVjh5rUKYGS+Tq3mYw2Pz5d YYd9DKtgJ4xRNkSZMEHFlcOoHD1+F1M5VYNNIEMY4LR5X/8MgDqQEEKkEDXbsNaY lnbI0hECdqnyHW0+Roc20IpD01PLSpF2HOw4/DIslnhGrPpPTdPmQFPdwCdkvWFK amcci0z3g6NCq9o5/PsZ4wBNTRQ6tlQ66Mjf4GgerOb8+QF+KrQf2X257xIJRiym ZnfaPJImkug4OIYqf5rqDqVgqSVcmu7nP0e9P2aUp5n/cR9xpjZLBTYEKA8a6SFp qKtP3xUDZ06mMMACCdSF =RqRh -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/84cde2cc-3d58-703f-d076-5af8325a28b3%40airmail.cc. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Possible to get usable Win7 gui?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Jarle Thorsen: > torsdag 29. desember 2016 13.14.25 UTC+1 skrev Grzesiek Chodzicki > følgende: >> W dniu czwartek, 29 grudnia 2016 13:07:44 UTC+1 użytkownik Jarle >> Thorsen napisał: >>> Currently my Windows 7 StandaloneVM feels a bit sluggish. >>> >>> Moving windows (no phun intended) is a pain. >>> >>> Is it possible to have a Windows VM without any lag, or is this >>> just a part of the deal with Qubes OS? >>> >>> What tweaks should I do to get my Windows VM as responsive as >>> possible? >>> >>> I have no problems with lag in dom0 or any of the Linux VMs. >>> >>> My display is 2560x1440, maybe a large display is part of my >>> problem? >> >> VM Performance is largely dependent on the CPU and RAM so ensure >> that your Windows VM has enough vCPUs and RAM assigned to it. > > Throwing more vCPUs and RAM at it hasn't made a big difference so > far, but I'm moving my system to a way more powerful system the > next couple of days, hope that will make a difference. > > Can anybody please confirm that it is indeed possible to have a > lag-free Windows experience under QubesOS? My Windows 7 and Windows 10 VM's feel reasonably responsive for getting work done (although I definitely wouldn't want to try gaming with that level of latency). My dom0 resolution is larger than yours; I haven't adjusted the default resolution in the Windows VM's. The Windows VM's have between 2 GB and 4 GB of RAM and 2 CPU logical cores; I'm on a Haswell i7. Cheers, - -Jeremy -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYaTvdAAoJELPy0WV4bWVwrwIQAKudnwSvu9iAItfV0ZAB91XK gilr85VrXFFqMaFIAGt25JRZvqbaVhX8oijIbXdsHfp9m2c14b+IOs4/8wF+KIP8 RptE7QEd0Vz3mbrW1NwZoDnN4dSMQ9yzbdktladiHaM/QfEAkpWOCTzhzIAvdkYm ep7IcbKasPsXVw9wBCuzfq5snKpeN09VUAcL5JpPB0zOMYN35fb/ccIHEEKwLNTG ITWxkzbfLrgl6jTkZr7IZK1m+pOACHnlcw49/Lnv+Z/3U/q/GivrJFe+G6j1+nY5 IDdhiz2AXri4lLM91xHU1A+TiLAMxET+0dCn5jWoDpkj3NuwFfN+RykZZl03W9Ra waX3+wHx/9BqUsGk0oKdi3f9NsRl5xMx2yruGMXRsqeSAABs74RdzkEQpX4jtccC xvv7hBRV8cUFJBJxrnCDOKuzqPhVE09B9+zYz/FTqfrVEmQxyl+p/1rFcD2RoUQN rEmIv9witEGmbC2K78sJgYCw32Wm27n0I5KYkRhgQ4C9+SdBun/IIWhY+cNRlI0X SRD9VinSeKL1CbBoHH7BvueHP1djP8L7nactT4MjM2dZ4DxfxdpKLjI/e1//i1by QnmFe8bAi00m+OuSsdDaxVkDHGhGlJ+xrffC7A5j1q/+V9SQ6U3kdgaIkO16dqgO va3/mfdQAMQCUepZ8wVn =xAip -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/fe4442bc-2ec4-c952-69ea-7ccc6cb748e4%40airmail.cc. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Is Fedora Really A Good Choice For QubeOS?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 pixel fairy: > On Tuesday, October 1, 2013 at 6:32:41 PM UTC-7, ears...@gmail.com > wrote: >> We all know Fedora is a big name, but is it a good choice for a >> Security Driven OS like QubeOS to be based around? What do others >> here think? > > There are a lot of packages creating a bigger attack surface. but, > bigger distros like fedora have companies behind them like red hat. > red hat has been pretty good about actively looking for > vulnerabilities in those packages. distros that automatically > upgrade to the latest version (gentoo etc) can also burn you. they > would make better template vms where your more likely to want newer > software and new issues can be better contained. > > for dom0, newer distros are better at hardware compatibility with > those fancy new processors, graphics cards and storage controllers > in laptops. > > just personal opinion, but wayland is a better fit than x11 for > qubes in the long run. fedora is the only distro with a dedicated > security staff actively supporting it. > > anytime you abstract a layer, your diluting your resources. > maintaining a dom0 isnt much more work than a domu template, but if > you want to add slackware, arch, and gentoo, youve now more than > doubled the developers distro maintanance work when they could be > working on stability and features. Potentially worth noting here that in Ed Snowden's keynote at Libreplanet 2016, he criticized the free software community's tendency to use stable, outdated software. Snowden said that the attackers move and adapt quickly, and it's dangerous to continue using outdated software that doesn't have the latest security fixes/features just because it's more stable or more backward-compatible. Snowden did not explicitly mention any distros that he was talking about, but I got the distinct impression that he was (at least in part) talking about Debian. Of course, "appeal to authority" is a classic fallacy, so we shouldn't do what Snowden says without questioning it, but I think it's at least worth considering his argument seriously. Cheers, - -Jeremy -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYaTeQAAoJELPy0WV4bWVwbNgP+QG3jY+xlwsTnViOS+IFEHMP Nyt+d9Cuq7iEnCsr1fuXbzjSNB8RDM0y2BY6rciELmo4kvyfsGoPYZod7nOlQPeV xjgjubrlA3udMxSCsc5lc2DbP4IszehJECYGbZw4gaFabScs6ugt0P9gxKaiTIWR pa9bAaSzJffZsJg9/efUJuo134Mdd8QBssKEC6idWCiEuM8YWHZI9xKfvhTjRrqj g233nSNbvctg0yoUQbf2XHZ6gyGZ2p0Y1ab8o0o0MFVsuQIuPCKlWgr/WhjgdWDY Ye4TCYZhonuLHRCiOt+ZuS2w8nj24O0qFvXra+asXAaW2mFzQa/Aq3CdLBE87nXE z3dgNp2Z08dWi28ncbCwvn8mpw0w07yl1n6+2JlBC4pDTF2/r6BMgsp4DIS9sFDB h+mFWCnqh80P/39SQeOoOcHATruMfHp8CUDVtOMVBRV4VpoA7YaKxiiiUXFnD21M S6XP7QqxPkbPW0E77UeR53igB61QQ1t3Fb4QQRLZY1bhncKn3kM/OmUDnHzepLQn 0/FLW/aJMBofOHeb6xqrfipeayGrdHLNuav9Nu1QRuX2lY6E0Sl40VZBwRERxfaW t+Ck3n4Qw2Gru13zXPhHuE8OpTV3/RgkMzNMnADxfArhSIW2zwoYQvNCn8U/LNaq P2HMZA0yehx6CZnBmdb/ =RC2L -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/52d5d96c-c021-9673-27c5-1999e8541961%40airmail.cc. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Cannot find unused qid!" when restoring backup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Andrew David Wong: > On 2016-12-13 12:56, Jeremy Rand wrote: >> Andrew David Wong: >>> On 2016-12-12 21:30, Jeremy Rand wrote: >>>> I just tried to restore 5 VM's from a backup. The backup was >>>> made on Qubes 3.0; I'm restoring to Qubes 3.2. All 5 VM's >>>> fail to restore with this error (although of course the name >>>> of the VM in the error message varies depending on what VM >>>> I'm trying to restore): > >>>> -> Restoring QubesAppVm iso-linux... ERROR: Cannot find >>>> unused qid! *** Skipping VM: iso-linux > >>>> The error was copied by hand since copying from dom0 to an >>>> AppVM is difficult, so there might be a typo. Based on the >>>> error message, I infer that maybe this has something to do >>>> with my Qubes 3.2 system having too many VM's on it already? >>>> Is that an accurate guess, or is there a different reason for >>>> this error? Is there any workaround? > >>>> Cheers, -Jeremy > > >>> The only other case in which I've seen this happen is when a >>> user surpassed the maximum number of Qubes VMs (254): > >>> https://groups.google.com/d/topic/qubes-users/Zw5XjZndrDo/discussion > >>> Did you do the same? > >> Looks like it. I just checked and the highest final IP address >> octet is 253; add 1 for dom0 and it looks like I'm at the limit. > >> I realize I'm probably much more gluttonous with VM's than most >> users, but is there by any chance any progress on increasing >> that limit? > >> Cheers, -Jeremy > > > We can see if anyone's interested in providing a patch: > > https://github.com/QubesOS/qubes-issues/issues/2519 > > Please understand that since this falls far outside of normal > usage patterns and affects only a small minority of users, it's > going to be a relatively low-priority issue. Therefore, it's > unlikely that this will be changed soon, unless it either turns out > to be trivial to change, or we receive a patch from the community. Yes, totally understood -- seeing as I didn't pay anything for Qubes, I certainly don't expect you to go out of your way to fix a minor issue that so far has only affected 2 people. Cheers, - -Jeremy -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYXOUbAAoJELPy0WV4bWVwh0kP/2wiRxhYFa1V8pb5TGIV/khN ELWZN0smAjo3JmQl7zvd/zWrANhun1X/prrEcFCvBGo7u62GuXfCioRUguXoBGZK uk12gm8x+nsYzCMEoOfLJh6zuxNtMGz/Biq8X3f2aYKErLtm99G74ocaQO7aYN3u zMyFw8Cfjkj5q1Zus0HejrPwVQTz5sLQjFBAZgXmH0LB+wKPOWDxs4UOxfBIcU/1 Ff5dEgdR+PVzgAdoFDns6OJXSy7r4js+gQ7kRLkuMV2R5Q9d2Rx5VwKXGLMdrhx2 vGn6BkD7kRxRHEgh4rQhjhXXWXd8/9r43Ggs+NsLx7mW4dTs2E6VwjEWaDPL/ypy nbffOljdZNGRR48JRNKTjs8DCL04mGkq00QSF/Xllmdq2INA0Fl1KFEqsdkUQcl5 3BkRi8af9lK6Ms9K7djEqj1qzCbkJqjFMQVwDkWHsbAKnoiPkQ2+jN6izlUUtKfP 4emkY6JUk8KYArvNVf0FAPrtC32mYynWEOgV7ot5i+lGxNtiR6C2aZHPJyhicNxW X6jA+LFdkp4X7ZEp8/79dBBoHxe5K3hB/Mdz5FSV+B+3o4o5pDxateQRjvcGLeeD Su2PNaJ/IDfapR5NttnGQq37QZZCSGnIZH2ZbWT9su5XPwAN5gZJ/hzTm7ZRQUIl hEY3OMxGEanhOpRuT135 =ZrQN -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d0d2e441-3303-c9e1-2215-d5657daf8e1d%40airmail.cc. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Talos Secure Workstation Crowdfunding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 J. Eppler: > Hello, > > here is the correct link: Looks like Enigmail's line breaks in combination with Google Groups may have broken the link I provided. Apologies (and thanks for correcting) if that's the case. Cheers, - -Jeremy -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYVBJTAAoJELPy0WV4bWVwmuUP/0isdqGXH2xLPgY9q7QAwVlM II/5Y7LdQ0HHk2r0tme/27BmThsVv7MYZIwkZg4AlxEqUTKMTSVXqvZAafqo5wl3 56Zms6ZF1LHUgjpuRo7YV0c/F+MR86jUnPY6WKkSmsqvUkeVfk8PJ2o8zJO8MyXh Lh46nd5TJ4ZwsJiV/7YiWwIwpidlP0DfLGkFbCZ9zyUUcm+NvKUYPxHcQrHIozRd ZEBs83iZGMy3PzxDPThujqa+BWkUAqxzuMeidsXZgY61IyDYpKiE9pAaBKkdmsrD LNpoeyjdsE2gMZwXDU9YGZkZAICH5vB7y4Tg6K2UiVYk9AP1/nRToFJZof8E+pDy R5xrkw2FcJH2DI8fkZ1q4Vnn7rYjRegS/7Tg1hF1z5uTxkAtI5Z9f4GCVm+B/5op PZZRnC3Kx3whNOi6wABz70wJY/V9hQ1nvG6aXYQpRDAJ00ppjxdvS7zmwTP0pFZm 0d+OpHF9WB4ncHIVtYrqGF8+vsAaQLPIFpw9HMnzCoWYgUS1CtIqVx221Iftiimu N7xJTbLr0nnWTmVYwxR/6JKz11gtcWJzB3VhxfwVHszUeoLd9mJnlHV8ZlX8B6l1 ybC/uGzFAdYnh+BXDEnhFH/e+jzPsPPGi5fPCBiblaZqVIwTwMGnilOeiL00mFXU Jsqrrlbl2E8nK8aToFNH =lyjA -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c2053b75-8fb4-4837-4456-29143f8dc17f%40airmail.cc. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Talos Secure Workstation Crowdfunding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi everyone, As those of you who've read Joanna's paper "Intel x86 Considered Harmful" are well aware, the Intel ME and other closed-source firmware pose a threat to trustworthy computing. We can do all the awesome hypervisor and isolation stuff we want (e.g. Qubes OS), but this doesn't help when the firmware is evil (and closed-source firmware should probably be assumed to be evil). x86 is not likely to improve much on this front (although Trammel Hudson's recent work is pretty cool), which means we should seriously be looking into alternative architectures. POWER8 is probably the best contender for a serious alternative to x86. As you may have heard, Raptor Engineering is doing a crowdfund campaign on Crowd Supply to produce the Talos Secure Workstation, a POWER8 desktop/workstation with fully libre firmware that is comparable in performance to current Intel hardware. In addition, most of the mainboard logic is implemented using FPGA's with libre bitstreams and libre toolchains instead of ASICs, which adds to the auditability and control by the user. Features particularly of interest to people who use Qubes include HVM, IOMMU, and TPM, as well as some very interesting engineering relating to preventing evil maid attacks. Raptor has done an excellent writeup of the latter; see the following links: https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workst ation/updates/talos-fpga-functions-and-responsibilities-part-1 https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workst ation/updates/talos-fpga-functions-and-responsibilities-part-2 (People who enjoy reading Joanna's technical writeups are likely to enjoy the above Raptor writeups too.) And of course, as a workstation class machine, Talos supports plenty of RAM for running lots of VM's simultaneously, as Qubes users tend to do. Raptor Engineering already has a solid track record of Coreboot and Libreboot development (among other relevant areas of expertise), so unlike most of the projects that have done crowdfunding in this space, Raptor has an understanding of the tasks involved and is likely to actually deliver. Fedora and Debian already support POWER8, so the Qubes dom0 and AppVM components shouldn't be hard to port. Xen does not support POWER8 at the moment, so Qubes won't run on Talos when the Talos ships. However, there is interest in adding POWER8 support to Xen, and POWER8 support for Xen is much more likely to happen, and much faster, if Talos meets their funding goal. Yes, the price for a Talos is sadly quite high. Note that it is much more powerful than most consumer PC's (e.g. the low-end "Desktop Edition" comes with 128 GiB of RAM), and that small production runs are naturally more expensive. If they meet their funding goal, it is likely that price decreases will happen later in the product lifecycle, as well as producing a new version based on POWER9. If you're in a financial position to order a mainboard (or a complete system), please support them. For the far greater number of you who are not (I definitely can't afford a mainboard), please consider the $250 SSH option, and if you can't do that, please consider donating $10. If you have friends who understand that closed firmware is a threat, tell them about Talos. If you have friends who ideologically are aligned (e.g. who support privacy rights) but who aren't aware of the technical concerns about x86 and closed firmware, explain the issue to them. There are industry players watching to see how this campaign goes and how diverse the support is; every $10 donation is a vote that signals "We want this to happen." $10 really does make a difference here. The crowdfund campaign ends in 29 days on Jan 14. You can support them here: https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workst ation Cheers, - -Jeremy Rand -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYU3gOAAoJELPy0WV4bWVwO+IQAIr+UtgNk+29oFRjvd+UKMUF QkWkXrn+PqWDYs63NSX4LWnyO3apo1wY/yjmBkSiKKvEnK+1v3nDOAxGxPSKyWC1 9DWhESfBzM1dagy2spGEB7YpuAM4yrp1Ih58PxT1e/mRRca14NomwzNiNiqDpw94 rZWQXxQ/igMQ8VTLivFosjB6aMKB2TyM8xFYMDg8+yefumG5wGrDKhSacM21L7MM uLilg0eTJLkttYXNnnZOATcIsymuT3Wi84hCkGzbDWekNen2/ZJfZO5+K39tzUXo xsK+ndi6RSU2khOJ2+/laU37aDV0iKAKRlWi0T40fmTaO/skedZSNIJ2Br7iXwGh UyUSAnhy26oH1wYJ8Y+oAd+liJStlxCRf5TCDWo4SsojR1IYV9qoIjfFOjPmUxT6 pLNhuEKP5UdP1yDvCjF+DLr+LtCjmkP63hCz+Asj0sesO7zcO4EYQEwyATx2b60S Uonczt9QFznxLy9wQdo8qi3beBDY3ap2dTvikvQydSMSSsh9kP3yVDhRkAxHMCn6 2u68jSUVszRQv5C15PG96bZa3cZ2oR570RJ9Yb+PfrOjRxd7z0e3+ApqIWyu68kf hMQeJCkPpI/GKOqjnJaweu9cuoMfh0mGYGRs1tIfDuJBFFzt5A/8RA10O+aViZMO h0OR5a2svxdfqY97t74y =pROL -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To
Re: [qubes-users] "Cannot find unused qid!" when restoring backup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Andrew David Wong: > On 2016-12-12 21:30, Jeremy Rand wrote: >> I just tried to restore 5 VM's from a backup. The backup was >> made on Qubes 3.0; I'm restoring to Qubes 3.2. All 5 VM's fail >> to restore with this error (although of course the name of the VM >> in the error message varies depending on what VM I'm trying to >> restore): > >> -> Restoring QubesAppVm iso-linux... ERROR: Cannot find unused >> qid! *** Skipping VM: iso-linux > >> The error was copied by hand since copying from dom0 to an AppVM >> is difficult, so there might be a typo. Based on the error >> message, I infer that maybe this has something to do with my >> Qubes 3.2 system having too many VM's on it already? Is that an >> accurate guess, or is there a different reason for this error? >> Is there any workaround? > >> Cheers, -Jeremy > > > The only other case in which I've seen this happen is when a user > surpassed the maximum number of Qubes VMs (254): > > https://groups.google.com/d/topic/qubes-users/Zw5XjZndrDo/discussion > > Did you do the same? Looks like it. I just checked and the highest final IP address octet is 253; add 1 for dom0 and it looks like I'm at the limit. I realize I'm probably much more gluttonous with VM's than most users, but is there by any chance any progress on increasing that limit? Cheers, - -Jeremy -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYUGCOAAoJELPy0WV4bWVwehIP/2UWc57pEVmh/RzLy5y09s+L m+3ttJ9+FMGg0Xm2jZGnNT3ufXhX3brxphC8I6hHij15z1ZuMrRQ6Ok3PFheDSD3 uLU+8pD3tX8L0TfU8PQsY5EkseiGM6fldQjgMhDzpX90+m1E7SwUCOO1JW50MbXH WkmjXkWaztKiQrDKskv6Rp4GcVHuuOWxK/tHB2OnQDuyjI99125a+rpOPdMbI7N/ dl1Eq2Kjpq5kUkif12C/ONgija9EKycWDoNBVKbxUWnIarNwqHUynKRgaQNtapJN UI4zkWX+oqdvYcXjn3+Hog37M7ZmTynCQMYI24G27YJP2AyTVu7ln9dOfe2aduHk jqFRRWfZK6iC84WzzFiIsPmJ+9/lqEpFGn6BwLwn0RWGS5yvjhMVxtpw3fvUZW1g n2stXQjSzxnWwN8cT0ojTEf0Q2J1HCbdUZApbzbbvs4+SuBNAQra1ly6fob8iCeo l6ga5MwsviL8KmDCj2T2iZWx1Wnffe4WgKlJB8bGI2AgF31xkmsv8C79s8oPfQii rj5tgzsh84S8LhtEuPiM6SZ8Kj/ViHuJ5KFoP4IQsaaICTg4TDfvVhp+8dTOnWka HZm5idIrCEStC+SxVdpdBUXfw0I9zn/LKxGK9SG1tyKX6f23uV9VGMAcooZmC0/1 TfUwJnNMTiJHfSrFlpIh =zC1M -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c2832b10-231e-9121-1cc2-06c13848bbe5%40airmail.cc. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Massive performance improvement after disabling power management in the BIOS
kotot...@gmail.com: > Hello community, > > I was wondering why one of my program was taking ~15 seconds to compile when > my colleague compiled it within ~3 seconds on his system. I know there are a > performance price to pay for the virtualisation but nonetheless. I was super > annoyed and I vaguely thinking about switching back to another distribution > but at the same time I was reading about DNS rebinding attacks and I really > wanted to stay on Qubes. > > I gave a look at the BIOS settings, in the power management section. There > are options like "Maximize performance on AC" and also options for when the > laptop is on battery. I already had the "Maximize performance on AC" on. I > disabled the whole power management section. Performance are better! > > The program mentioned above now compiles in ~5 seconds. The whole systems > seems more responsive, Firefox and Youtube video (HTML5) seems also better. > The only drawback is that the laptop is definitively generating more heat > (and probably consuming more energy) but that's okay because I spend most of > the time connected to the AC. > > Is there a bug somewhere in the kernel, in Xen or Qubes which prevent them to > properly use this BIOS power management system correctly? > > Have other users experience something similar? > > > When googling I found this article from VMWare with similar problems / > solutions > > https://blogs.vmware.com/vsphere/2012/01/having-a-performance-problem-hard-to-resolve-have-you-checked-your-host-bios-lately.html Hi, might I ask what manufacturer/model your laptop is? -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c81cf4fb-869a-5baa-ba53-5cf5d7c10118%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Future plans for KDE on Qubes?
7v5w7go9ub0o: > > On 10/23/2016 09:38 AM, Achim Patzner wrote: >> Hi! >> >> >> After a few months of severe suffering from xfce on a HiDPI display I >> gave in and installed @kde-desktop-qubes on my system – and I'm pretty >> sure I don't want to see xfce for the next few years. Title bars have a >> usable size (something that cannot be configured in xfce without >> building your own themes), icon aren't scaled randomly and fonts are >> finally looking as they should. And third-party software like Softmaker >> Office is finally working as expected. So: Will there be support for KDE >> beyond Qubes 3.2 or will I have to plan for carrying a third machine for >> my office work space? > > +1 > > Never thought I'd admit it, but KDE (despite its legendary (and today > overstated) bloat and complexity) - actually works rather well. Good to see that I'm not the only Qubes user out there who finds KDE to be more usable than the alternatives. Totally agree -- I really hope KDE continues to be supported on Qubes for those who prefer it. Cheers, -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e77bfd4b-4ca7-c3c4-e538-49551bfc77c8%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Multiple monitors partially broken in Debian and Whonix AppVM's
Jeremy Rand: > If I install LibreOffice in a Fedora 23 Template using Qubes 3.2, the > "Presentation Display" setting works properly with no issues, so I can > see my notes on my main display and the presentation shows up on my > external display. > > However, this doesn't work properly under Debian 8 or Whonix 13. It > seems that both the notes window and the presentation window show up on > the main display, and are forced to the resolution of the main display. > I can drag the presentation window to the external display and maximize > it, but its window size remains at the resolution of my main display. > Since my main display is much higher resolution than the external > display, the result is that the presentation appears zoomed in, with > much of the border cut off. > > Note that I'm using the jessie-backports version of LibreOffice in my > Debian/Whonix VM's. > > Any idea what might be causing this? > > Cheers, > -Jeremy Rand Hello, This problem is still occurring for me. Does anyone know what might be causing it? Cheers, -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/dc4b31c6-2718-1f07-fd23-62f993b75d1d%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Inconsistent Screen Resolution for Fedora VMs
xmee...@gmail.com: > I just did a clean install of Qubes 3.2. For some reason the resolution off > apps in Fedora VMs is wildly inconsistent. The borders of the windows, dom0, > and the Debian VMs are correct but the apps in Fedora VMs range from > consistent with the others to so low as to be almost unusable. I can't figure > out what causes them to change and xrandr outputs the same thing no matter > what the displayed resolution is. I think this occurred for me a few weeks ago. If I recall correctly, the HiDPI settings in GNOME had somehow been set to 0. No magnification is 1, double magnification is 2. 0 gets interpreted as 2, for reasons that only the GNOME people are likely to understand. The standard GNOME procedures for changing HiDPI settings fixed it for me (I restored it to 1). Sorry I don't have more details for you, I don't believe I wrote down the fix at the time. -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a60c47f9-0a8e-e671-8abf-77f034a3ae25%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Qubes 3.2 - Missing prompt: 'Edit Applications' - Problem creating Whonix Disposable vm (dvm)
qer...@tutanota.com: > > I am following this guide: > > > > > https://forums.whonix.org/t/using-whonix-workstation-as-a-disposablevm-dispvm/2461 > > > > I have created the whonix-ws dvm template but am unable to create a usable > dvm like in the aforementioned guide, primarily because there is no 'edit > applications' prompt and I have not been able to discover the new way of > editing applications. Is there a way to edit applications like in 3.1 or must > a different process be followed to create whonix-ws dvm for tor browsing? Hi, Might this be a KDE/XFCE difference? I'm using KDE with Qubes 3.2 and the "Edit Applications..." option is present for me. Cheers, -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/72c4ca1e-6a6f-89ca-694c-7875bdfe1e72%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] philosofy on qubes and other environment
pleom...@gmail.com: > philosofy of qubes is that you are safe when your app is isolatet.This is > wrong just keep app in sandboxes or jails and what wrong can be happen? Thanks for the spamfest. Looks like my null-routed email address list finally has someone other than Drew in it. Next time you feel tempted to send a ridiculous number of 1-line emails to a mailing list, please don't. There are those of us who actually have useful things to be doing. Cheers, -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/eb16d477-fcd5-117e-d26d-24d29a0e079e%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Thoughts about installed software
Rusty Bird: > Hi Robert, > >> However I would not use the "move to VM" command like this, as I >> experienced those requests getting lost One time files were >> actually deleted, since that time I always use copy instead of >> move. > > Sounds troubling. Do you remember the last Qubes release version > where you experienced this kind of data loss? > > Rusty In Qubes 3.0, I noticed that source files for the "move to VM" command would be deleted even if the move failed due to insufficient disk space in the destination VM. (It goes without saying that this is a Very Bad Thing.) I'm not sure if this is still the case in newer releases of Qubes. Cheers, -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6ba93f84-206a-303e-e608-262b10a79f97%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] ANN: Qubes network server
Manuel Amador (Rudd-O): > Folks, it gives me great pleasure to announce the product of over two > years of work (primarily because I never paid enough attention to this > project to bring it to completion): Qubes network server. > > The traditional Qubes OS networking model contemplates a client-only use > case. User VMs (AppVMs or StandaloneVMs) are attached to ProxyVMs, which > give the user control over outbound connections taking place from user > VMs. ProxyVMs in turn attach to NetVMs, which provide outbound > connectivity for ProxyVMs and other user VMs alike. > > Qubes network server changes all that. With the Qubes network server > software, it becomes possible to make network servers in user VMs > available to other machines, be them peer VMs in the same Qubes OS > system or machines connected to a physical link shared by a NetVM. You > get actual, full, GUI control over network traffic, both exiting the VM > and entering the VM, with exactly the same Qubes OS user experience you > are used to. > > This is all, of course, opt-in, so the standard Qubes OS network > security model remains in effect until you decide to share network servers. > > Anyway, without further ado: > > https://github.com/Rudd-O/qubes-network-server > > Real easy: clone, build, install, test. I tested it with Qubes 3.1, but > it's very likely that it'll work fine in Qubes 3.2. I recommend you > test this on a Qubes machine that is not your main Qubes machine, but > the code does not do anything funky, and uninstalling the program should > be enough to revert your system back to its original state. > > I hope we can turn this add-on into a core Qubes feature. As always, > contributions to the project — reports, code enhancements, pull > requests, other items — are very much welcome! Ooh, nice! This should be a huge benefit to usability for these use cases -- while manual port forwarding via iptables is a thing, it's really error-prone and time-consuming to debug. Thanks for your work on this. (For anyone wondering, I haven't tested it due to lack of time at the moment.) Cheers, -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7ad3b276-56da-65fa-c62c-40dcb64a120a%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] HVM linux creating problem
m.j.p@gmail.com: > hello, i'm just starting with qubes and wanted to have vm with intellij > installed. > > i've choosen hvm to have my working apps only on one vm than via template. Why are you using an HVM for that rather than a PV StandaloneVM? Am I missing something? Cheers, -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/92badd62-a612-c8e7-1584-5190e4b4e14d%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] QVM Manager restart fails periodically
raahe...@gmail.com: > On Tuesday, October 4, 2016 at 12:13:38 PM UTC-4, cubit wrote: >> 4. Oct 2016 16:04 by jerem...@airmail.cc: >> I can confirm that I encountered this today. It was with a VM that had >> been running for several days. I've encountered the same error (or one >> similar to it) in the past when trying to shut down a VM that takes a >> long time -- Qubes Manager asks me if I want to kill it, and if I say >> yes, sometimes there's some apparent race condition and the error comes >> up (I guess because the VM finished shutting down right before Qubes >> Manager tried to kill it). >> >> >> >> >> For mich I do not see any request to kill the AppVM and the uptime of the VM >> is very low. for example 50 minutes when I was testing the function to try >> and get it to error. > > happened to me a couple times, when I tried to restart sys-usb and shut down > sys-net at the same time. Sys-usb would fail to start ask me to kill it, > saying there is a possible bug in qubes manager. > > Now I just wait for sys-net to fully shutdown, wait a sec and then restart > sys-usb and haven't had the issue. Yes -- like a lot of race conditions, it happens more often when the system is under heavy load. I see this behavior more often when starting/stopping multiple VM's at once, or when the system is otherwise under heavy CPU or I/O load. Cheers, -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/db9eb038-5d34-e901-5ebc-f4039a067824%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] QVM Manager restart fails periodically
cubit: > 4. Oct 2016 12:31 by a...@qubes-os.org: > >> Thanks for the report. Tracking: >> >> https://github.com/QubesOS/qubes-issues/issues/2362 >> > > > > > Some unscientific testing. > > > > > Trying a restart after 15 minutes of not doing a restart and the function > works as expected > > > > > Trying a restart after 50 minutes of not doing a restart and the function > fails the first time with the error as mentioned previously. I can confirm that I encountered this today. It was with a VM that had been running for several days. I've encountered the same error (or one similar to it) in the past when trying to shut down a VM that takes a long time -- Qubes Manager asks me if I want to kill it, and if I say yes, sometimes there's some apparent race condition and the error comes up (I guess because the VM finished shutting down right before Qubes Manager tried to kill it). Cheers, -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c5220077-a2ec-382a-d6b5-06d937b93bf2%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: I can't disable ipv6 on Debian Template
nishiwak...@gmail.com: > Uh ok, this ipv6 listening on my template set me in full paranoid mode. I > have found disappointing to see ipv6 wasn't disabled on Debian template, but > yea sorry, I went completely mad & full retard mode about Qubes on the rest. > > I thought I was betrayed. I have been betrayed a lot by relatives but that > doesn't mean I'm supposed to react like a dumbass and think of conspiracy if > I got one port listening... Sadly my imagination went crazy mode. I guess you > can call it a defense mechanism, but nevertheless, I am sorry about that. > > My boot problem is in fact related to "sudo dd if=/file.iso of=/dev/sdX" ends > up burning a UDF partition that refuses to boot. I tried your advices except > the ArchLinux one, but I guess I just have to keep trying. Also I read > somewhere I need to enter "bs=512" to burn more little fragments than the > original size to avoid boot problem with UDF. This might fix my issue, I will > try tomorrow. > > Fun part is that I want to go back to Windows only very briefly, to install > my mouse drivers and fix its sensitivity being too fast, as Linux drivers are > really painful to install for this model (I did it on Debian, it took me a > lot of efforts to make it work). > > Then I think I will probably join back in the future Qubes, as indeed it is a > very innovative OS. It's just I am interested on trying BSD systems. I found > a great guide to learn Korn shell scripting, watched all videos > https://m.youtube.com/playlist?list=PLCAFDE9B81B30388E > It was very interesting and very well made, allows you to understand better > how command line work and the logics behind programs ! > > In fact I just want to learn to use a different Unix-based system than Linux > and try there what I have learnt on this great tutorial. It's easier when > your mouse isn't on steroids ^^ Sincere apologies for making the inference about the agenda thing. Cheers, -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/01c8c10c-fac3-63dc-a349-727aaa0d78cf%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: I can't disable ipv6 on Debian Template
nishiwak...@gmail.com: > I won't wait another week with my HDD disabled by this OS. I'm trying to figure out if this is a veiled threat of some kind...? FWIW, I've booted from USB drives while Qubes was installed internally before. I'm under the impression that lots of people here have done so. So perhaps you might want to consider the likely possibility that there is something different about your setup compared to mine (and everyone else's whose setup works fine), rather than this being a deliberate attempt by Qubes developers to "make [sic] hostages". Then again, based on your other posts in this thread, it's likely that I'm wasting time trying to reason with someone who has an entirely different agenda than getting an actual bug fixed. I won't be bothering to engage further if additional posts support that conclusion. Cheers, -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3a46a661-d4bf-ea8b-5ff1-ba4f65520be3%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] sys-firewall no longer works after creating new Net VM
neilhard...@gmail.com: > I created a new Net VM, in order to use Debian, and it works fine. > > But now I want to revert back to sys-net. > > The problem is that my sys-firewall no longer works. > > How do I get sys-firewall to work again? > > It starts up fine, but simply doesn't work. Other App VMs are not getting > data through it. > > Thanks. Been a while since I did this, but I believe that if you create a new VM and specify "ProxyVM" as the type instead of "AppVM" or "NetVM", you'll wind up with a VM that has similar (or identical?) configuration as sys-firewall. Cheers, -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7df5acf9-3db3-ca97-d0c8-d6357eed6873%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Available memory
York Keyser: > Hi group, > > I have a short, maybe stupid question, where or how can I see the > available memory. Not the memory of each VM I need to know how much > memory is availably global wide. (Short-term and Long-term memory) > > Regards York Last I heard, there isn't an easy way to see the total available RAM in all VM's. Maybe some progress happened there and I haven't heard? It would certainly be a useful feature. Cheers, -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8f7dd740-bdba-3337-f464-f2f507f34e48%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: Qubes Windows Tools
Achim Patzner: > Am 28.09.2016 um 10:06 schrieb Drew White: >> On Wednesday, 28 September 2016 17:47:01 UTC+10, Foppe de Haan wrote: >>> On Wednesday, September 28, 2016 at 8:20:29 AM UTC+2, Drew White wrote: Why does QWT require TESTSIGNING to be turned on? Is that because Win7 requires things to be signed? >>> https://www.qubes-os.org/doc/windows-appvms/ >>> "Before proceeding with the installation we need to disable Windows >>> mechanism that allows only signed drivers to be installed, because >>> currently (beta releases) the drivers we provide as part of the Windows >>> Tools are not digitally signed with a publicly recognizable certificate." >> Still doesn't answer that question either. >> >> I said "hi devs" because I needed someone with the knowledge of WHY, not >> just an end user reason, but a dev description that is technical. > > Which part of "we don't provide signed drivers so if you want to run > them you have to turn that requirement off" needs a developer to make > you understand it and what kind of LART do you expect said developer to > use for beating some sense into you? It's clear, it's precise and unless > you need a translation into another language there is not much anyone > could do for you. Please keep the developers doing something more > important than correcting your refusal to accept facts. > > > Achim > It occurs to me that although I've re-routed messages from Drew to /dev/null for quite a while (thus saving me from reading that drivel), I didn't do so for messages that reply to him. I think I'm actually okay with that oversight, as now I get to enjoy reading 3 different people explaining to him why his messages are the type of message that resulted in me null-routing him, but I don't have to subject myself to reading whatever replies he comes up with. (On that note -- kudos to the 3 of you who managed to reply to him, explaining in reasonable detail why he's off base, without losing your sanity. Quite impressive.) Cheers, -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f180040c-2a30-c5be-6f84-6b6f056c2abf%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] "Carrying forward" a DMA attack..?
raahe...@gmail.com: > On Tuesday, September 27, 2016 at 5:11:27 PM UTC-4, Jeremy Rand wrote: >> raahe...@gmail.com: >>> or just only allow https in the vm firewall settings. >> >> I assume you mean whitelisting TCP port 443? If so, be aware that while >> this will stop most non-HTTPS traffic, there is nothing that prevents >> other protocols from using port 443. It's a fairly well-known attack on >> Tor's "stream isolation by port" feature for websites to use nonstandard >> ports in order to get isolated in the wrong Tor circuit (e.g. in order >> to deanonymize SSH traffic), which is why Tor doesn't stream-isolate by >> port by default. >> >> Whitelisting TCP port 443 is still better than nothing, though, assuming >> that you don't expect any legitimate traffic to go over other ports. >> Just be aware that it's trivially easy to bypass for an attacker. >> >> Assuming that you're using a Firefox-based browser (including Tor >> Browser), you can get some defense in depth by also enabling the feature >> of HTTPS-Everywhere that blocks all non-TLS requests. Nothing wrong >> with combining this with the firewall whitelist that you suggested. >> >> Cheers, >> -Jeremy > > oh I see now there is the feature in the plugin ive never used lol. I still > think its unescessary if you already blocking that traffic with the firewall, > especially if that plugin or browser is compromised, especially with latest > news about firefox plugins. For example noscript itself is considered a > vulnerability on firefox now. As I said, it gets you defense in depth because the two mechanisms prevent different (though overlapping) attacks. HTTPS Everywhere's feature for blocking non-TLS requests will block non-TLS requests from Firefox that use port 443, while the FirewallVM won't be able to stop this. For example, a request to http://www.nsa.gov:443/ will be stopped by HTTPS Everywhere, since it knows the protocol being used as opposed to just the TCP port. The FirewallVM, on the other hand, will block TCP connections on ports other than 443 even if Firefox in the AppVM is compromised. E.g. you visit https://www.nsa.gov/ , they deploy a Firefox zero-day, and are thus able to bypass HTTPS Everywhere. Both of these attacks have a lot of overlap (e.g. a simple request to http://www.nsa.gov/ will be blocked by both). But each defense does prevent some types of attack that the other doesn't, so it makes sense IMO to use both. Definitely won't hurt you, and it might help depending on what attacks get aimed at you. (Of course, either of those defenses alone is likely to prevent the vast majority of real-world attacks, but I'd still suggest doing both. Justified paranoia is why we're all here, right? :) ) Cheers, -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6560bf5f-8710-40e8-0a14-be32c57adae3%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: I can't disable ipv6 on Debian Template
johnyju...@sigaint.org: >> The "listening" services are less of a concern, since the firewall >> wouldn't permit any incoming connections to be passed through to start >> with. It's the "phone home" style services, like time sync, Samba name >> lookups on microsoft servers, and such, that are more concerning, and >> privacy-busting. > > The paranoid part of me (which is about 95% of me) half-suspects that NTP > is actively monitored by the powers that be, to keep tabs on us > security-minded Linux geeks. > > There's been enough major security bugs in NTP, that one must wonder if > they're akin to the heartbleed/rng/SSL/etc. compromises that don't > necessarily look like innocent mistakes. > > Qubes is good at trying to get dom0 to push the time to the VM's by its > own means. And if you set the ClockVM to sys-whonix, say, you remove, or > at least greatly reduce, the ability of TPTB to track your setting your > clock. :) > > However, as mentioned, the default of using NTP time syncing is enabled by > default in the Debian-8 template, which defeats that protection for Debian > Appvms, unless you disable it in the template. Just an oversight, I'm > sure. (No sarcasm, for once.) > > My PC's RT clock might drift by a few seconds each week, if that; I'm not > sure why time synchronization has to be so damn frequent and aggressive. > A red flag for the paranoid. :) > > I have a RS232 GPS dongle that spits out the time with 1-second accuracy > (or atomic-clock level accuracy, if you use the 1-second clock-tick signal > available on one of the chips, which I have done, lol). > > I plan on hooking that up to my Qubes setup in the near future, and > disabling network-based clock sync all together. > > (Until Qubes 4.0 comes out, forces me to upgrade to a newer motherboard > with no RS232 support. :) ) > > Might be a good open-sourced hardware project. I think I've seen some out > there already, although not necessarily integrated smoothly into Qubes. > > Just one more hole to make sure we plug. > > JJ You might find Jake Appelbaum's tlsdate interesting, or Adam Langley's Roughtime. Both are quite a bit more secure than NTP, although tlsdate doesn't work with TLS 1.3, and Roughtime is still a proof of concept. Cheers, -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6179d0f8-9f5b-5180-70dc-b60aec8c0aae%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] "Carrying forward" a DMA attack..?
raahe...@gmail.com: > or just only allow https in the vm firewall settings. I assume you mean whitelisting TCP port 443? If so, be aware that while this will stop most non-HTTPS traffic, there is nothing that prevents other protocols from using port 443. It's a fairly well-known attack on Tor's "stream isolation by port" feature for websites to use nonstandard ports in order to get isolated in the wrong Tor circuit (e.g. in order to deanonymize SSH traffic), which is why Tor doesn't stream-isolate by port by default. Whitelisting TCP port 443 is still better than nothing, though, assuming that you don't expect any legitimate traffic to go over other ports. Just be aware that it's trivially easy to bypass for an attacker. Assuming that you're using a Firefox-based browser (including Tor Browser), you can get some defense in depth by also enabling the feature of HTTPS-Everywhere that blocks all non-TLS requests. Nothing wrong with combining this with the firewall whitelist that you suggested. Cheers, -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8d47d4b9-7ed4-84f4-e697-13db24877024%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] backup
'Gabriel' via qubes-users: > Hi fellows, > > I started using qubes a while ago and I have a question concerning backups. > What I want is a complete backup to a dedicated external USB HDD. I > understand to achieve this all the VMs must be shut down. > Therefore when I plugged in the HDD I mounted it in dom0 under /mnt. You can backup a subset of VM's from the GUI. I typically backup every VM except the USB VM (with the external HDD attached to the USB VM and mounted in a DispVM), under the assumption that if I'm ever restoring to a fresh Qubes install, there will already be a USB VM there, so backing up the USB VM isn't really needed. Cheers, -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/58032d10-22a7-7c1b-8ee1-bd95c4ba563a%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Does anyone use a dedicated Tor router box..?
neilhard...@gmail.com: > Does anyone use a dedicated Tor router..? > > The theory is, Tor is secure, but Firefox is not. > > Therefore, you have 1 computer that runs Tor only, and a WiFi hotspot... > Another computer runs Firefox and any other programs. > > So long as the other computer connects to the Tor computer for network > access, it doesn't matter if it gets hacked, because your real IP address > never leaks. > > Qubes implements this somewhat by separating the Whonix Net VM and App VM. > > However, the problem with Qubes, of course, is all the Xen exploits which > make it insecure. > > If you were hacked in Qubes, the hacker could easily then leak out your real > IP address. > > But if you were hacked behind a physical Tor box, your real IP can never > leak, unless the Tor box itself can be compromised... And as far as we know, > there are no exploits for the Tor network itself, only for Firefox. > > I would use Qubes for the Tor box and the other box, if only for the VT-D > protection, although maybe there are other free Linux OSs that have VT-D > protection. > > What do you think...? Has anyone tried doing this..? How did it work out...? I'm pretty sure that I recall the Whonix people doing some experiments with running the Workstation and Gateway on 2 physical machines instead of 2 VM's. I've never tried those instructions, and I don't know if that setup is still maintained, but yes, it has been thought of. Also, I think SecureDrop uses 4 physical machines, 1 of which runs Tor and another of which runs the hidden service, a 3rd of which is offline completely (I can't remember the purpose of the 4th offhand). So it's fairly similar to a Qubes setup in many ways. Cheers, -Jeremy Rand -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/bc34773a-c275-b87d-f550-ba2bfd9ed539%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Salt InterVM Configuration explorations and pitfalls in 3.2-rc2
nekroze.law...@gmail.com: > On Tuesday, August 30, 2016 at 12:57:54 PM UTC+10, Jeremy Rand wrote: >> Seems to me that an attack could be constructed where the Tor exit used >> for update downloads feeds sys-whonix an exploit, and from there is able >> to either break out of Tor, or compromise Tor in some way that may >> affect other VM's' anonymity. > > Forgive me if I am misunderstanding the scenario you proposed, but the setup > in question "sys-net>sys-firewall>sys-whonix>sys-update" If dom0 uses > sys-update to pull updates we should be ok. The default for when qubes is > told to use whonix/tor for updates however is > "sys-net>sys-firewall>sys-whonix" with sys-whonix being the update VM if I > remember correctly. In that case dnf/yum is in fact running in a whonix VM > (which as you mention might be a security issue) and the previously discussed > method should prevent that, however as Marek mentioned it is not the default > because it would require the addition of another appVM and the base setup > should be as minimal as possible. Not everyone has 16+gb of ram. Yes, you understand the scenario I suggested correctly. I agree with you and Marek that, for users with less RAM, it may be an acceptable tradeoff to run the update in sys-whonix. However, there are some users who either have a lot of RAM or are willing to shut down other VM's while performing dom0 updates in order to gain some extra security, and I think it would be reasonable for those users to use a "sys-update" VM for dom0 updates. I also think that this is something that might make sense to ask the user on Qubes install, and automatically configure "sys-update" if the user opts for the extra security. The attack surface probably isn't massive here. But I always like reducing attack surface when feasible, and using a "sys-update" VM seems like a decent way to do so. If Marek (or perhaps Patrick) disagree with me that there's a security vs RAM usage tradeoff, I'd be very interested to hear their analysis on this. Cheers, -Jeremy Rand -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ce619a10-ecc2-3b31-85f2-f0d28afdcbb1%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Salt InterVM Configuration explorations and pitfalls in 3.2-rc2
Marek Marczykowski-Górecki: > On Wed, Aug 17, 2016 at 01:42:36AM -0700, nekroze.law...@gmail.com wrote: > >>> In any case, if you put Fedora-based VM behind sys-whonix, and set it as >>> UpdateVM, it should work. > >> That does indeed seem to fix the problem. Is there a reason why the whonix >> setup choice that uses whonix for dom0 updates not also build an update vm >> that uses sys-whonix and is based off of fedora? > > Basic actions (install updates, new packages) should work in this setup > and it save some RAM (no need for additional VM in addition to > sys-whonix). Seems to me that an attack could be constructed where the Tor exit used for update downloads feeds sys-whonix an exploit, and from there is able to either break out of Tor, or compromise Tor in some way that may affect other VM's' anonymity. Granted, this is a fairly lousy attack as attacks go, but isn't the entire point of Whonix that nothing is supposed to run inside the Whonix gateway except Tor? Cheers, -Jeremy Rand -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6d9feec4-a205-dc21-9158-bad70538f8ee%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
[qubes-users] Multiple monitors partially broken in Debian and Whonix AppVM's
If I install LibreOffice in a Fedora 23 Template using Qubes 3.2, the "Presentation Display" setting works properly with no issues, so I can see my notes on my main display and the presentation shows up on my external display. However, this doesn't work properly under Debian 8 or Whonix 13. It seems that both the notes window and the presentation window show up on the main display, and are forced to the resolution of the main display. I can drag the presentation window to the external display and maximize it, but its window size remains at the resolution of my main display. Since my main display is much higher resolution than the external display, the result is that the presentation appears zoomed in, with much of the border cut off. Note that I'm using the jessie-backports version of LibreOffice in my Debian/Whonix VM's. Any idea what might be causing this? Cheers, -Jeremy Rand -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/50eefa6e-6b57-deea-2c5f-1d6f570da464%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Qubes VM compromised? - Follow up
johnyju...@sigaint.org: > >> I just use Whonix within Qubes and I like it. I'm glad it comes out of >> the box since 3.1 > > I've retreated to only using Fedora. Setting up Tor and Firefox (with > noscript, ssl observatory, adblocker) to use it as a proxy is essentially > the same effect as Whonix (or tbb). Even if tor/firefox are on the same > vm rather than separated, you're behind sys-net and sys-firewall, so your > real world address isn't going to leak. Another two VM's on top of that > (whonix-gw and whonix-ws) is a bit of overkill IMO, and a memory pig. Running Tor in the same VM as the browser won't keep your public IP from leaking to the same extent as using Whonix. For example, if Firefox gets pwned, it can simply generate a request to whatismyip.com without going through Tor, and then send the result to whoever it likes. (Unless I'm misunderstanding what you're doing.) Cheers, -Jeremy Rand -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/204c1635-520a-e9c4-aa87-edc40e59b59f%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Unnecessary things in dom0/templates?
arthur.summ...@gmail.com: > I just updated dom0 and saw a few packages - avahi and openssl - that made me > curious as to why they are there. I'm all about having a lean system, so I > remove things where and when I can. If there's a reason for these things > being there, then that's cool, but since dom0 is network-isolated, that > struck me as a little odd. > > I'm also curious to know if other people have thoughts on certain packages > and why they're included (in dom0 or in templates), so feel free to list them > on this thread. OpenSSL is used for lots of things that aren't network-related. I'm under the impression that OpenSSL is used for the Qubes backup/restore system. A Qubes devloper would be able to answer with more certainty. -Jeremy Rand -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9cbde4a0-027d-7f5b-c6eb-6ca87e744369%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: Fedora 23 template not updating - with a blank screen
48juya+35xih7kuzgagg via qubes-users: > It seems that doing a 'dnf update --refresh' it provides some output but > updating the repositories is taking forever: > > [root@fedora-23 ~]# dnf update --refresh > RPM Fusion for Fedora 23 - Nonfree > 1.1 MB/s | > 156 kB 00:00 > RPM Fusion for Fedora 23 - Free > 3.8 kB/s | > 457 kB 02:00 > Qubes OS Repository for VM (updates) > 1.0 MB/s | > 286 kB 00:00 > Fedora 23 - x86_64 - Updates > 199 kB/s | > 24 MB 02:03 > > > Its hanging for more than 15m now, any ideas how to solve this? Coincdentally, this occurred to me about 20 minutes ago. Restarting the fedora-23 TemplateVM and trying to update again fixed it for me. Might have been a server issue on Fedora's end. -Jeremy Rand -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e39a5b17-d83a-977e-a760-2125c24d2d3b%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] USB Root Drive Corruption
johnyju...@sigaint.org: >> This problem persists in 3.2rc2. >> >> (And I get 0 errors on the same USB drive under Tails. When I can find >> the SATA power connector around here somewhere, I'll try moving the drive >> direct onto the SATA bus.) > > I think the problem *may* be that systemd has a default 90 second timeout > on jobs, including unmounting root. > > On an external USB drive, due to slower transfer times, the shutdown > process of all the VM's, killing processes, flushing buffers, etc., > happens to take long enough that a clean unmount of the drive doesn't get > a chance to occur, leaned to a corrupted filesystem. > > If I shut down each Appvm manually before finally doing the reboot, the > work left to do on shutdown lets the unmount occur with in 90 seconds, so > the drive shuts down cleanly. > > I think that's what I've been seeing, anyway. There's a lot of disk > activity while systemd talks about outstanding jobs, and while the time > remaining of waiting for the jobs, ticks down to zero. > > Now, why the fsck on boot fails (and things fall into r/o mode, and fail > thus hang the boot sequence), I'm not sure. It could be a similar > problem, that startup jobs aren't happening within the 90 second default > job window for systemd (due to slower USB transfers, and the time taken > for the fsck), and the boot process gives up. > > People with internal drives and killer machines wouldn't see this issue. > > I'm going to try cranking up DefaultTimeoutStartSec and > DefaultTimeoutStopSec in /etc/systemd/system.conf, and see if that > improves the situation. I'll also scrutinize systemd-analyze (which I > just learned about, being an old-school /etc/init.d guy, lol) and see if > that confirms my suspicions. > > Cheers, > > JJ This might explain why I didn't see this behavior, because the external USB drive that I booted 3.2rc1 from was a USB3 drive that internally used RAID0, so it's probably faster than most. Might I ask whether your external USB drive was USB2 or USB3, whether it was an HDD or SSD, and whether it used RAID0? Cheers, -Jeremy Rand -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/168f1392-c917-c2f7-ce6f-70236a734eab%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] USB Root Drive Corruption
johnyju...@sigaint.org: > Well, my wild enthusiasm with Qubes has turned into complete frustration > and exasperation this morning. > > The "mild" corruption I was seeing on boot (running Qubes from a USB 2.5" > HD) wasn't quite so mild the last time I booted. > > This time, rather than "recovering journal... done," the fsck spewed more > than I've ever seen an fsck spew, and the filesystem was trashed. /var > ended up as a symlink to liblber-2.4.so.2.10.2. I found /var/lib/qubes in > lost+found (along with 350 other directories). Argh! > > I'd highly recommend that nobody run Qubes 3.1 from an external USB drive. > > I'm going back to another OS as my daily system. > > I'll probably give Qubes 3.2rc a try on an internal hard drive, as a > secondary OS, to see if that solves my HD and video corruption issues. If > not, I'll probably wait for Qubes to mature a bit more before using it in > any serious manner. I've run Qubes 3.0rc1 and Qubes 3.2rc1 from an external USD hard drive (for about a month each). 3.0rc1 encountered kernel panics about once per day (which wasn't the case when run from an internal drive) and booted much slower than from an internal drive, but I didn't notice any obvious drive corruption from it. 3.2rc1 had no issues whatsoever and wasn't much slower than internal. I haven't tried any release of 3.1. So, my guess is that the issue you're encountering either was fixed between 3.1 and 3.2rc1 (and didn't seem to exist in 3.0rc1), or is in some way unique to your setup. Maybe a hardware issue? Cheers, -Jeremy Rand -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/df5ff24c-c6ce-8dda-dfac-5f07bea4f9c0%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Question about Whonix / Tor Browser / exploits
neilhard...@gmail.com: > I have a question about Whonix/Tor Browser exploits. > > I have played around a bit with Metasploit to see how browser exploits work. > > They basically rig a web page with exploits, and then it does what's known as > "arbitrary code execution", to open up a "remote shell". > > As far as I can tell.. the remote shell is running in the browser's RAM. They > are essentially hi-jacking the browser's RAM, and using it to run their own > remote shell. > > The hacker then usually loads a file from the remote shell, onto the > computer's hard drive, in order to obtain persistence... As soon as the > browser tab closes, the remote shell is gone, hence why they need persistence. > > So my question is about persistence. > > Is it possible to simply remove the hard drive altogether from Whonix, to > prevent them achieving persistence...? > > I know that TAILS simply doesn't have a hard drive at all. > > Would this be useful to have in Whonix..? To remove the hard drive > altogether, perhaps in VM Settings in QUBES...? > > Or is it possible to run a Xen exploit purely in the browser's RAM anyway...? > Thus, they don't even need a hard drive because they can just run the exploit > in RAM anyway...? > > So the main question is really whether they can run the Xen exploit in RAM > anyway or not If not, then surely removing the hard drive itself > would be useful...? > > Hopefully you understand my question. It's possible to use Whonix as a DisposableVM (although it's not the default configuration of a fresh Qubes installation), so in theory any exploit placed in the VM will disappear when the VM is closed. This would, presumably, mitigate persistent malware placed via Firefox exploits, but won't help against malware that combines a Firefox exploit with a Xen exploit. It still seems like an improvement against the default configuration. Cheers, -Jeremy Rand -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/49652994-14ed-c71c-3f0a-9c595d304940%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] MicroSD assigned to dom0 and not to sys-usb
Marek Marczykowski-Górecki: > On Mon, Aug 01, 2016 at 07:35:26PM +, 468ezc+5r0fnwy87qeag via > qubes-users wrote: >> Hi, > >> My MicroSD while attached is assigned to dom0 and not sys-usb as is >> supposed. Notwithstanding, USB devices are still assigned to sys-usb. > >> Is this the intended behavior? Doesn't this increases, in the same manner as >> usb devices does, the surface attack in dom0? > > Your (micro)SD card reader is probably not a USB device, but PCI device. > Yes, it's better to assign it to some VM - sys-usb is ok. You can do > this in VM settings - "Devices" tab. Seems to me that assigning the SD controller to a different VM than sys-usb would eliminate some attack vectors, since if they're assigned to the same VM, IOMMU won't prevent software accessing the SD card from attacking software accessing the USB devices (and vice versa). A doomsday scenario that comes to mind is when the USB controller is being used to connect to the Internet via a phone tether, and the SD card is storing some high-value data. (My doomsday imagination is limited; perhaps there are better doomsday scenarios.) Is my intuition on this corect? Of course, using a separate VM means increased RAM usage, which may or may not be worth it. Cheers, -Jeremy Rand -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/33219161-b369-6ddc-b4b2-f9e75310881d%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: [qubes-devel] Window border colors
Marek Marczykowski-Górecki: > On Wed, Jul 27, 2016 at 09:53:00AM +0000, Jeremy Rand wrote: >> 45in10+d44wd6z0yzqcg via qubes-users: >>> The proposed workaround solved part of the issue, however I'm still facing >>> issues with application windows that are not displayed as outlined on my >>> previous comment: >>> >>> Since this update every time a command is launched, when the respective >>> AppVM is down, the window is not displayed and the AppVm shows as being in >>> a transient state (for instance, when launching the gnome-terminal, the >>> terminal console only gets displayed after another instance of >>> gnome-terminal is launched, then two terminal console windows are displayed) > >> I think this is an independent issue. It's been happening to me >> intermittently for at least a week prior to the update that broke the >> window border colors. In fact, I think it's been happening to me >> intermittently since I started using 3.2rc1. > > I think this is another instance of this: > https://github.com/QubesOS/qubes-issues/issues/2085 > > When it happen, check /var/log/qubes/guid.VMNAME.log.old for something > like: > XDestroyWindow 0x5e5 > ErrorHandler: BadWindow (invalid Window parameter) > Major opcode: 10 (X_UnmapWindow) > ResourceID: 0x5e5 > Failed serial number: 194 > Current serial number: 197 > > Hi Marek, I was able to reproduce this today. The requested log file is pasted below: Icon size: 128x128 invalid PMinSize for 0x724 (0/0) invalid PMaxSize for 0x724 (0/0) invalid PResizeInc for 0x724 (0/0) invalid PBaseSize for 0x724 (0/0) invalid PMinSize for 0x725 (0/0) invalid PMaxSize for 0x725 (0/0) invalid PResizeInc for 0x725 (0/0) invalid PBaseSize for 0x725 (0/0) invalid PMaxSize for 0x725 (0/0) invalid PResizeInc for 0x725 (0/0) ErrorHandler: BadWindow (invalid Window parameter) Major opcode: 4 (X_DestroyWindow) ResourceID: 0x725 Failed serial number: 144 Current serial number: 146 The affected AppVM in this case is a Whonix WS AppVM; the window being opened was Konsole. This is on Qubes 3.2rc1 with KDE. Hope this helps in diagnosing it. Cheers, -Jeremy Rand -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/aa15ea90-962f-c585-1a36-06c5a8e19e90%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: [qubes-devel] Window border colors
45in10+d44wd6z0yzqcg via qubes-users: > The proposed workaround solved part of the issue, however I'm still facing > issues with application windows that are not displayed as outlined on my > previous comment: > > Since this update every time a command is launched, when the respective AppVM > is down, the window is not displayed and the AppVm shows as being in a > transient state (for instance, when launching the gnome-terminal, the > terminal console only gets displayed after another instance of gnome-terminal > is launched, then two terminal console windows are displayed) I think this is an independent issue. It's been happening to me intermittently for at least a week prior to the update that broke the window border colors. In fact, I think it's been happening to me intermittently since I started using 3.2rc1. -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/838684bb-e06e-59b9-d861-83dcb58d1322%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: [qubes-devel] Window border colors
Marek Marczykowski-Górecki: > On Wed, Jul 27, 2016 at 04:32:24AM +0000, Jeremy Rand wrote: >> Marek Marczykowski-Górecki: >>> On Tue, Jul 26, 2016 at 03:11:33PM -0700, Andrew David Wong wrote: >>>> On 2016-07-26 14:52, Manuel Amador (Rudd-O) wrote: >>>>> Hello. I just did an update, rebooted, and now my window borders do not >>>>> have the VM's colors. The prefix on the window title is correct tho. >>>>> >>>>> >>>>> What gives? >>>>> >>>>> >>> >>>> That sounds very strange. Have you done any kind of customization or made >>>> any >>>> changes from the defaults? For example, have you changed the colors or >>>> changed >>>> the window border style? >>> >>>> Also, are you using KDE or XFCE? R3.1 or R3.2-rc1? >>> >>> Those are important questions. >>> >>> In addition, please provide version of qubes-gui-dom0 package. And check >>> properties of some VM window using xprop from dom0 (call xprop, then >>> click on some VM window). Especially those properties: >>> _QUBES_LABEL >>> _QUBES_LABEL_COLOR >>> _KDE_NET_WM_COLOR_SCHEME >>> >>> > >> Same thing has happened to me. > >> No customizations have been done. I initially thought it might be due >> to customizations, so I reinstalled Qubes from scratch, did a >> qubes-dom0-update, and rebooted, and it happened. So definitely not due >> to customizations. > >> All the windows now appear to have the window border coloring that is >> normally associated with dom0 (gray when not in focus, cyan when in >> focus). Also interestingly, the icon of the Launcher in the Panel has >> disappeared and became solid white. (I was able to workaround it by >> right-clicking it, and in the settings dialog manually choosing an icon >> from the list.) In addition, there is now an odd icon on the left side >> of every window title bar (just to the right of the application icon) >> that I don't recall ever being there before; it looks like a 1-pixel >> thick square with the corner pixels removed. (I can provide a >> screenshot if you need it.) > >> KDE on 3.2rc1. > >> "dnf info qubes-gui-dom0" in dom0 shows version 3.2.1. > >> I did the xprop you requested, and clicked on the fedora-23 TemplateVM. > >> _QUBES_LABEL is 8. >> _KDE_NET_WM_COLOR_SCHEME is >> "/home/jeremy/.local/share/qubes-kde/black.colors". > > This looks ok. I assume the file exists too. > >> _QUBES_LABEL_COLOR does not show up in the xprop output at all. > > This is also ok in qubes-gui-dom0 3.2.1. > >> Hope this helps in diagnosing. > > Try this: > > Go to system settings -> Application Style -> Window Decorations. It > should be set to "Breeze". If it is set to "Plastik", it may be the > cause of the problems. > > If this is the case, I think this may be related to KDE update done by > Fedora recently (a lot of kf5-* packages), so unrelated to > qubes-gui-dom0 version. Yes! It was set to Plastik. Changing it to Breeze and clicking Apply instantly fixed the issues. (Well, I can't test whether it fixed the icon of the launcher, because I've already done the workaround that I described previously. But everything else is fixed now.) Thank you Marek! -Jeremy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/17fc9fcc-f323-1b34-9183-20006cd62519%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: [qubes-devel] Window border colors
Marek Marczykowski-Górecki: > On Tue, Jul 26, 2016 at 03:11:33PM -0700, Andrew David Wong wrote: >> On 2016-07-26 14:52, Manuel Amador (Rudd-O) wrote: >>> Hello. I just did an update, rebooted, and now my window borders do not >>> have the VM's colors. The prefix on the window title is correct tho. >>> >>> >>> What gives? >>> >>> > >> That sounds very strange. Have you done any kind of customization or made any >> changes from the defaults? For example, have you changed the colors or >> changed >> the window border style? > >> Also, are you using KDE or XFCE? R3.1 or R3.2-rc1? > > Those are important questions. > > In addition, please provide version of qubes-gui-dom0 package. And check > properties of some VM window using xprop from dom0 (call xprop, then > click on some VM window). Especially those properties: > _QUBES_LABEL > _QUBES_LABEL_COLOR > _KDE_NET_WM_COLOR_SCHEME > > Same thing has happened to me. No customizations have been done. I initially thought it might be due to customizations, so I reinstalled Qubes from scratch, did a qubes-dom0-update, and rebooted, and it happened. So definitely not due to customizations. All the windows now appear to have the window border coloring that is normally associated with dom0 (gray when not in focus, cyan when in focus). Also interestingly, the icon of the Launcher in the Panel has disappeared and became solid white. (I was able to workaround it by right-clicking it, and in the settings dialog manually choosing an icon from the list.) In addition, there is now an odd icon on the left side of every window title bar (just to the right of the application icon) that I don't recall ever being there before; it looks like a 1-pixel thick square with the corner pixels removed. (I can provide a screenshot if you need it.) KDE on 3.2rc1. "dnf info qubes-gui-dom0" in dom0 shows version 3.2.1. I did the xprop you requested, and clicked on the fedora-23 TemplateVM. _QUBES_LABEL is 8. _KDE_NET_WM_COLOR_SCHEME is "/home/jeremy/.local/share/qubes-kde/black.colors". _QUBES_LABEL_COLOR does not show up in the xprop output at all. Hope this helps in diagnosing. Cheers, -Jeremy Rand -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1329b606-183b-3eec-cc01-9de0bfd287d9%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Can't Boot From Win10 Retail USB
rick.jeffr...@gmail.com: > Win10 runs as an HVM; the devs haven't finished building the Windows Tools > for it. Within its limits it is fine. > I can confirm this; I've been running Windows 10 in an HVM for months with no issues. Windows Tools support would be nice, but for my use cases being able to test software I write on the latest OS release is a higher priority, so it's doing its job just fine. -Jeremy Rand -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6bfa3edf-807d-077a-4a13-126b76763b59%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Sending a directory to a DispVM?
Andrew David Wong: > On 2016-07-18 01:27, Jeremy Rand wrote: >> Hello, > >> Might there be any plans to allow sending a directory to a DispVM? Right >> now in Qubes 3.2 rc1, attempting to do so from the file manager GUI in a >> Fedora 23 template yields this error: > >> qopen-in-vm: Fatal error: send file to dispVM (error type: Is a directory) > >> The desired behavior, I think, would be to open a file manager window >> inside the DispVM that includes the full contents of the selected >> directory. This way, files could be edited in a DispVM that depend on >> other nearby files (e.g. document files that reference image files). > >> (I briefly looked on the issue tracker and didn't see any mention of this >> topic.) > >> Cheers, -Jeremy Rand > > > I think this would fall under "Allow to open more than one file in the same > DispVM": > > https://github.com/QubesOS/qubes-issues/issues/814 Thanks Andrew! Yes, that issue looks like a superset of my suggested use case. > > As Marek says in a comment on this issue: > >> Current "open-in-vm" protocol allow only to pass one file, because we want >> the protocol simple AND allow to pass possibly modified file back. > > I've added your comment to this issue. Please note that it's a "help wanted" > issue, so it's unlikely to be implemented without help from the community. Sounds good. I know you guys have a roadmap and priorities, and I definitely trust you to make the call on what gets developer attention and what needs community assistance to be implemented. Cheers, -Jeremy Rand -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/34c6616f-4e69-edde-8a31-fd8aa5c42508%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: Unable to install 3.2-rc1 on Thinkpad T450s
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/27/2016 04:45 AM, 41zxmg+5qvzr7o3u2us via qubes-users wrote: > Jeremy, > > You are awesome, that does work indeed. The tutorial is a bit > unclear, but when I add this as two separate lines it works > smoothly :) > > > Many thanks :) Glad I could help, and that the hours I spent tinkering with it (literally just a few hours ago) helped someone other than just me. :) Cheers! - -Jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJXcPgKAAoJEAHN/EbZ1y06a8oP/1xwx5yrc+WxuoyvXnJ9uI9l lGfTk1uvOSIIqovKcp1z63mZveUrPpXUdeMeahzK5QCChTcyc3w9Vvqj8ezPe/ST tYeWTdVIMi3V/w+S6pEP0g1F4jtbmvBwFAORPWmqka2mzTa23UoZc6Xu/4BJIiPU QMNsOr0pbuaxvHwJ6Srm/NYTRf557ztg+4W+pcwiEZXQQxFzKQKBGkbqEFcoKU1Q Qt4B027n9OHxX3uftyho9cwXcPpPj3W/9h6ZIDt3WbJuAbmi5zjWIXDlfsPQS+sZ fm7HNa7mVgMMMjmf24+/g23br/X3IFhxHIO6lzFZOeUb1Jn8tjKU0EwsSXArCcQS Cg31NACvBlk1o5vVs76zDw155i5BY7y/ErdxpwHDBSZPl4MYeo9iyYJ3mHnlXUkM 0qYKGdXFJXTw4MpbD7LvwFhg7MfkM+XCSdc/eK4sJnoGfhNBOhM+KPrS/cVpbIlF WOTj83lcPPz7bTkRO7dWqzxo9b9Jlu/MfbVAKztI8NLvhJdtWLwkEaJV48ZMIMiZ uMIOdgHkIebiwdGG3ycKOiDXGPkC7WHUlkS7vwrkcgwGB2BSUu6sP4CN7NY0G0V/ R/SNq3INa5w/2kbZdTz61Qd5cB3SZX/YMyTHgwStDLYd7HRIWnFu9LLpG1KWzU/F Kq/c/23jdnjKsw1p54LH =RtGv -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/62ccfafe-117d-3e32-d417-7024e2862b00%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Unable to install 3.2-rc1 on Thinkpad T450s
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/27/2016 04:23 AM, 41zxmg+5qvzr7o3u2us via qubes-users wrote: > Thanks for the suggestion but this doesn't relate to the problem at > hands. > > At this stage I'm simply not able to install Qubes 3.2Rc1 due to > the UEFI implementation from lenovo. I followed the indications > posted in this article > (https://www.qubes-os.org/doc/uefi-troubleshooting/) and I was able > to install Qubes (passing the kernel parameters /mapbs > /noexitboot). However after the installation is completed and after > enabled the same corresponding parameters (mapbs=1 noexitboot=1) on > the installed system into /mnt/sysimage/boot/efi/EFI/qubes/xen.cfg > I'm not able to boot the new installed system as this hangs on the > same four penguins that were showed during the installation. > > Thus, I suspect added kernel parameters on the xen.cfg are not > being passed. > > Any ideas how to solve this? I don't know if this is your issue, but the instructions are a bit ambiguous. I initially tried adding those params to the end of the "kernel" lines, but they had no effect. You actually need to add the params on 2 separate new lines (1 line per param), at the end of each section that includes a kernel line. (I.e. all sections except the first one, because it doesn't have a kernel line.) @Andrew David Wong, any chance those instructions could be made a little bit more clear? I'm totally okay with the fact that I lost a few hours debugging this (I'm using a release candidate, after all), but I imagine some users might find this frustrating. Cheers, - -Jeremy Rand -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJXcPKfAAoJEAHN/EbZ1y06N9YP/2TR/IejUyrsGLvVWesJaK1m KYWknCbtZBLhFtlHVAGPEGlXNKmGkfm+VdfJyMHQgAic7Vq+2u6eTXDtK0/G2AsW yoze8bRV3U+IMyWR/97B9T9XL6tmCoW2FH+UWXB9eG+GHhpVHerVhf1rZE4aHVr5 S3Jm0/14yag7Q1vf/NZtqLNLyeyTeo9gQisqLtAw4FVY3IFtnb6NNZWhm7zrCzqi WxlJsX7vX/q1zD/l3WTvedpNHgKtEo5uXE6WHQL7JyjzCti9InLlf6peRq8GG8wN BnnQZEudGwCtM6rNIE5UMhJefJeX6tC1SCPjm7ggKKGaTYCNNVXekCo9pWYGyOkz elTQMtIHCfi7zOYSpuFB6K+DvyPifxrudGiBiWk+M86oWphpf9ZPMHSV01rwiYnR ICsLjJhX7ecVDZM96ALpil1xlUp4eF270oaAT8V81DzR//Wo8LRi/NX5kPfAR7KD ZMSMTovytEqSzo9WCe24N+8E2QrjkNsKEbgK6BeXTZNYON5HakHC8oUvIcqPi+F5 Ty39mg3U7pp9ePodZG5DyA4IaUdYFDpAPPebRpeftyg7LvPvau37/m6PeBdcMJo4 c7w9bQ8z6y4ZrdF0pueOOgbtDfwJLCOAeOxKNfdDtMmGg0qg0Q01rhVDazKxS6Jg l4znrkOS+ecPWlEZywCM =seIa -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e6d0bd20-3680-45be-ff94-15f7d06b599e%40gmail.com. For more options, visit https://groups.google.com/d/optout.
