Re: [qubes-users] Re: 35c3 session: Introduction to Qubes OS
>>> During 35th Chaos Communication Congress in Leipzig we'll be organizing an >>> introductory session to Qubes OS: >>> >>> https://events.ccc.de/congress/2018/wiki/index.php/Session:Introduction_to_Qubes_OS >> >> Was it recorded, so others can view it later? I cannot find it here: >> https://media.ccc.de/c/35c3 ? > > AFAIK it wasn't. It was a „self-organised session”, so there was no camera > manned by CCC staff, and no-one else would record since on the Congress the > recording people is generally frowned upon by attendees and organisers alike. Thank you for the answer. If you feel the urge to make a similar session to other users/backers of qubes-os, thank you in advance. Like Micah Lee’s presentation, I actually learned something new, and was looking forward to it. Sincerely Max -- 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/5227D155-5075-43BB-BC7A-A34E3676EB78%40militant.dk. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: fed29 templates/upgrade
On 1/4/19 5:00 PM, Andrew David Wong wrote: > On 1/4/19 1:13 PM, John S.Recdep wrote: >> On 1/4/19 1:37 AM, Andrew David Wong wrote: >>> On 1/3/19 11:31 PM, John S.Recdep wrote: On 1/3/19 2:51 PM, 22rip-2xk3N/kkaK1Wk0Htik3J/w...@public.gmane.org wrote: > Thanks 799...I learned something! > > Similar to 799 but less hardcore...I always download a fresh > template(vs upgrade). In my case I ran with a full/fresh > Fedora-29 after the Fedora-28 hplip issues, and added any > new software from fresh: > > https://www.qubes-os.org/doc/templates/ > >>> >>> hmm, ok let's say I just use the new fresh 29 template, is there some way that I can know what non-stock software I installed on my Fedora-28 template, as I can't remember all that I may have installed >>> >>> >>> This is more of a Fedora question than a Qubes question. As far >>> as I know, there isn't a clean way to do this. Following Marek's >>> advice from years ago, I just keep a list of the packages that I >>> install in each of my templates. >>> >>> So, no advice on upgrading from my 28 template at this time? I find it strange that the template is in the dom0 updates available, but I see no notice in the news section on qubes website nor here .. >>> >>> >>> See: >>> >>> https://github.com/QubesOS/qubes-issues/issues/4223 >>> >>> and >>> >>> https://github.com/QubesOS/qubes-doc/pull/739 > >> So, Andrew does this mean that although the Fedora-29 Template is >> available via sudo qubes-dom0-update that it still has issues and >> hence it is not officially advisable to use it ? ( whether via >> 'fresh' d/l nor 'upgrades' ? ) > >> Forgive me, am just a layman, not sure what I would expect to >> interpret from the github links (perhaps the fact that there are >> any issues provides the answer?) > >> My repos are just the default qubes 4.0+ versions > > > Well, you said you found it strange that there was no documentation or > announcement for the Fedora 29 template. These links show why: the > documentation is still being worked on, and the necessary steps prior to > the announcement have not yet been completed. (In fact, at the time of > this writing, the issue still indicates that the template has not yet > migrated to the stable repo, which appears to be false.) > > In order to avoid this sort of confusion in the future, perhaps we > should refrain from migrating new templates to the stable repo until > documentation and an announcement are ready to be published, then do > it all simultaneously. What do you think, Marek? > > OK understood, thx for the clarification. BTW all: no luck with the suggested methods of determining what extra packages I may have installed in the fedora-28 Template . but I'll just live with the fresh fedora-29 template -- 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/ecccbac3-75a7-31d0-c181-db9e172e6a72%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: fed29 templates/upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 1/4/19 1:13 PM, John S.Recdep wrote: > On 1/4/19 1:37 AM, Andrew David Wong wrote: >> On 1/3/19 11:31 PM, John S.Recdep wrote: >>> On 1/3/19 2:51 PM, >>> 22rip-2xk3N/kkaK1Wk0Htik3J/w...@public.gmane.org wrote: Thanks 799...I learned something! Similar to 799 but less hardcore...I always download a fresh template(vs upgrade). In my case I ran with a full/fresh Fedora-29 after the Fedora-28 hplip issues, and added any new software from fresh: https://www.qubes-os.org/doc/templates/ >> >> >>> hmm, ok let's say I just use the new fresh 29 template, is >>> there some way that I can know what non-stock software I >>> installed on my Fedora-28 template, as I can't remember all >>> that I may have installed >> >> >> This is more of a Fedora question than a Qubes question. As far >> as I know, there isn't a clean way to do this. Following Marek's >> advice from years ago, I just keep a list of the packages that I >> install in each of my templates. >> >> >>> So, no advice on upgrading from my 28 template at this time? I >>> find it strange that the template is in the dom0 updates >>> available, but I see no notice in the news section on qubes >>> website nor here .. >> >> >> See: >> >> https://github.com/QubesOS/qubes-issues/issues/4223 >> >> and >> >> https://github.com/QubesOS/qubes-doc/pull/739 > > So, Andrew does this mean that although the Fedora-29 Template is > available via sudo qubes-dom0-update that it still has issues and > hence it is not officially advisable to use it ? ( whether via > 'fresh' d/l nor 'upgrades' ? ) > > Forgive me, am just a layman, not sure what I would expect to > interpret from the github links (perhaps the fact that there are > any issues provides the answer?) > > My repos are just the default qubes 4.0+ versions > Well, you said you found it strange that there was no documentation or announcement for the Fedora 29 template. These links show why: the documentation is still being worked on, and the necessary steps prior to the announcement have not yet been completed. (In fact, at the time of this writing, the issue still indicates that the template has not yet migrated to the stable repo, which appears to be false.) In order to avoid this sort of confusion in the future, perhaps we should refrain from migrating new templates to the stable repo until documentation and an announcement are ready to be published, then do it all simultaneously. What do you think, Marek? - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlwwHc0ACgkQ203TvDlQ MDC3vxAAojbKj36me1TyU3iC+++fzvbV3Cz0NBideZaLmQkXXkydgmM8XFgVgLrT 4dgLsSBsg0M9x3FtzVzz653kvPYm/2n1YGjEboNiq19DbByqfvqCeKhEvxPXGwS4 XP/bFzvtQ9fG/kqRWU03npdqBes9qlhiBOzn2Qnhfc3KNuZvX4U1i5IPTZnipuh+ FSCqYdbbOq8dnjhu3zChq9A4GFD74f/jnx+bvP9NV0GWjGIFQQ/Y+Iza6HhlcO+y gAFLOR3shPFz4PAfJztSKzdaINavIWYqJtU07WIKVb4GJS1dnoU7B0NPyB73wdoa 2iSKoZkr8Yb2ZamdqvAaZP4JUnyG6QeakpW7fG4xtDWTpJnuKw1BvTxqTFAybJ3F sz2A807BmI/ie8znIU7BDCTihFnqw3oXAic550crMhh0WSjR8sYKTc8c3Nmpbv0V y9V0p12h+HuljaPQk8AXGa1QA2wviVS3r9gjN1VNKls8R2QwIqjohkitr5v9j9i/ Hz1X/ctZ9o64h9v8laVwpkLeWeNKjMWxLhD/a0FEqDeVkIxD+sS85uf5x2hkJyaD mUaxgax/WduElTaZW5unLPub8ZUOD7nLSjDrz9WZw3iDnuZl4CcG2qUNHBQPl6RT eh/Hb3mPTKSp4M+hB1msXa/FaCLy5OI3EiryRE6yXLu3xsx1c6g= =mpOV -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/73b6b80c-d209-6902-09a0-14c56a07f966%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Thanks and howto install Python version >= 2.6.4 on debian-9 template?
On Fri, Jan 04, 2019 at 06:40:08PM -0500, Chris Laprise wrote: > On 01/04/2019 04:18 PM, gone wrote: > > > Thanks again, unman. > > > > I think I've understood all the steps up to 5. and executed them. Then > > with Step 6 it went different to what you predicted. No output about > > mgmt-salt (btw. what is that?) and unfortunately no option to "say NO": > > > > user@debian-9-mix:~$ sudo apt-get install python3.7 > > Reading package lists... Done > > Building dependency tree > > Reading state information... Done > > Some packages could not be installed. This may mean that you have > > requested an impossible situation or if you are using the unstable > > distribution that some required packages have not yet been created > > or been moved out of Incoming. > > The following information may help to resolve the situation: > > > > The following packages have unmet dependencies: > > python3.7 : Depends: python3.7-minimal (= 3.7.2~rc1-1) but it is not > > going to be installed > > Depends: libpython3.7-stdlib (= 3.7.2~rc1-1) but it is not > > going to be installed > > E: Unable to correct problems, you have held broken packages. > > > > Is that problematic? Would you propose to go on with step 7 or do > > something else first? > > > > I think you need to include the '-t buster' option for apt-get install. > Otherwise it won't look for newer dependencies in the buster repo and so > won't be able to find them. > If you look at my instructions, you'll see I didnt suggest setting the Default-Release until *after* you'd installed Python3.7. My guess is that you've pinned to stretch already, so you have to specify buster for the install, as Chris says. If you do, you'll see the warning - mgmt-salt-vm-connector is the backend that allows for salt control of qubes. The new update tool uses this to run updates so you'll wont be able to use it on the new template. -- 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/20190105012119.uhpvoozieheb264s%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] signal-desktop?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I just installed signal-desktop (in the template) and now try to run it in the appVM. The app starts and I can see the window border, but nothing inside the window. Haven't done much diagnosis yet. Just wondering if someone here recently installed signal-desktop on a debian-9 based qube and has some hints for me. Cheers, Sven -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlwwAOYACgkQ2m4We49U H7Z6wBAAuGJwpxLEd706AFUWd4niXsPyUg1GFtgF1KY0fts3FOSvtdEPoTEZ5EBR ayVxn6Lr66QLk5Lkiur18Y997Zrljjcz1nHwJg1JPYgE1ZdWSGVfiK8111n+2t6b /prMFk5lbkbUqLOM9ZuPR6fsxrP0RU2MSJHXWq4kJ8mQPwwNw9aq9ExhVIf7G/DT OOdfdBxMXxRuC5SjZqHyCN6nDhs4nVSxr8AxDO1Y/5X+Kz+mx/zOyZTY2esR7HDt DXI6cUB15Zr3R6rtI3JrW1HWXksYZDkbBIDaELFrvIOoSZHM9bhzvPfMzZmvxydr q3A6aN22KdC7bwfEaZgQJtaaVix4C6zk1MVA7SxTnPdgy2FhOhmlWivm60AnV0jK gUWiIy/fBocbLCveH7J9bXrftNZ2eckauWiaTyhf13BKwhtzaTK6ERih7bQZkgMz ygBQJaMaToElLAASu/az1d+pFDlPvSAlBGXTUH1yKCrJO1xxu5ForZOOSaQjYLRx D/IR8bcGoeTIws0XpGtMjZAm4N72g33SidlaFtstTTS/RTQ44Ru/Q1RUiiSezxkl gkclXTClqI5WQR/UwU9P2PaX6OGxhRqZdO75jyHydliXEEJ9Tjb7sAQMx0GsGJdf 1IsTTd3EdV829Q+fH2USCJ4MtenyfKH8oBcB2TwUdIIvfy5gs5U= =Ltw8 -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/4b5540b7-2ff8-fd89-27d5-c753b2fb1285%40SvenSemmler.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL - Dell Inspiron 5570 (compliance plate mark: P75F, P75F001)
Citromail.hu levelezőrendszerből küldve Lépj be vagy regisztrálj -- 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/20190105015705.1964%40citromail.hu. For more options, visit https://groups.google.com/d/optout. Qubes-HCL-Dell_Inc_-Inspiron_5570-20190105-062515.yml Description: application/yaml
[qubes-users] HCL - Dell Inspiron 5570 (P75F, P75F001)
Need mouse to install. Install base system (not usbvm, whonix etc.), add those later from packages. Ethernet must be active at startup, does not detect cable plug-in. Slow (8 Gb, rotating hd, i5), but works. Citromail.hu levelezőrendszerből küldve Lépj be vagy regisztrálj -- 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/20190105014108.3630%40citromail.hu. For more options, visit https://groups.google.com/d/optout. Qubes-HCL-Dell_Inc_-Inspiron_5570-20190105-062515.yml Description: application/yaml
[qubes-users] Howto use ExpressVPN with Qubes
Hello, as I have spent several hours setting up ExpressVPN with Qubes and tried to document the process as good as possible. I'd like if someone can give it a try and maybe tell me if it is working or if you see room for improvement https://github.com/QubesOS/qubes-doc/blob/18a6d21b09742023a23f5e2576b8379c1b969e86/configuration/howto-use-expressvpn-with-qubes.md One thing which I don't understand is why I can't use the VPN Proxy behind sys-firewall but only behing sys-net? If I set sys-firewall as AppVM the other AppVMs which have the proxy/VPN-Qube as netvm can't connect. - O. -- 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/CAJ3yz2uOfgHDTof40wX_FGMVqQgY_4%3Du44k43cy6CUcXnq5KfA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qvm-restart
Am Fr., 4. Jan. 2019, 22:46 hat gone geschrieben: > The restart-function is available in the right-click-menue of a vm in > the Qube Manager. Could this also be provided for the CLI as a > "qvm-restart" command? > You can easily write a script yourself: #!/bin/bash qvm-shutdown --wait $1 && qvm-start $1 - O > -- 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/CAJ3yz2u6Vb3ikFAJWUvPkXkbzd%2B3EhXwWCxdW81_2uv84os7kA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: 35c3 session: Introduction to Qubes OS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Dec 30, 2018 at 02:52:46AM -0800, max via qubes-users wrote: > torsdag den 27. december 2018 kl. 12.12.36 UTC-5 skrev Wojtek Porczyk: > > Hi qubes-users, > > > > During 35th Chaos Communication Congress in Leipzig we'll be organizing an > > introductory session to Qubes OS: > > > > https://events.ccc.de/congress/2018/wiki/index.php/Session:Introduction_to_Qubes_OS > > Was it recorded, so others can view it later? I cannot find it here: > https://media.ccc.de/c/35c3 ? AFAIK it wasn't. It was a „self-organised session”, so there was no camera manned by CCC staff, and no-one else would record since on the Congress the recording people is generally frowned upon by attendees and organisers alike. - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEaO0VFfpr0tEF6hYkv2vZMhA6I1EFAlwv82wACgkQv2vZMhA6 I1GhBg/+LEz9VRbkDkWwvxtcPtJf+L9mqoABFVzEk6pSxPrlEQDsfRT6D4hUv7sk MXGSn/P4MYJjTmPKOby0fHE1WHLbnwSVQFEq/sHwffuhCJQ0cX+BVoQ8UpeC70T1 HThMbffQQ0n4N1spzKdxREqaTjZEju2CnSiY6LDmOlvdCrxKab0Wukq1JbO5qt7w C7VFmJaN46qmRmwQEoerqe6sZQfGt2IFB65aBLDQ1NlVve2iLrABMQJdL5gp0iTQ LIqkfZyi9aZGREb04gNRd89w47dhKPDIdZD9dKleSjgrOHxK9whoKw7KkS+KLa5q gpsL8w5Rrmt2hnrT+3Fw2MkMnmn2vkF4ttg9mM6M4lNi/Eu3KAydHi0kbFCaNfRP TA+12VY/dnb7rajwuUpX0aC+/ZgopqfigrRSLYB/yAZvdgxXAFmaNYVu2t/L3Y9p vjsw8f8nHXEWIEZrqoMOUhyfMc5v8kVhMs1POD07jc1rGFY2+EpPELxBDZ02c4iO ThFSa/X0WKE7jj++C0R/T3BbbvpNXIJy5lY/A+DEguObN1+mCikcOAxNemgAgHUA QKxl30tjL7fyk0V/RGZ8ajgxj+ZEDjZcoa01eD6W3QGUY50k28kSD8QC42nHNT9K zunpa0ASACQTDmDIgReDfgYNwKbP/HesfNg4TD3MbbILP8OvVII= =Es5C -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/20190104235938.7jmihfkxnwujzmgy%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: How risky is GPU pass-through?
On Tuesday, January 1, 2019 at 11:19:24 AM UTC+2, John Mitchell wrote: > > > > I don't need a core sample of the moon to know that it isn't made of green > > cheese. Doesn't matter what the videos showed. There are lots of videos > > that "prove" and impossible claim. If you want to believe that, it's > > completely up to you. > > > > VMs have longer code paths than native. That alone would cause a perf hit. > > Then there is the noisy neighbor problem and the fact that dom0 has to > > cycle steal. Anyone with a lick of common sense would see the > > impossibility of such a claim. > > You are correct their are some wacky videos out on the Internet. I wouldn't > trust these videos if they didn't come from reliable sources, Level1techs are > legit. > > I will assume by longer code paths you are referring to the execution times. > This is true however the path is roughly only a 5% longer to execute time > penalty yielding 95% of the bare metal performance. Red Hat provides most of > the speed boost with their virtio drivers. You can learn more here, > > https://docs.fedoraproject.org/en-US/quick-docs/creating-windows-virtual-machines-using-virtio-drivers/index.html > > When we believe strongly about something we tend to have tunnel vision and > can't see outside the box. I can only present that it works, I can not open > your mind up to see outside the box nor do I want too. I respect your > opinion and will hope you can do the same. > > Anyway, this will be my last response unless I have something new to share. > I freely give you the last word if you need it. > > I hope you and family and everyone on this group have a very Happy New Year! > > Peace! Used to run Gentoo with qemu / kvm and was passing through 3 GPU's each running win10 for over a year. It took some time to setup and was a fun project to figure out things. There was no lag or crashes and Games were running smooth thanks to vfio! Of course bare Metal would be faster but Benchmarks tend to go from 3% to 5% lower ratting, nothing that worried me. -- 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/079f9acd-3fab-4e1e-80a7-e83ab606f133%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Thanks and howto install Python version >= 2.6.4 on debian-9 template?
On 01/04/2019 04:18 PM, gone wrote: Thanks again, unman. I think I've understood all the steps up to 5. and executed them. Then with Step 6 it went different to what you predicted. No output about mgmt-salt (btw. what is that?) and unfortunately no option to "say NO": user@debian-9-mix:~$ sudo apt-get install python3.7 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: python3.7 : Depends: python3.7-minimal (= 3.7.2~rc1-1) but it is not going to be installed Depends: libpython3.7-stdlib (= 3.7.2~rc1-1) but it is not going to be installed E: Unable to correct problems, you have held broken packages. Is that problematic? Would you propose to go on with step 7 or do something else first? I think you need to include the '-t buster' option for apt-get install. Otherwise it won't look for newer dependencies in the buster repo and so won't be able to find them. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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/83bc9581-7d23-4312-37ff-cac1f8ff2ec6%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Install errors on Thinkpad P1 (aka X1 Extreme) with R4.0 and R4.0.1-rc2
On 20190104 at 09:24 -0800 Eric Duncan wrote: > It is upon completion of this step, just before the system switches to the > login screen, that the error message pops up: > > /usr/bin/qvm-start sys-firewall failed > stdout: "" > stderr: "Start failed: internal error: Unable to reset PCI device > :00:1f:6: > no FLR, PM reset or bus reset available, see > /var/log/libvirt/libxl/libxl-driver.log for details. > " The good old I219-LM problem... Before assigning (or after 8-) it to sys-net (I do not really see any reason it should be assigned to sys- firewall... are you sure?) it needs to get set to no-strict-reset=true and permissive=true; take a look at qubes-os.org. > Click OK switches a black screen, and the system become unresponsive. Only a > hard reset gets it to reboot, at which it boots up to the LUKS password, I > enter it, and the system boots to a black screen again - unresponsive. Use the dGPU or take care of turning off the nouveau driver completely (nouveau.modesetting=0). > I suspect it's the Nvidia graphics. However, I can't get the installer to > boot past Xen with Hybrid graphics - Xen pauses for 5 minutes or something, > and goes black. Why don't you use the nVidia GPU instead? It is definitely faster than the iGPU anyway, booting faster, using (at least on my machine) less energy and you do not meed to modify the kernel command line. And on kernel-latest my system is working with all cores. > WARNING (to anyone else installing on a P1/X1 Extreme/P52, etc): To install, > you must switch to discrete graphics in BIOS (no hybrid). But, DO NOT DO > THIS unless you have BIOS 1.17 or later or you will BRICK YOUR THINKPAD! That didn't break mine. Turning on Thunderbolt BIOS support and turning off secure boot did that for me. Switching to dGPU is only causing problems if you do not wait on the next reboot for the system to reinitialize the device tree in ME (and thus starting with empty ACPI tables) by resetting it at just the right time during the 30 seconds this would take. Achim -- 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/e6322720ce13f51517724aad689eb58e5ab2c971.camel%40noses.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] qvm-restart
The restart-function is available in the right-click-menue of a vm in the Qube Manager. Could this also be provided for the CLI as a "qvm-restart" command? -- 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/ac012663-d9f1-5921-f64f-00f8055775e2%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Thanks and howto install Python version >= 2.6.4 on debian-9 template?
On 1/4/19 11:56 AM, unman wrote: On Fri, Jan 04, 2019 at 12:12:44AM +0100, gone wrote: On 1/3/19 11:51 PM, Chris Laprise wrote: On 01/03/2019 05:07 PM, gone wrote: On 1/3/19 10:45 PM, Chris Laprise wrote: On 01/03/2019 03:40 PM, gone wrote: On 1/3/19 12:50 AM, unman wrote: On Wed, Jan 02, 2019 at 05:08:50PM +0100, gone wrote: On 1/1/19 10:19 PM, Chris Laprise wrote: On 01/01/2019 02:37 PM, gone wrote: Hello, 1st of all, I want to thank all the developers and supporters for that great stuff called Qubes OS. My first question here after some hard time of setting up version 4.0, updating it step by step and studying is the following: I have a debian-9 template running and for some application to get installed on it I need Python with Version = 3.6 as a prerequisite. Since the preinstalled versions in debian-9 are 2.7 and 3.5 I attempted to install version 3.6.4 from source as described at https://www.rosehosting.com/blog/how-to-install-python-3-6-4-on-debian-9/ in order not to run into problems with incompatibilities when switching to another repo. Installing the build tools with "sudo apt-get install -y ..." worked fine but the next step, downloading the source file, with "wget https://www.python.org/ftp/python/3.6.4/Python-3.6.4.tgz; brings "... failed: Temporary failure in name resolution. wget: unable to resolve host address ‘www.python.org’ " As I am neither an expert nor an experienced from-source-installer I need some help and hope to get it here. Thanks very much in advance and all the best for 2019. Installing from Debian testing is much easier and it has Python 3.7. Just set the default release as in the following link, then add a line for "testing" in your /etc/apt/sources.list (and then 'apt update'): https://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html#s-default-version Thanks Chris for the explanation. Yes, it may be easier to change to the testing repo, but in general I would like to stay on the stable path with that template. Switching to the testing repo and 'apt update' would probably cause trouble with other software running smoothly so far. Or can I use that only for python install and then fall back? If you follow the instructions that Chris linked to you should be fine. apt update just updates the list of available packages. It doesn't in itself do anything more. By setting the default release to stable, you ensure that you wont be "accidentally" installing stuff from testing. That will only happen if you explicitly specify the testing repo: apt-get -t testing install foo I'd strongly recommend aptitude, which does an excellent job of dealing with packages from different releases, and allows you to explicilt choose the version you want. It also lets you review in detail what the consequnces will be , so you are always able to roll back. And, of course, with Qubes it's trivial to clone the template, try out your proposed update from testing, and make sure that everything works fine before you commit your precious qubes to use the new template. OK, I've done setting the default version to "testing" in the newly created /etc/apt/apt.conf but for the additional line in the sources.list I'm not sure, what really is to do. I've tried it with "deb http://deb.debian.org/debian stretch testing contrib non-free" but that seems to be wrong, as I get the following output in the terminal: user@debian-9:~$ sudo apt update Hit:1 http://deb.qubes-os.org/r4.0/vm stretch InRelease Hit:2 http://security-cdn.debian.org stretch/updates InRelease Ign:3 http://cdn-fastly.deb.debian.org/debian stretch InRelease Hit:4 http://cdn-fastly.deb.debian.org/debian stretch Release Reading package lists... Done Building dependency tree Reading state information... Done All packages are up to date. W: Target Packages (contrib/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list:4 and /etc/apt/sources.list:10 W: Target Packages (contrib/binary-all/Packages) is configured multiple times in /etc/apt/sources.list:4 and /etc/apt/sources.list:10 W: Target Translations (contrib/i18n/Translat.and several more lines with W: at the beginning. Sorry but I'm absolutely not familiar with that, although it's pretty interesting. @unman: As soon as it will have worked this way I promise to try aptitude next ;-) . The relevant advice here is "set the default release as in the following link...". Not set default release to testing! In this case it should be set to stretch because that's the Debian release you're using. You should add testing only as an additional line in sources.list: deb http://deb.debian.org/debian testing main Oh sorry, Chris, I reported wrong. The default in apt.conf is correctly set to stable. Thank you for the correct line to put in sources.list. FWIW, the debian page isn't terribly clear about it. Also, I believe that if you set the default to "stable" instead of the more specific "stretch", the system could try to
[qubes-users] Salt orchestration
Hi, I need to orchestrate Salt states so that VMs are started, stopped and configured in stages. I tried using the Salt Orchestrate Runner, but it couldn't find states that I can use with 'qubesctl state.sls ' and 'qubesctl state.highstate'. I have two use cases: 1. Salt should start, configure, and halt template VMs before it starts app VMs that use them. For example, the Salt GPG state requires the python-gnupg package. This package needs to be installed in the template VM so that the Salt GPG state can import keys in the app VM. The current sequence of my states appears to let template VMs halt before Salt starts app VMs. But I would like to strictly enforce this ordering between admin VM states and regular VM states. 2. Salt should ensure that service VMs are running before Salt applies states to their client VMs. For example, I have a service VM that exports gpg-agent's SSH socket through Qrexec. This VM needs to be running so that the client VM can clone git repos using keys on the serivce VM. This second case is more difficult to enforce without orchestration. I can approximate this functionality with a series of commands: qubesctl --target template-vm state.highstate qvm-shutdown template-vm qubesctl --target service-vm state.highstate qvm-start service-vm qubesctl --target client-vm state.highstate But I would like to be able to describe this orchestration in Salt. Does the Salt Orchestrate Runner work on Qubes? If not, is there a way to orchestrate Salt on Qubes? Thanks, Brian -- Brian C. Duggan he/him/his -- 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/53a38760-fd3e-31f8-d06b-b821a809fc23%40dugga.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: R4.0 and R4.0-rc2 Instructions for USB Keyboard w/Sys-USB fails
On Friday, January 4, 2019 at 7:56:26 PM UTC+1, Eric Duncan wrote: > > The guide also shows how to hide all USB controlles from Dom0. This is now > > default, so you need to unhide them. > > Do you think I need to pass an entire controller? Could I start of focus on > what IDs the USB keyboard is using and just pass that? I'm new to USB pass > through processes, so these are my first attempts. > > Whichever is the case, I'll update the guide as well with a PR to add this > step. > > The guide is also a bit annoying as for other a year I always thought it was > only for USB block devices - until I recently scrolled all the way down - and > now see the info about other USB devices. I'll add an Introduction as well > to help clarify things and what all that guide covers. > > I'm not sure what you mean. There are different ways to connect USB devices to an AppVM/Qube. 1 is to attach block devices, this is the safest method and you can use this to attach individual partitions. However, if your device is not a storage device, but a webcam or keyboard, it will not work. 2. You can also attach the complete device to a Qube(USB Passthrough). This works with more devices this gives more ways to infect the destination Qube if the device is compromised. Method 3 is to attach the whole USB controller using Xen PCI passthrough. When creating a USB Qube(sys-usb), all USB controllers are attached to this Qube so Dom0 is protected from all USB devices. You can then connect USB devices to other Qubes when necessary with method 1 and 2. This means if you use a USB Qube, if you attach a USB keyboard, it is also connected to sys-usb, and not Dom0, and you cannot use USB passthrough on Dom0, so you can't use it to type. To solve this, the USB qube gets permission to send keystrokes to dom0(done automatically when you execute qubesctl state.sls qvm.usb-keyboard). (Btw, this means that the USB qube can send keystrokes to Dom0 and also see sent keystrokes i.e. passwords. If you or someone connects a compromised/evil USB device to sys-usb it can thus sniff your passwords or sent commands to Dom0. If you don't want this: A: only use built-in laptop keyboard or PS/2 keyboard and don't give USB Qube permission to send keystrokes. If this is not possible or external USB keyboard is needed: B: if you have multiple USB controllers you might be able to create a second USB qube and attach one of the USB controllers using PCI passthrough to that device and leave the others connected to the first USB Qube. Then you can allow permission to send keystrokes for the second USB Qube and connect your keyboard to the USB ports belonging to that USB controller, and connect other (untrusted) USB devices to the USB ports from the other controller connected to the first USB Qube. Now you're protected from malicious devices unkowingly connected by yourself, an attacker might of course still attach the device to the other USB ports. And/Or C: use the DisposableVM feature with sys-usb to ensure a clean sys-usb every boot. This is more useful for a non-targeted attack/accidental compromise. Of course compromise can still happen between boots. Even with a USB Qube, Dom0 is still unprotected from USB devices during boot, this why USB controllers are hidden from Dom0 during boot. To enter your LUKS password, you only need to unhide the USB controllers from Dom0. If you have access to your machine you can follow the standard instructions to hide them, but instead of adding the line(s) "rd.qubes.hide_all_usb" you need to remove them. If you don't want to reinstall Qubes, you can boot the machine, then edit the boot command in Grub during boot(not sure how that works with (U)EFI boot) by pressing 'e' and remove "rd.qubes.hide_all_usb" on the same place(s) and press ctrl+x to boot. Then after booting is complete also remove "rd.qubes.hide_all_usb" with the normal instructions to make it permanent. > On Friday, January 4, 2019 at 12:54:56 PM UTC-5, Lorenzo Lamas wrote: > > On Friday, January 4, 2019 at 6:29:37 PM UTC+1, Eric Duncan wrote: > > > > > > The odd part is... I can press ESC and get to the text output of LUKS > > > asking for password. So something is kind of working? > > > > Indeed strange though that ESC is still working. > > It's a race condition when Xen is attaching USB controllers? If I act > quickly, I can get a few characters typed until the keyboard goes dead. > Which begs the question, why does Xen allow me to even type a few chars > before the usb is redirected? I guess the USB controllers are not yet hidden that early in the booting process. -- 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
Re: [qubes-users] old version of xscreensaver
On 01/04/2019 03:24 AM, haaber wrote: On 01/03/2019 06:03 PM, Frédéric Pierret wrote: We built the upstream package of xscreensaver in current-testing for both Qubes 3.2 and 4.0. Welcome back to XFCE Chris :D ! LOL, seriously? The XFCE deficits are too numerous, unfortunately. Dear Chris, for less advanced users it might be helpful to have a non-dogmatic discussion on advantages and disadvantages of both sides. I guess that XFCE has speed on its side, for example. Visual aspects seems on the KDE side (at least for me). I invite you to give us a deeper comparison... best, Bernhard An impromptu list of KDE advantages: * Monitor power-save mode always works - this always fails in XFCE. * Multi-monitor configurations are remembered correctly - XFCE forgets them. Very useful if you want laptop's internal screen to turn off when connecting external display. But this is important for any config involving multiple displays. * Auto-login at boot time works. * Focus-stealing prevention works better (not perfect - but XFCE's doesn't work at all). * Screen saver allows you to stop the screen lock a few seconds later by just tapping a key. OTOH the xscreensaver is totally unforgiving - requires a lot of repeated password typing. * Custom Qubes border colors; the defaults are far too bright for dark/low light themes. * Fine-grained control of audio volume - XFCE's volume stepping is annoyingly inaccurate. * Very nice Redshift control widget. * Much better accessory apps: Text editor, terminal, etc. This matters even for dom0. - Notice I didn't touch on anything that would be considered advanced. Also notice the stuff that works in KDE but is broken in XFCE... the fact that XFCE developers let these obvious bugs sit for years is a cause for general concern. I use the more advanced KDE features, too: * Controlling which VMs appear on which desktops * Hotkey functions * Color correction profiles. (KDE also works better inside appVMs, at least in the sense that its apps will always start when requested.) On the downside, this version of KDE takes about 5sec longer to start up - which the auto-login more than makes up for. And the Network Manager icon is blank, even though it works. I'm happy to take that trade-off. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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/a812d079-68e6-c054-7a0a-ad1e57f4d8d1%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: fed29 templates/upgrade
On 1/4/19 1:37 AM, Andrew David Wong wrote: > On 1/3/19 11:31 PM, John S.Recdep wrote: >> On 1/3/19 2:51 PM, 22rip-2xk3N/kkaK1Wk0Htik3J/w...@public.gmane.org >> wrote: >>> Thanks 799...I learned something! >>> >>> Similar to 799 but less hardcore...I always download a fresh >>> template(vs upgrade). In my case I ran with a full/fresh >>> Fedora-29 after the Fedora-28 hplip issues, and added any new >>> software from fresh: >>> >>> https://www.qubes-os.org/doc/templates/ >>> > > >> hmm, ok let's say I just use the new fresh 29 template, is there >> some way that I can know what non-stock software I installed on my >> Fedora-28 template, as I can't remember all that I may have >> installed > > > This is more of a Fedora question than a Qubes question. As far as I > know, there isn't a clean way to do this. Following Marek's advice > from years ago, I just keep a list of the packages that I install in > each of my templates. > > >> So, no advice on upgrading from my 28 template at this time? I find >> it strange that the template is in the dom0 updates available, but >> I see no notice in the news section on qubes website nor here >> .. > > > See: > > https://github.com/QubesOS/qubes-issues/issues/4223 > > and > > https://github.com/QubesOS/qubes-doc/pull/739 So, Andrew does this mean that although the Fedora-29 Template is available via sudo qubes-dom0-update that it still has issues and hence it is not officially advisable to use it ? ( whether via 'fresh' d/l nor 'upgrades' ? ) Forgive me, am just a layman, not sure what I would expect to interpret from the github links (perhaps the fact that there are any issues provides the answer?) My repos are just the default qubes 4.0+ versions -- 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/a7ea5b94-5d94-0b0e-7125-8f66092507ba%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: R4.0 and R4.0-rc2 Instructions for USB Keyboard w/Sys-USB fails
> The guide also shows how to hide all USB controlles from Dom0. This is now > default, so you need to unhide them. Do you think I need to pass an entire controller? Could I start of focus on what IDs the USB keyboard is using and just pass that? I'm new to USB pass through processes, so these are my first attempts. Whichever is the case, I'll update the guide as well with a PR to add this step. The guide is also a bit annoying as for other a year I always thought it was only for USB block devices - until I recently scrolled all the way down - and now see the info about other USB devices. I'll add an Introduction as well to help clarify things and what all that guide covers. On Friday, January 4, 2019 at 12:54:56 PM UTC-5, Lorenzo Lamas wrote: > On Friday, January 4, 2019 at 6:29:37 PM UTC+1, Eric Duncan wrote: > > > > The odd part is... I can press ESC and get to the text output of LUKS > > asking for password. So something is kind of working? > > Indeed strange though that ESC is still working. It's a race condition when Xen is attaching USB controllers? If I act quickly, I can get a few characters typed until the keyboard goes dead. Which begs the question, why does Xen allow me to even type a few chars before the usb is redirected? -- 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/82cfa581-92c5-4699-9a9e-b788d8e45c5d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: old version of xscreensaver
I have tried KDE shortly on R4 now, here are some of my pro's and cons: XFCE: Pros -Fast and light. -I have my standard panel on the bottom and created a second, auto-hiding, panel on the top filled with Launchers to get something like a MacOS Dock.(But way less fancy.) Cons: -Not visually appealing. -Default Window Manager theme (Slick) is very ugly, and also the some of the colors from the collored borders get very ugly. I thought R3.2 used a different fault. I've set mine to Nodoka. -I've set appearance to Greybird, the panel looks a lot better now but Application Launcher does not match. -Xscreensaver lockscreen is way too ugly. KDE: Pros -Loads more visually appealing. -Much nicer lockscreen. Cons -After logging in after booting it needs quite some time to load while XFCE loads almost instantly. -Sys-Net network icon is invisible -Other icons are very out of focus compared to XFCE and some are uglier as well. -Not sure if there is an alternative to my XFCE 'Dock' that doesn't require installing additional software/extensions into Dom0. -- 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/9a19e877-f67a-408c-8607-0e8fc9221ff4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: R4.0 and R4.0-rc2 Instructions for USB Keyboard w/Sys-USB fails
On Friday, January 4, 2019 at 9:54:56 AM UTC-8, Lorenzo Lamas wrote: > The guide also shows how to hide all USB controlles from Dom0. This is now > default, so you need to unhide them. Do you think I need to passthrough an entire controller? Or should I try to narrow down just the one keyboard USB device? Whichever it is, I'll push a PR to update the docs - as the doc seems to indicate that running the one command is all you need to do (I also have a problem with the doc having no introduction paragraph, as when you first read it you think it's all about USB block devices only - until you scroll way way down). On Friday, January 4, 2019 at 9:54:56 AM UTC-8, Lorenzo Lamas wrote: > > The odd part is... I can press ESC and get to the text output of LUKS > > asking for password. So something is kind of working? > > Indeed strange though that ESC is still working. Yeah, I think it's a race condition. If i act quickly, I can get a few characters typed before the keyboard stops working. But a few characters of a 30+ long passphrase... I'm not that fast of a typer. :) -- 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/3d5e0363-bbfd-4b03-b082-418496de2eb0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: R4.0 and R4.0-rc2 Instructions for USB Keyboard w/Sys-USB fails
On Friday, January 4, 2019 at 6:29:37 PM UTC+1, Eric Duncan wrote: > Following this guide to enable a sys-usb qubes, but with a USB keyboard fails: > > https://www.qubes-os.org/doc/usb/#how-to-use-a-usb-keyboard > > Tried on two ISOs: R4.0 (bare ISO install, no updates) and R4.0-rc2 (up to > date). > > Tried on two systems: Thinkpad X1 Tablet 3rd Gen and Apple Macbook Pro > mid-2014. > > Both systems reboot to a keyboard that does not work to enter LUKS password, > and therefore losing all access to the system. > > I'm guessing I need to configure the keyboard for USB pass through? As a > step missing perhaps? > > The command executes properly: > > sudo qubesctl state.sls qvm.usb-keyboard > > And after a reboot, the system doesn't allow USB keyboard. > > The odd part is... I can press ESC and get to the text output of LUKS asking > for password. So something is kind of working? The guide also shows how to hide all USB controlles from Dom0. This is now default, so you need to unhide them. Indeed strange though that ESC is still working. -- 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/387f0edb-a753-498e-8028-5ee60960a7a9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] R4.0 and R4.0-rc2 Instructions for USB Keyboard w/Sys-USB fails
Following this guide to enable a sys-usb qubes, but with a USB keyboard fails: https://www.qubes-os.org/doc/usb/#how-to-use-a-usb-keyboard Tried on two ISOs: R4.0 (bare ISO install, no updates) and R4.0-rc2 (up to date). Tried on two systems: Thinkpad X1 Tablet 3rd Gen and Apple Macbook Pro mid-2014. Both systems reboot to a keyboard that does not work to enter LUKS password, and therefore losing all access to the system. I'm guessing I need to configure the keyboard for USB pass through? As a step missing perhaps? The command executes properly: sudo qubesctl state.sls qvm.usb-keyboard And after a reboot, the system doesn't allow USB keyboard. The odd part is... I can press ESC and get to the text output of LUKS asking for password. So something is kind of working? -- 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/adbb8ff4-d1a0-47d8-aa15-cce0dfbce7f0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Install errors on Thinkpad P1 (aka X1 Extreme) with R4.0 and R4.0.1-rc2
Latest 1.17 BIOS, VT-d and Virtualization enabled in BIOS. Various thunderbolt assists disable/enable, etc options tried on/off. Must use discrete graphics during install, which is an Nvidia Quatro P2000 (similar to the GTX 1050qm generation). Anaconda installer gets past the initial setup, partitions the drive, etc and reboots. After first reboot, when selecting which qubes to configure, the system starts to configure all the Qubes. It is upon completion of this step, just before the system switches to the login screen, that the error message pops up: /usr/bin/qvm-start sys-firewall failed stdout: "" stderr: "Start failed: internal error: Unable to reset PCI device :00:1f:6: no FLR, PM reset or bus reset available, see /var/log/libvirt/libxl/libxl-driver.log for details. " Click OK switches a black screen, and the system become unresponsive. Only a hard reset gets it to reboot, at which it boots up to the LUKS password, I enter it, and the system boots to a black screen again - unresponsive. I've tried flipping various options in BIOS to no avail. I suspect it's the Nvidia graphics. However, I can't get the installer to boot past Xen with Hybrid graphics - Xen pauses for 5 minutes or something, and goes black. NOTE: I got the same error on a Thinkpad X1 Tablet 3rd Gen using R4.0.1-rc2. However, switching to R4.0 RTM did not get the error and the system installed normally. WARNING (to anyone else installing on a P1/X1 Extreme/P52, etc): To install, you must switch to discrete graphics in BIOS (no hybrid). But, DO NOT DO THIS unless you have BIOS 1.17 or later or you will BRICK YOUR THINKPAD! Known issue across most latest-generation Thinkpads these days with discrete graphics. -- 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/9bc8512c-7e90-4467-99ac-64dd8c3f6a3a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] old version of xscreensaver
On Fri, 4 Jan 2019 09:24:50 +0100 haaber wrote: >> On 01/03/2019 06:03 PM, Frédéric Pierret wrote: >>> We built the upstream package of xscreensaver in current-testing for >>> both Qubes 3.2 and 4.0. >>> >>> Welcome back to XFCE Chris :D ! >> >> LOL, seriously? >> >> The XFCE deficits are too numerous, unfortunately. >> >Dear Chris, for less advanced users it might be helpful to have a >non-dogmatic discussion on advantages and disadvantages of both sides. I >guess that XFCE has speed on its side, for example. Visual aspects seems >on the KDE side (at least for me). I invite you to give us a deeper >comparison... best, Bernhard > GUI of choice is a very personal thing. I am more pragmatic and don't like "dancing" icons and starting all of my application names with K...or G for that matter...but to each his own. I am "slightly" impaired visually, and the simpler and more clean a GUI, the better for me. I have to spend many hours in front of a screen each day. There is a tad more manual effort to get XFCE 'just right', but I like the visually simple appearance and would rather devote my computing power to function than what I consider fluff. Now historically I have used older, less powerful machinery. In fact, my Qubes machine is having motherboard issues with the power management circuitry and won't boot reliably so I'm actually using an old Dell D620 32 bit machine for now...which used to be my wife's Windows 7 computer. The screen is a tad flaky which is why she quit using it, but it is at least functional and boots when I ask. I have a replacement motherboard on the way and will be doing the surgery on my T520 once I get it. I'm not really a hardware guy, so it will be a learning experience to be sure. Even with the additional power of a 2.5Ghz four core processor, I still prefer to save the power for actual work. Stuart -- 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/20190104090844.58fe687e%40D620Debian9. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] old version of xscreensaver
On 20190103 at 19:29 -0500 Chris Laprise wrote: > The XFCE deficits are too numerous, unfortunately. It's just the worst UI since OSF/Motif (which made me go to plain X11/twm). Achim -- 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/e051e37a42761c4679444de7c8b12ddfccce29b0.camel%40noses.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] HCL - Lenovo Thinkpad T480
On 20190104 at 10:14 +0100 Zrubi wrote: > Thunderbolt BIOS Assist: > if enabled, the mentioned device - causing the hibernation issues - > are gone, then only one USB device remains, which is works without > problems. Be careful to have updated the firmware before turning it on; I've seen the bug that is hitting the P series affecting T series models, too. > Confirmation needed: As I do not have any Type-C devices, I can't > check if that is still working in this case or not. Without BIOS assist mode strange things are happening in Qubes (but not up to date Arch) if you connect the Thunderbolt 3 Dock (and even worse if you connect the Thunderbolt Graphics Dock should you have one). Important point: Set Thunderbolt security in the setup, too. If you leave it open it will be possible to attach any Thunderbolt device without user intervention and use it to get full access to the hardware. > Moreover, if you don't need the thunderbolt at all, it can be > disabled completely from BIOS. Hence then the USB-C connector lost > its functionality for sure. In the case of the P series the Thunderbolt controller has control over the physical connector so if you turn it off the USB subsystem and the GPU will lose their access, too. Stupid design if you ask me. Achim -- 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/47180d3bbd028f3b6a260d89fcff4d3df436a7ee.camel%40noses.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: fed29 templates/upgrade
On Fri, Jan 04, 2019 at 01:13:52PM +0100, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 04, 2019 at 05:37:07AM -0600, Andrew David Wong wrote:
> > On 1/3/19 11:31 PM, John S.Recdep wrote:
> > > On 1/3/19 2:51 PM, 22rip-2xk3N/kkaK1Wk0Htik3J/w...@public.gmane.org
> > > wrote:
> > >> Thanks 799...I learned something!
> > >>
> > >> Similar to 799 but less hardcore...I always download a fresh
> > >> template(vs upgrade). In my case I ran with a full/fresh
> > >> Fedora-29 after the Fedora-28 hplip issues, and added any new
> > >> software from fresh:
> > >>
> > >> https://www.qubes-os.org/doc/templates/
> > >>
> > >
> > >
> > > hmm, ok let's say I just use the new fresh 29 template, is there
> > > some way that I can know what non-stock software I installed on my
> > > Fedora-28 template, as I can't remember all that I may have
> > > installed
> > >
> >
> > This is more of a Fedora question than a Qubes question. As far as I
> > know, there isn't a clean way to do this. Following Marek's advice
> > from years ago, I just keep a list of the packages that I install in
> > each of my templates.
>
> Since some dnf version it is possible:
>
> sudo dnf history userinstalled
>
> dnf mark can be used to adjust the list (without actually
> installing/removing packages). This may list some more packages, as it
> will include default packages installed by the template builder. But
> should be a good starting point for such a list.
>
The problem with that is that it outputs version numbers, which isnt
particularly helpful.
dnf repoquery --qf "%{name}" --userinstalled
Will give you just the names.
Somewhat more naively, 'dnf list installed|cut -f1 -d" "|tail -n +3'
will give you a complete list which you could feed to 'dnf install'.
Debian has apt-clone which works nicely. I don't know if there's a Fedora
equivalent.
--
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/20190104123413.4heul54qzytbcxhd%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: fed29 templates/upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Jan 04, 2019 at 05:37:07AM -0600, Andrew David Wong wrote: > On 1/3/19 11:31 PM, John S.Recdep wrote: > > On 1/3/19 2:51 PM, 22rip-2xk3N/kkaK1Wk0Htik3J/w...@public.gmane.org > > wrote: > >> Thanks 799...I learned something! > >> > >> Similar to 799 but less hardcore...I always download a fresh > >> template(vs upgrade). In my case I ran with a full/fresh > >> Fedora-29 after the Fedora-28 hplip issues, and added any new > >> software from fresh: > >> > >> https://www.qubes-os.org/doc/templates/ > >> > > > > > > hmm, ok let's say I just use the new fresh 29 template, is there > > some way that I can know what non-stock software I installed on my > > Fedora-28 template, as I can't remember all that I may have > > installed > > > > This is more of a Fedora question than a Qubes question. As far as I > know, there isn't a clean way to do this. Following Marek's advice > from years ago, I just keep a list of the packages that I install in > each of my templates. Since some dnf version it is possible: sudo dnf history userinstalled dnf mark can be used to adjust the list (without actually installing/removing packages). This may list some more packages, as it will include default packages installed by the template builder. But should be a good starting point for such a list. > > > > > So, no advice on upgrading from my 28 template at this time? I find > > it strange that the template is in the dom0 updates available, but > > I see no notice in the news section on qubes website nor here > > .. > > > > See: > > https://github.com/QubesOS/qubes-issues/issues/4223 > > and > > https://github.com/QubesOS/qubes-doc/pull/739 > > > > > Seems like this happened with 28 release as well > > > - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlwvTgAACgkQ24/THMrX 1yxPrggAirGLmrqKZm73SVrEoSraBBgGIN7hXEXxgsKr4jtK5ymU7YEVyO2zc44S wQKcSJrmbO7VlGTNRGmxmMRsFa5f5j5Yxn1HaKeTKFd0HHLJja00SbpYCVnx6RFP 1cLSrAWwHHxazMImQ0mKkeBhmlHI45/dD30EwWJ3C2gYWCPj6PjHyfTpl61itf5M zPuMBAcyxemZ0LNgg2mCtD56i60n6c44d8+1xjPCBgdDTKbMkk72TTejv3MAuEdC qeREUS9QPBwR5Zbx0Fr72YIXRsXOEPYT3zi996u48lRXmHdo90AByq2zc4PJKUpc YdSTPPu4su9j+iPKzxWQUrPl5xt/wQ== =4V1h -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/20190104121352.GN23474%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: fed29 templates/upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 1/3/19 11:31 PM, John S.Recdep wrote: > On 1/3/19 2:51 PM, 22rip-2xk3N/kkaK1Wk0Htik3J/w...@public.gmane.org > wrote: >> Thanks 799...I learned something! >> >> Similar to 799 but less hardcore...I always download a fresh >> template(vs upgrade). In my case I ran with a full/fresh >> Fedora-29 after the Fedora-28 hplip issues, and added any new >> software from fresh: >> >> https://www.qubes-os.org/doc/templates/ >> > > > hmm, ok let's say I just use the new fresh 29 template, is there > some way that I can know what non-stock software I installed on my > Fedora-28 template, as I can't remember all that I may have > installed > This is more of a Fedora question than a Qubes question. As far as I know, there isn't a clean way to do this. Following Marek's advice from years ago, I just keep a list of the packages that I install in each of my templates. > > So, no advice on upgrading from my 28 template at this time? I find > it strange that the template is in the dom0 updates available, but > I see no notice in the news section on qubes website nor here > .. > See: https://github.com/QubesOS/qubes-issues/issues/4223 and https://github.com/QubesOS/qubes-doc/pull/739 > > Seems like this happened with 28 release as well > - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlwvRUgACgkQ203TvDlQ MDANIxAAnG1X0SAoeUAtr5ySPTWsVYRIcdY3nY8RAE+LRmtAj2r6/6MBZbkCD9sl HBb4VzRZ8263xN1ERd1L5LqRqVtmnGR07jLBj9UdiZAtdZ2oUs+DHph46E+1wCbf 3TOzCO6uZzdvQAB1JUn4qCzyfdQz0jpOOpU/WOoONaj6JcPjrb07I4IUDL0d+sfd dzH/ehPCk03OUElB/h4lfbKpS0Q8z2aawreCTlgzZW3F6o6EyLkul+/GTyfCr2oy WGBlvtQfh3Agx6gvnXsIeexueNhUQEpHr8ktnGeitf29/K9qyTnL2GZ39kEhqPlY oRVEEIpZBvMYizLHo0abx5SmVH8zVx20JRJQ75S2vX8f21FIzikZbKMsn/iAH5Wj MkcKSQA+5HJ4VmmqBhs7dwR7fNByxpAidIB3/e/2i0MO1BncPoMd8n79AX+mEolA H5N/H8k2Bcb8z3vWb/IO0cVIe9dy6s7l7ZvXuJQ6IZ1KFtB/zHdz0O5jelS0c96M WY3ZSjg6x2pw/5g7i5J5C3O23ZMghm58MH84Wl19Cqm/u39PqnwLuThWyRN8JXy3 PAhq0BuvP4UWSQew67p4BIspxYJaM3Fwcv42Y+bg+dJoYgg3xnYdHHgx1Z47hQ0F 7HPmvfMl50D4LJBTkWoHgZg83yd/zOVx0ovLUSvFq0vb/hODnYc= =EMl8 -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/c4a5cb8f-6718-7054-11eb-4a20aa8044ac%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: qvm-run on R4 with Windows VM
On Friday, January 4, 2019 at 11:51:40 AM UTC+1, Lorenzo Lamas wrote: > On Sunday, December 30, 2018 at 12:53:41 PM UTC+1, Lorenzo Lamas wrote: > > On Qubes 3.2, I was able to start executables on my Windows VM through a > > launcher with a qvm-run command: > > "qvm-run -q --tray -a VMname -- 'cmd.exe /c "C:\path\to\file.exe"' " > > However, when I try this on Qubes 4, it doesn't work, the Windows VM > > doesn't even start with this command. How can I fix this? > > Adding a launcher for a application already listed in Qubes automatically > makes this command, which is different but doesn't work either and doesn't > start the VM either: "qvm-run -q -a --service -- VMname > qubes.StartApp+Programs-Accessoiries-Windows_Explorer" Rectification: the second command DOES autostart the VM, but does not start Windows Explorer. -- 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/bc59f26a-a534-4268-88e9-ea79b347fd36%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Thanks and howto install Python version >= 2.6.4 on debian-9 template?
On Fri, Jan 04, 2019 at 12:12:44AM +0100, gone wrote: > > On 1/3/19 11:51 PM, Chris Laprise wrote: > > On 01/03/2019 05:07 PM, gone wrote: > > > > > > On 1/3/19 10:45 PM, Chris Laprise wrote: > > > > On 01/03/2019 03:40 PM, gone wrote: > > > > > On 1/3/19 12:50 AM, unman wrote: > > > > > > On Wed, Jan 02, 2019 at 05:08:50PM +0100, gone wrote: > > > > > > > > > > > > > > On 1/1/19 10:19 PM, Chris Laprise wrote: > > > > > > > > On 01/01/2019 02:37 PM, gone wrote: > > > > > > > > > Hello, 1st of all, I want to thank all the > > > > > > > > > developers and supporters > > > > > > > > > for that great stuff called Qubes OS. My first question here > > > > > > > > > after > > > > > > > > > some hard time of setting up version 4.0, updating it step by > > > > > > > > > step > > > > > > > > > and studying is the following: > > > > > > > > > > > > > > > > > > I have a debian-9 template running and for some application > > > > > > > > > to get > > > > > > > > > installed on it I need Python with Version > > > > > > > > > >= 3.6 as a prerequisite. > > > > > > > > > > > > > > > > > > Since the preinstalled versions in debian-9 are 2.7 and 3.5 I > > > > > > > > > attempted to install version 3.6.4 from source as described at > > > > > > > > > https://www.rosehosting.com/blog/how-to-install-python-3-6-4-on-debian-9/ > > > > > > > > > > > > > > > > > > in order not to run into problems with incompatibilities when > > > > > > > > > switching to another repo. > > > > > > > > > > > > > > > > > > Installing the build tools with "sudo > > > > > > > > > apt-get install -y ..." worked > > > > > > > > > fine but the next step, downloading the source file, with > > > > > > > > > > > > > > > > > > "wget > > > > > > > > > https://www.python.org/ftp/python/3.6.4/Python-3.6.4.tgz; > > > > > > > > > > > > > > > > > > brings "... failed: Temporary failure in name resolution. > > > > > > > > > wget: unable to resolve host address ‘www.python.org’ " > > > > > > > > > > > > > > > > > > As I am neither an expert nor an experienced > > > > > > > > > from-source-installer I > > > > > > > > > need some help and hope to get it here. > > > > > > > > > Thanks very much in advance > > > > > > > > > and all the best for 2019. > > > > > > > > > > > > > > > > > > > > > > > > Installing from Debian testing is much easier > > > > > > > > and it has Python 3.7. > > > > > > > > Just set the default release as in the following > > > > > > > > link, then add a line > > > > > > > > for "testing" in your /etc/apt/sources.list (and > > > > > > > > then 'apt update'): > > > > > > > > > > > > > > > > https://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html#s-default-version > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks Chris for the explanation. Yes, it may be > > > > > > > easier to change to the > > > > > > > testing repo, but in general I would like to stay on > > > > > > > the stable path with > > > > > > > that template. Switching to the testing repo and > > > > > > > 'apt update' would probably > > > > > > > cause trouble with other software running smoothly > > > > > > > so far. Or can I use that > > > > > > > only for python install and then fall back? > > > > > > > > > > > > > If you follow the instructions that Chris linked to you > > > > > > should be fine. > > > > > > apt update just updates the list of available packages. It doesn't > > > > > > in > > > > > > itself do anything more. > > > > > > > > > > > > By setting the default release to stable, you ensure that you wont > > > > > > be > > > > > > "accidentally" installing stuff from testing. That will > > > > > > only happen if > > > > > > you explicitly specify the testing repo: > > > > > > apt-get -t testing install foo > > > > > > > > > > > > I'd strongly recommend aptitude, which does an excellent > > > > > > job of dealing > > > > > > with packages from different releases, and allows you to explicilt > > > > > > choose the version you want. It also lets you review in > > > > > > detail what the > > > > > > consequnces will be , so you are always able to roll back. > > > > > > > > > > > > And, of course, with Qubes it's trivial to clone the > > > > > > template, try out > > > > > > your proposed update from testing, and make sure that > > > > > > everything works > > > > > > fine before you commit your precious qubes to use the new template. > > > > > > > > > > > OK, I've done setting the default version to "testing" in > > > > > the newly created /etc/apt/apt.conf but for the additional > > > > > line in the sources.list I'm not sure, what really is to do. > > > > > > > > > > I've tried it with > > > > > > > > > > "deb http://deb.debian.org/debian stretch testing contrib non-free" > > > > > > > > > > but that seems to be wrong, as I get the following output in > > > > > the terminal: > > > > > > > > > > user@debian-9:~$ sudo apt update > > > > > Hit:1 http://deb.qubes-os.org/r4.0/vm stretch InRelease > > > > > Hit:2
[qubes-users] Re: qvm-run on R4 with Windows VM
On Sunday, December 30, 2018 at 12:53:41 PM UTC+1, Lorenzo Lamas wrote: > On Qubes 3.2, I was able to start executables on my Windows VM through a > launcher with a qvm-run command: > "qvm-run -q --tray -a VMname -- 'cmd.exe /c "C:\path\to\file.exe"' " > However, when I try this on Qubes 4, it doesn't work, the Windows VM doesn't > even start with this command. How can I fix this? Adding a launcher for a application already listed in Qubes automatically makes this command, which is different but doesn't work either and doesn't start the VM either: "qvm-run -q -a --service -- VMname qubes.StartApp+Programs-Accessoiries-Windows_Explorer" -- 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/15e2e791-bf69-4497-8410-f6cb82062f09%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] old version of xscreensaver
On 1/4/19 9:24 AM, Frédéric Pierret wrote: On 1/4/19 1:51 AM, unman wrote: On Fri, Jan 04, 2019 at 12:03:49AM +0100, Frédéric Pierret wrote: We built the upstream package of xscreensaver in current-testing for both Qubes 3.2 and 4.0. Welcome back to XFCE Chris :D ! On 1/3/19 11:56 PM, Chris Laprise wrote: On 01/03/2019 02:00 PM, Achim Patzner wrote: Am Mittwoch, den 02.01.2019, 20:42 -0800 schrieb pixel fairy: xscreensaver complains about being an old version. doubt this matters, but might scare some users. There are worse problems with it (and some of them depend on X and the hardware you're running on) which might also warrant finding something different. I just have to find some time for constant rebooting of my system to create a meaningful bug report. (To give you an idea: Imagine a machine (let's call it Lenovo P52) with multiple GPUs where certain output channels are connected to one of the GPUs only starting a screen server. If you connect your second monitor to the right port the screen saver will not blank one of them if you start X without an appropriately xorg.conf... And to make things worse it also depends on the GPU you are using and the phase of the moon.) The bad screensaver is one of the reasons I switched back to KDE, and why I recommend it to other Qubes users. The default environment doesn't rise to the level of an every day functional desktop. I fully agree - xscreensaver has lots of issues. Many of the screensavers do though. E.g. most won't survive an X server crash due to e.g. OOM killer, but your X server will probably be restarted automatically and leave your screen unprotected... In total it's not wise to trust one's screensaver for anything sincere. Is this a thing now? Is Qubes going to provide updated packages for any other software? Absolutely not. It is just because it is annoying, at least, under XFCE. -- 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/fa3bf1a3-9d4d-b859-746b-89e7a7c029eb%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qubes-users] HCL - Lenovo Thinkpad T480
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 9/7/18 5:56 PM, bbrr3...@gmail.com wrote: > On Thursday, August 23, 2018 at 2:03:55 PM UTC+1, > sagi-qub...@rtsn.nl wrote: >> You may want to track and/or contribute to: >> https://github.com/QubesOS/qubes-issues/issues/3689 >> https://github.com/QubesOS/qubes-issues/issues/3705 >> >> In any case, I'd be interested to hear the details of your >> workaround. > > As far as I recall it was simply: > > qvm-pci detach sys-usb dom0:3c_00.0 Just for the record: As leaving potentially dangerous devices (and physical connectors) in dom0 is not the best advice, and there is a BIOS option to solve this issue at "hardware" level: Thunderbolt BIOS Assist: if enabled, the mentioned device - causing the hibernation issues - are gone, then only one USB device remains, which is works without problems. Confirmation needed: As I do not have any Type-C devices, I can't check if that is still working in this case or not. Moreover, if you don't need the thunderbolt at all, it can be disabled completely from BIOS. Hence then the USB-C connector lost its functionality for sure. - -- Zrubi -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEmAe1Y2qfQjTIsHwdVjGlenYHFQ0FAlwvI+0ACgkQVjGlenYH FQ0/vg//QWJ76wGz7O0UCC8yrPvgjHRYBjy6O+3YCKlGo72M48rOEV4zihy2X6z/ cjkImZkytwbY4JXGp3STCAafM/0X456DQqxTZYNZRNqa8H3HiSt3Iu5fCu90S3I/ eNTA2TWGy3MYheXhuRu5e1lf9zBwZ2yRbZoW076Y0hbS/Z0hNZPnIE7sEAZiZLHk TsdSCyPqcoQA1J2yoA2VfR9XhTWbTDmxplyV6OCjKIM+v2KevmQOeFgsXyH7qKXV O2lKbS+ZolFjIEYqh6+Fcnsjxgqrb3Fq00CczUbFLCe7kla4K9dJncvyxeiFlLiZ l+1b19HAWCAXtbJKiqx19dRq/tj7mDQ3GXIQdjn8g0pRn1Cfpm1GtZUTPbOzLNzE +L31eZwpC3yJm9WY9mNa4mQ0PDqnsuv7OGxjeW/6kXwdNkOzZL0+TW2jcCfsSLdC vjwONknsnIbjmPgfaIdGWHfwPAW/7eLkiT2qvbPCUEFNktAkOUxDg3wH8fWFIDIH C72bpqrXLXOvs7gmEzf5L1Vt89gAlokH4g67BZz9jGCrvv9RBbQN3mCL5Ftuf/d+ g3gBA7lfGY1NNg50s3CGsDUtuFDgJUU/K7Yq2SudQousARVymIbThEgGd8bPKcbU xe6l9WUTtfSIOfwFh/uuSjfmyLbpSqVF3PtiCbecOpEH+tH4BS4= =ft4g -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/eaf6f342-080a-f073-4cdf-3edc16e29632%40zrubi.hu. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] old version of xscreensaver
On 01/03/2019 06:03 PM, Frédéric Pierret wrote: We built the upstream package of xscreensaver in current-testing for both Qubes 3.2 and 4.0. Welcome back to XFCE Chris :D ! LOL, seriously? The XFCE deficits are too numerous, unfortunately. Dear Chris, for less advanced users it might be helpful to have a non-dogmatic discussion on advantages and disadvantages of both sides. I guess that XFCE has speed on its side, for example. Visual aspects seems on the KDE side (at least for me). I invite you to give us a deeper comparison... best, Bernhard -- 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/1f38481a-8ef0-88e5-fa73-859111bd0104%40web.de. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] old version of xscreensaver
On 1/4/19 1:51 AM, unman wrote: > On Fri, Jan 04, 2019 at 12:03:49AM +0100, Frédéric Pierret wrote: >> We built the upstream package of xscreensaver in current-testing for >> both Qubes 3.2 and 4.0. >> >> Welcome back to XFCE Chris :D ! >> >> On 1/3/19 11:56 PM, Chris Laprise wrote: >>> On 01/03/2019 02:00 PM, Achim Patzner wrote: Am Mittwoch, den 02.01.2019, 20:42 -0800 schrieb pixel fairy: > xscreensaver complains about being an old version. doubt this > matters, but might scare some users. There are worse problems with it (and some of them depend on X and the hardware you're running on) which might also warrant finding something different. I just have to find some time for constant rebooting of my system to create a meaningful bug report. (To give you an idea: Imagine a machine (let's call it Lenovo P52) with multiple GPUs where certain output channels are connected to one of the GPUs only starting a screen server. If you connect your second monitor to the right port the screen saver will not blank one of them if you start X without an appropriately xorg.conf... And to make things worse it also depends on the GPU you are using and the phase of the moon.) >>> The bad screensaver is one of the reasons I switched back to KDE, and >>> why I recommend it to other Qubes users. The default environment >>> doesn't rise to the level of an every day functional desktop. >>> > Is this a thing now? Is Qubes going to provide updated packages for any > other software? > Absolutely not. It is just because it is annoying, at least, under XFCE. -- 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/ebca4da5-1017-e2fd-311d-213db323dab9%40qubes-os.org. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
