Re: [qubes-users] after update no VM 'starts' apps anymore.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-01-29 19:51, 'awokd' via qubes-users wrote: > On Tue, January 30, 2018 12:05 am, 'Tom Zander' via qubes-users > wrote: >> Is this a known issue? >> >> >> I can start a VM using qvm-start, but when I use qvm-run nothing >> happens, it hangs forever. Even commands that don't need a X >> server. For any qube of the various OSs I run. > > qvm-run works on both powered on and off VMs on my 4.0 on testing > repo. qvm-run works on powered on (only) VMs on my 3.2 stable. > Are you using the `-a` option? qvm-run -a This starts the VM if it's powered off, then runs the command in it. Working fine for me on 3.2. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlp6p/MACgkQ203TvDlQ MDADKw//cWINAKpW/PM44bVJ+hm8iF++MzeH/kG8XNwvWRWWlOQbk0YkByvM5njN SpWW08MLs8b5X9hQvRzAoJbE1eC4I4jrojXcx2f/FPvCShlIkhwkAoPetFuXl1Zq HrYxhlbmB8u8efI6w4hTb6Re5iOoCXKGhlUtisvcapc6EGUcg5R9Yc1l6y2KrVES RPHpNyDJx4ULs7Moqjk9NyjUSy5a0ehklxtzggBuNUg5i6RejyuJ+isHG4TefSn3 gh1rX0JIhhJZc8zgEO9swjQGwYYy45fSmAK6lSB20MHCtQvWwXsVyZ+JR1/p9Lad Znscp6T5A6Iz3mIAlBRE3+4V8BR3iF8IxS9PfJEkDXnnNCbnKs24hkj/qg42HDMF 1Qx09TS4y3MZLYRZOuVc0TCtnahR3T92RVat1Ne5gtVbU+Hg2EToaZwmAHtLUXoD nOQLTFCYlw4GuKiigDLjE+edo16G3IUtHjahuydgnl15HRqPjYa33NvdG1hxCIPL /vUUW9C5Z5ooMYcTpnKEXzpHkaKeOtSxP8NLs0hG0VWyO93VTEbrYdeyzR/alaOm txyufMGl9gSg21OaPXa4y86l2lN05FRrOsWxRUCRZ+61nE5ZGQxOKiLoEe5F61/u qA/Nk+VaZSzWAvGbCwDqLDcAfw3KxMCpBZdlPeR2azU8VbY09EU= =RaBw -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/8a313e38-6b5d-27d0-9a85-60bef3c1a80f%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Fedora-minimal und Q. 4.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-02-06 17:05, Jo wrote: > Apologizes for being so unspecific, i actually meant missing > both.T The command qvm-convert-pdf is not recognized. I found the > pdf-converter on github, therefore, i will manually install it > within the template. > > Another thing/bug i noticed actually right now: My sys-vpn > (fedora-26-minimal) are missing the options "Copy/move to vm" and > "open in Dispvm" in the GUI-context menu.However, the command > qvm-copy-to-vm is recognized and working. Im unsure what is > triggering this bug, since my usb-vm is also based on a > fedora-26-minimal template but does have the gui-entrys/the > qvm-copy function > > cheers > Thanks. Updated the issue. P.S. - Please try to avoid top-posting. > On 02/06/18 02:21, Andrew David Wong wrote: >> On 2018-02-05 08:47, Jo wrote: >>> Cheers folks, >> >>> because of the switch to 4,0 im currently setting up a complete >>> new system-structure, and therefore, i wanted to base all the >>> sys-vms on fedora minimal templates. >> >>> However, im missing a few qubes-specific functions and >>> couldnt find informations on what to install to get them. Ive >>> installed all the necessary packages mentioned in the >>> Documentation, but the "convert to trusted PDF/IMG function" is >>> still missing. >> >>> Any hints which package i need to add? >> >> >> When you say that it's "missing," does you mean that the CLI tool >> is missing, or the option is missing from the GUI context menu, >> or both? >> >> In either case, this sounds like this might be an oversight. >> Tracking: >> >> https://github.com/QubesOS/qubes-issues/issues/3543 >> - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlp6iBwACgkQ203TvDlQ MDC/uA/+LgrqQAoakeEcZBK+25Yr+9PCqMF++0Yhh0L7VxENhxX9NDlTmcn7UAjt KIzuXcwU4b+Dl+v+Q5aC5BarH74X6fZKiymiDSguZCpF+2HN8nAhW3QAXKKkA9H8 MvyMOvqpkzWCcx2u4wKI7/ZqFsxNDl1PVhF/o7ir/Eq2wX+RKdU67pwVacdx4nln uVmIeAZP7EABGj9MLyfQ0Fo45p2JedtP4M4+uDU5c7fmN1ZgrKkv6SmEqnSUxOiK MSstTdiM/Z9Hwe8+S/ItFMnoh3CaTpu6PMOwP0imUKP7ZUO7xkPuuHJviQDLnnRF TotePcMsrnKB+SwuyvwWjbZfLqJL3YE1FoEcVsp+dEm7wcNmKwwnicXnn+DuMujx J5xu6+I9y0L8tkhRS53t6aPi1b24xXaHexvCxvPztfySUNFnLmI6etl7UzuT4VkL 1GRg2sansswPJPwhCaI9vWHPLTgiSfnhZLRJL1582evnZ6mjebW+PzfLwYY50KNG NXYI8/AFRK/GmIMTqNrBjyruOD4sj7PCMgKL1P9Y9K/SlRF/pFgPL1lZJG81Aj8j zPaXTwkKR8rkksDy7XzMxrXfxM/hhUCshQQrfGmjcY3yYHxF+Pr9RQmi3QpQbAV4 nc13D+UVR4qP8+wLxigR3K+t5iE23Zdh6WDd8pgmCh1ygYe1bnc= =wC/4 -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/1b04dbe2-3b32-5a4a-565a-d867b313a0b0%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL report for Lenovo ThinkPad T520 4240-4HG
Hello, See attached. Regarding BIOS settings mentioned in "remark": the combination of both VT-d and Discrete Graphics being ON causes the installer to freeze. If configured post-install, it causes the OS to freeze while booting. Turning VT-d OFF allows for installation (with warning) but breaks networking and who knows what else. As the remark states, the proper configuration is VT-d ON and Discrete Graphics OFF. jh -- 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/abca4a31-59a1-65e2-f37c-a75fd9107923%40journey.sk. For more options, visit https://groups.google.com/d/optout. Qubes-HCL-LENOVO-42404HG-20180206-203645.yml Description: application/yaml
Re: [qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?
On Sun, Feb 4, 2018 at 4:14 PM, 'Tom Zander' via qubes-users < qubes-users@googlegroups.com> wrote: > On Sunday, 4 February 2018 18:10:44 CET Yuraeitha wrote: > > Also it's been explicitly said that no Qubes 4 existing features will be > > added to the new-old Qube Manager. Which might also hint towards no > > changes coming to Qube Manager. If anything, it has to be re-made almost > > entirely to work well with Qubes 4+, and currently no one is doing that. > > The Qubes Manager is written to Qt4, which is equally outdated as the > backends of Qubes it used (3.x). > > I started a project using Qubes4-api and Qt5 APIs, though. See Ps at the > bottom of the mail. > > [start rant] > > The biggest issue i ran into is that Qubes4 is just too immature to > actually > use for more than browsing and email. It was too painful for my desktop > full-time work machine. > I tried for 2 months, my significant other stated that I had been > extraordinary patient with Qubes when I finally stopped using it ;) > > My problems are widespread; > * the admin-api is very immature and poorly implemented. Getting a stack- > trace in the server logs and no answer is just unacceptable. Unit tests, > anyone? > * system-tray is hopelessly broken. Losing apps because they don't show in > the system-tray up when you close them was fun! > * The design of qubes-daemon is too fragile, it starts/stops VMs and > patiently waits and hopes everything will work. I expected a much more > 'hands-on' approach (at least for Linux kernels) with much more reporting. > I > also lost data because apps aren't being quit, they are being killed on VM > shutdown. > * Why do I see 'lock'-icons for most of my windows in the task-bar? > * the documentation is very out-of-date. > * I don't know how, it may be fedora packaging, it may be qubes packaging > or > configs, but the amount of KDE (apps running in dom0) crashes I had in the > 2 > months of using Qubes is greater than the amount i had in the previous 5 > years. This boggles the mind... > * The graphics pipeline is hopelessly outdated. Its about a decade behind > the industry. > * Poor quality of many tools, the icon-copier copying the 22px icon from a > VM instead of the 256 one that was also there is just... sad. > * The amount of services, bash-scripts, config files, duplicated data in > qubes and then again in the system is horrible, under documented mess. > * rexecd validation being implemented using bash is a joke (mostly felt > because its extremely slow) > * total lack of mature end-user-focused tools. Swear to God. There are zero > today. > * Having nothing but python APIs for your operating system is something > that > makes no sense. Python was never meant for servers, or even big > applications. Finding a full-stack python developer is more rare than > finding a Bitcoin C++ developer. > > end-rant. > > Qubes is an amazing idea, has some fantastic and genius concepts in it. > I hope many of those things will get fixed, although the list has grown so > long that I'm not sure it can without being forked. > > @Tom I am here from the first release of Qubes and every new major release it was the same: a major remake breaking almost everything that was working fine. The miracle was that over time devs were able to fix it again. How much time? About one year. So I am still using 3.2 with no plan to upgrade anytime soon. So I understand that if you are using R4 as your daily operative machine it may be too much. Also in your case the situation is even worse because you are dealing with the GUI which will be the last to be fixed. But it will be fixed faster than you think as always happened in the past. Also I have a strong feeling that this will be the last major remake, so there will be plenty of time to polish it. Are you in a hurry? Take your time, open your heart to the community as you have done now. Ask what you need and be faithful, it will be done. You cannot impose your rhythm to a project like Qubes because resources are really very limited, this is why you finished your patience. But just adapt to Qubes own rhythm and you'll enjoy this wonderful community and this awesome project. Your GUI needs will be a strong stimulus to pay more attention to the needs of ends users. Often developers see only their needs. Well it is natural specially in an open source project. But end users are the only ones able to confirm the real success of a project over time. But try also to understand if there are conditions for your Qubes Manager to be incorporated as an official tool. You wrote you accepted my offer to cover some efforts of a rewritten Qubes Manager with $5000. Do not leave me with this money, rather help us promote the idea that end users should pay for what is directly done for them like GUI. Best Fran -- 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 t
[qubes-users] 4.0-rc4 install on Lenovo G505S - no network
I've installed rc4 on G505S with Coreboot (legacy bios). Installation went ok (found iommu and interrupt remapping just fine). On 1st (gui) boot, I've tried all the combinations selecting 1) create ServiceVMs, AppVMs, 2) only ServiceVMs, 3) only configure templates,... but none works. It always hangs at Configuring 1st template (usually debian-9). If I reboot, and attempt the same thing, I see it prepends tmp- for tmp-debian-9, and hangs while configuring again (and keeps prepending tmp-tmp-debian-9 on consequent runs, and halts). I then re-installed, and proceeded with last option. So I did Advanced option (only creates dom0, no other VMs). Here I attempted to run 'firstboot-qubes-text' manually, but that fails for each one of the 4 options with the same error: Failed to disable unit: No such file or directory Failed to sotp kdump.service: Unit kdump.service not loaded. -> Configuring template debian-9... usage: qvm-start [-h] [--verbose] [--quiet] [--all] [--exclude EXCLUDE] [--skip-if-running] [--drive DRIVE | --hddisk IMAGE | --cdrom IMAGE | --install-windows-tools] [VMNAME [VMNAME ...]] qvm-start: error: no such domain: 'debian-9' This is what I see in /var/lib/qubes/vm-templates [root@dom0 vm-templates]# du -sk * | sort -n 1951428 whonix-gw 2431376 whonix-ws 2760892 debian-9 3599232 fedora-26 So templates are installed, but they are somehow not visible to qubes (they also don't show up in Qube Manager (only dom0 does)). Looking at some anaconda scripts (qubes-os.py), I noticed this call: qvm-template-postprocess --really 'post-install' fedora-26 /var/lib/qubes/vm-templates/fedora-26 Tried running it, but it produces a lot of errors, final one: qubesadmin.exc.QubesDaemonNoResponseError: Got empty response from qubesd. See journalctl in dom0 for details. Can you please let me know what should I focus on, to complete configuring the templates, and other standard qubes (sys-net, sys-firewall, personal, work...)? At this point obviously the system doesn't have the network access. -- 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/03ba5300-bb33-488c-b373-2c21fcdac0d1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Yubikey with smartcard and HOTP together
Be interested to see if that functionality can be made to work smoothly. I could be wrong but sounds like the yubikey would have to be reset as a regonized device for that to work. Something has to reintialize the keyboard function as that is released once the device is assigned to a vm. That is if I am understanding it correctly. -- 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/e73cd166-6b78-4b3d-82b8-88d889cdfca1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes 4.0 without IOMMU/VT-d/AMD-Vi or Interrupt Remapping
Forgot to add: It is a shame that qubes doesn't support POWER. Due to the ceasing of manufacturing of the KGPE-D16 and D8 boards the OpenPOWER9 TALOS 2 is soon the only reasonable brand new option for a performance board with libre firmware/hardware. It is of course possible to make a virtualization setup on POWER with different security zones but it wouldn't be as slick as qubes and you would lack xen's security features like stubdoms although arguably it would still be more secure than a modern intel/amd system that has ME/PSP and a litany of other anti-features and security holes. Info: * In terms of speed even the base 4 core CPU is faster than a fully loaded dual 6386SE KGPE-D16 system, and much faster than an intel/amd system one would buy for the $2.5K price of the TALOS 2 board/4 core cpu combo. * OpenPOWER sforza has SMT4 with 4 threads per core so even the base 4 core CPU is very fast, the system maxes out at 96 threads with dual 24 core CPU's. * It has a nice open source secure IBM OpenBMC firmware for remote management, PCI-e 4.0 with CAPI, POWER IOMMU and POWER-KVM (virtualization) * There is absolutely no hardware code signing enforcement, you can even load your own microcode (and if you are an EE/CS masters, learn how to make modifications via the IBM provided documentation!) * When they first were released a brand new KGPE-D16 and a 6386SE would cost more than the TALOS 2 board/cpu, so it is a reasonable price (it came down a lot from the previous POWER generation) * IBM immediately released complete spectre fixes. -- 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/df790981-e211-c683-ba81-6ee3a1087638%40gmx.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Can't seem to build qubes 3.2
On Tuesday, February 6, 2018 at 3:48:26 PM UTC-8, Tim W wrote: > Are you running the ./setup or using the build.conf example? If the later > look at awokd's link and follow those steps. > > https://github.com/QubesOS/qubes-issues/issues/3426 > > > That is how I have been building qubes iso and separate templates since ver > 3.1. Do not follow any of the steps to edit conf files etc in the linked > instructions above. Just follow the cmds as those issues have been fixed. > > Pick fc26 (optional fc26minimal) stretch (optional stretch minimal) and the 2 > whonix templates. You tech can add all the fc26 and Stretch template choices > as they all should build based off my tests results. You would need more > disk space though. I could be off but I think adding 5 gig per extra > template you add should keep you with enough build space. Start at 60 gig > for standard build and go up from there. They build in fc23 fc25 i have seen > people post issues using fc27 but have no idea if its version related or not. I was building with ./setup, I'm just trying to get a new kernel into a 3.2 iso so I can install qubes on my Thinkpad. -- 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/1370ee6e-35cf-40e5-b655-098a4c7f1301%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?
On Tuesday, 6 February 2018 23:22:26 UTC, awokd wrote: > On Tue, February 6, 2018 11:09 pm, Alex Dubois wrote: > > > I do not address the main part because I believe there is a bug with > > /rw/config/qubes-firewall-user-script not triggering on network change > > that I want to report and get an understanding on how it will be > > addressed. > > This one? https://github.com/QubesOS/qubes-issues/issues/3260 Yes thanks found it and commented on my needs in this type of context. for example, I spin up a web server, I need the FirewallVM to get a hook to update it's firewall rules accordingly. -- 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/f1526012-cfa2-44bd-9165-7bdfffdd464f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Can't seem to build qubes 3.2
Are you running the ./setup or using the build.conf example? If the later look at awokd's link and follow those steps. https://github.com/QubesOS/qubes-issues/issues/3426 That is how I have been building qubes iso and separate templates since ver 3.1. Do not follow any of the steps to edit conf files etc in the linked instructions above. Just follow the cmds as those issues have been fixed. Pick fc26 (optional fc26minimal) stretch (optional stretch minimal) and the 2 whonix templates. You tech can add all the fc26 and Stretch template choices as they all should build based off my tests results. You would need more disk space though. I could be off but I think adding 5 gig per extra template you add should keep you with enough build space. Start at 60 gig for standard build and go up from there. They build in fc23 fc25 i have seen people post issues using fc27 but have no idea if its version related or not. -- 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/b392158d-f3a4-4d31-a80f-d2a9a1ade1ad%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes 4.0 without IOMMU/VT-d/AMD-Vi or Interrupt Remapping
5he nice thing going forward is most newer processors are coming with the iommu etc where just 2 years ago it was at least 2x less choices. The real issue these days is making sure the bios/efi software is supporting it to the standard and not some half baked abortion of what it should be. Its one of the reasons the lenovo thinkpads are the first choice. If they had not switched away from coreboot or allowing it to be swapped in it would be about as good as you could get with an current cpu. My 440p has been great running qubes and fully supports 4.0 as well. 16g ram has been plenty for a laptop (not workstation replacement). For a workstation I would rather build one so I could have as close to an ideal config as possible but certainly not cheap $ option. -- 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/19c78800-bc6a-49e3-b674-9af1b8bb5bbc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Can't seem to build qubes 3.2
On Tuesday, February 6, 2018 at 3:23:37 PM UTC-8, Unman wrote: > On Tue, Feb 06, 2018 at 03:06:32PM -0800, Alchemist wrote: > > On Tuesday, February 6, 2018 at 3:00:39 PM UTC-8, Alchemist wrote: > > > On Tuesday, February 6, 2018 at 2:47:29 PM UTC-8, Unman wrote: > > > > On Tue, Feb 06, 2018 at 02:27:57PM -0800, Alchemist wrote: > > > > > On Tuesday, February 6, 2018 at 5:15:34 PM UTC-5, Unman wrote: > > > > > > On Tue, Feb 06, 2018 at 02:02:47PM -0800, Alchemist wrote: > > > > > > > So I follow the build guide instructions, I have No_Sign=1, but > > > > > > > for some reason the build script fails by telling me that the > > > > > > > package is unsigned. > > > > > > > > > > > > > > Fedora 27 is my build system. > > > > > > > > > > > > > > Any ideas? > > > > > > > > > > > > > You'll really have to give us a clue - which package is unsigned? > > > > > > You can turn on DEBUG and VERBOSE in builder.conf if you don't > > > > > > already > > > > > > have them. > > > > > > Then check the logs in build-logs and see exactly what is happening. > > > > > > > > > > Sorry about that, > > > > > > > > > > /qubes-builder/cache/fc23/base_rpms/acl-2.2.52-10.fc23.x86_64.rpm is > > > > > not signed. Exiting! > > > > > make[1]: *** > > > > > [/home/liveuser/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86: > > > > > /home/liveuser/qubes-builder/chroot-fc23/home/user/.prepared_base] > > > > > Error 1 > > > > > > > > > > is the error I get, I turned on Debug and Verbose, but there's > > > > > nothing in build-logs. > > > > > > > > > Ok, so that's an issue with that package from Fedora. It isn't to do > > > > with > > > > signing or not signing the packages that you are building. > > > > Just delete that rpm and try the build again. > > > > > > I deleted it, and it still is giving me the same error. > > > > Here's the entire area of the log: > > > > [SKIPPED] libusbx-1.0.21-0.1.git448584a.fc23.x86_64.rpm: Already downloaded > > > > (154/154): acl-2.2.52-10.fc23.x86_64.rpm 44 kB/s | 77 kB 00:01 > > > > > > Total38 kB/s | 77 kB 00:02 > > > > Complete! > > The downloaded packages were saved in cache until the next successful > > transaction. > > You can remove cached packages by executing 'dnf clean packages'. > > + rm -f /tmp/tmp.q6KHM6Y1gW > > + echo '-> Verifying signatures...' > > -> Verifying signatures... > > + set +x > > Filename: > > /home/x/qubes-builder/cache/fc23/base_rpms/acl-2.2.52-10.fc23.x86_64.rpm is > > not signed. Exiting! > > make[1]: *** > > [/home/x/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86: > > /home/x/qubes-builder/chroot-fc23/home/user/.prepared_base] Error 1 > > make[1]: Leaving directory '/home/x/qubes-builder' > > make: *** [Makefile:224: vmm-xen-dom0] Error 1 > > > > Can you go to cache and test it: > rpm -qpi should show you the details [x@localhost base_rpms]$ rpm -qpi acl-2.2.52-10.fc23.x86_64.rpm warning: acl-2.2.52-10.fc23.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 34ec9cba: NOKEY Name: acl Version : 2.2.52 Release : 10.fc23 Architecture: x86_64 Install Date: (not installed) Group : System Environment/Base Size: 187824 License : GPLv2+ Signature : RSA/SHA256, Tue 08 Sep 2015 08:24:19 AM PDT, Key ID 32474cf834ec9cba Source RPM : acl-2.2.52-10.fc23.src.rpm Build Date : Tue 08 Sep 2015 04:47:35 AM PDT Build Host : buildvm-17.phx2.fedoraproject.org Relocations : (not relocatable) Packager: Fedora Project Vendor : Fedora Project URL : http://acl.bestbits.at/ Summary : Access control list utilities Description : This package contains the getfacl and setfacl utilities needed for manipulating access control lists. -- 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/840608cf-d3fb-49fd-a344-a06f554f4c7b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Can't seem to build qubes 3.2
On Tue, Feb 06, 2018 at 03:06:32PM -0800, Alchemist wrote: > On Tuesday, February 6, 2018 at 3:00:39 PM UTC-8, Alchemist wrote: > > On Tuesday, February 6, 2018 at 2:47:29 PM UTC-8, Unman wrote: > > > On Tue, Feb 06, 2018 at 02:27:57PM -0800, Alchemist wrote: > > > > On Tuesday, February 6, 2018 at 5:15:34 PM UTC-5, Unman wrote: > > > > > On Tue, Feb 06, 2018 at 02:02:47PM -0800, Alchemist wrote: > > > > > > So I follow the build guide instructions, I have No_Sign=1, but for > > > > > > some reason the build script fails by telling me that the package > > > > > > is unsigned. > > > > > > > > > > > > Fedora 27 is my build system. > > > > > > > > > > > > Any ideas? > > > > > > > > > > > You'll really have to give us a clue - which package is unsigned? > > > > > You can turn on DEBUG and VERBOSE in builder.conf if you don't already > > > > > have them. > > > > > Then check the logs in build-logs and see exactly what is happening. > > > > > > > > Sorry about that, > > > > > > > > /qubes-builder/cache/fc23/base_rpms/acl-2.2.52-10.fc23.x86_64.rpm is > > > > not signed. Exiting! > > > > make[1]: *** > > > > [/home/liveuser/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86: > > > > /home/liveuser/qubes-builder/chroot-fc23/home/user/.prepared_base] > > > > Error 1 > > > > > > > > is the error I get, I turned on Debug and Verbose, but there's nothing > > > > in build-logs. > > > > > > > Ok, so that's an issue with that package from Fedora. It isn't to do with > > > signing or not signing the packages that you are building. > > > Just delete that rpm and try the build again. > > > > I deleted it, and it still is giving me the same error. > > Here's the entire area of the log: > > [SKIPPED] libusbx-1.0.21-0.1.git448584a.fc23.x86_64.rpm: Already downloaded > > (154/154): acl-2.2.52-10.fc23.x86_64.rpm 44 kB/s | 77 kB 00:01 > > > Total38 kB/s | 77 kB 00:02 > > Complete! > The downloaded packages were saved in cache until the next successful > transaction. > You can remove cached packages by executing 'dnf clean packages'. > + rm -f /tmp/tmp.q6KHM6Y1gW > + echo '-> Verifying signatures...' > -> Verifying signatures... > + set +x > Filename: > /home/x/qubes-builder/cache/fc23/base_rpms/acl-2.2.52-10.fc23.x86_64.rpm is > not signed. Exiting! > make[1]: *** > [/home/x/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86: > /home/x/qubes-builder/chroot-fc23/home/user/.prepared_base] Error 1 > make[1]: Leaving directory '/home/x/qubes-builder' > make: *** [Makefile:224: vmm-xen-dom0] Error 1 > Can you go to cache and test it: rpm -qpi should show you the details -- 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/20180206232333.uui7dpgjllu6kaos%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?
On Tue, February 6, 2018 11:09 pm, Alex Dubois wrote: > I do not address the main part because I believe there is a bug with > /rw/config/qubes-firewall-user-script not triggering on network change > that I want to report and get an understanding on how it will be > addressed. This one? https://github.com/QubesOS/qubes-issues/issues/3260 -- 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/243e6bcc7071c0525b75d8421aee99a7.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Can't seem to build qubes 3.2
On Tue, February 6, 2018 10:47 pm, Unman wrote: > On Tue, Feb 06, 2018 at 02:27:57PM -0800, Alchemist wrote: > >> On Tuesday, February 6, 2018 at 5:15:34 PM UTC-5, Unman wrote: >> >>> On Tue, Feb 06, 2018 at 02:02:47PM -0800, Alchemist wrote: >>> So I follow the build guide instructions, I have No_Sign=1, but for some reason the build script fails by telling me that the package is unsigned. Fedora 27 is my build system. Might want to try Fedora 25 instead? -- 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/daff058c02b869866d7eade50ad0a15d.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Can't seem to build qubes 3.2
I have been having isses with fedoras repo over the last few days while compiling both 3.2 and 4.0. I have stopped using make qubes all together and instead compile the packages in small groups or individually. I can then redo a package a few times without starting over. I have been able to compile a number of different template configs. So far it seems the non standard templates fail with python script or config errors. Fedora 25 works other than the fc25fullyloaded template. Centos fails as does Xenial Ubuntu. I had issues with archlinux as well but have not tried it package by package so it might work. They may build fine as templates only but they do not when rolled into a qubes os iso build. Im putting together a list of the failures to post once Im done so we can look over and fix the issues. -- 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/731060d9-fbfc-45db-b97a-89beee2b245d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?
On Tuesday, 6 February 2018 15:04:52 UTC, Alex Dubois wrote: > On Tuesday, 6 February 2018 10:32:16 UTC, awokd wrote: > > On Mon, February 5, 2018 6:18 pm, 'awokd' via qubes-users wrote: > > > On Mon, February 5, 2018 6:01 pm, 'Tom Zander' via qubes-users wrote: > > > > >> If someone can figure out how to port-forward in 4.0, please do update > > >> the docs. I never managed to get that working. > > > > I see what you mean. If I follow > > https://www.qubes-os.org/doc/firewall/#port-forwarding-to-a-qube-from-the-outside-world > > on R4.0, I'm not getting past the first step of: > > > > Verify you are cutting through the sys-net VM firewall by looking at its > > counters (column 2) > > > > iptables -t nat -L -v -n [counters increasing] > > > > iptables -L -v -n [not] > > > > I wonder if it's an nft vs. iptables thing? Interestingly, this procedure > > works fine: > > https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes > > . > > I did this doc long long ago. 4.0 has a new networking model. I've just > upodated to v4, I'll review it... sorry... OK, networking is working in R4rc4, I have it working fine with a dozen of VM + my intranet traffic at home routing through QubesOS. I've started to update the doc here: https://github.com/adubois/qubes-doc/blob/master/security/firewall.md I am about to do a pull request for this first update. I do not address the main part because I believe there is a bug with /rw/config/qubes-firewall-user-script not triggering on network change that I want to report and get an understanding on how it will be addressed. -- 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/4fd5212e-bf60-4216-b84c-2cf0d00f844c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Can't seem to build qubes 3.2
On Tuesday, February 6, 2018 at 3:00:39 PM UTC-8, Alchemist wrote: > On Tuesday, February 6, 2018 at 2:47:29 PM UTC-8, Unman wrote: > > On Tue, Feb 06, 2018 at 02:27:57PM -0800, Alchemist wrote: > > > On Tuesday, February 6, 2018 at 5:15:34 PM UTC-5, Unman wrote: > > > > On Tue, Feb 06, 2018 at 02:02:47PM -0800, Alchemist wrote: > > > > > So I follow the build guide instructions, I have No_Sign=1, but for > > > > > some reason the build script fails by telling me that the package is > > > > > unsigned. > > > > > > > > > > Fedora 27 is my build system. > > > > > > > > > > Any ideas? > > > > > > > > > You'll really have to give us a clue - which package is unsigned? > > > > You can turn on DEBUG and VERBOSE in builder.conf if you don't already > > > > have them. > > > > Then check the logs in build-logs and see exactly what is happening. > > > > > > Sorry about that, > > > > > > /qubes-builder/cache/fc23/base_rpms/acl-2.2.52-10.fc23.x86_64.rpm is not > > > signed. Exiting! > > > make[1]: *** > > > [/home/liveuser/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86: > > > /home/liveuser/qubes-builder/chroot-fc23/home/user/.prepared_base] Error > > > 1 > > > > > > is the error I get, I turned on Debug and Verbose, but there's nothing in > > > build-logs. > > > > > Ok, so that's an issue with that package from Fedora. It isn't to do with > > signing or not signing the packages that you are building. > > Just delete that rpm and try the build again. > > I deleted it, and it still is giving me the same error. Here's the entire area of the log: [SKIPPED] libusbx-1.0.21-0.1.git448584a.fc23.x86_64.rpm: Already downloaded (154/154): acl-2.2.52-10.fc23.x86_64.rpm 44 kB/s | 77 kB 00:01 Total38 kB/s | 77 kB 00:02 Complete! The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. + rm -f /tmp/tmp.q6KHM6Y1gW + echo '-> Verifying signatures...' -> Verifying signatures... + set +x Filename: /home/x/qubes-builder/cache/fc23/base_rpms/acl-2.2.52-10.fc23.x86_64.rpm is not signed. Exiting! make[1]: *** [/home/x/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86: /home/x/qubes-builder/chroot-fc23/home/user/.prepared_base] Error 1 make[1]: Leaving directory '/home/x/qubes-builder' make: *** [Makefile:224: vmm-xen-dom0] Error 1 -- 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/545d3975-8ac1-4466-b032-7fa73a48b138%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Can't seem to build qubes 3.2
On Tuesday, February 6, 2018 at 2:47:29 PM UTC-8, Unman wrote: > On Tue, Feb 06, 2018 at 02:27:57PM -0800, Alchemist wrote: > > On Tuesday, February 6, 2018 at 5:15:34 PM UTC-5, Unman wrote: > > > On Tue, Feb 06, 2018 at 02:02:47PM -0800, Alchemist wrote: > > > > So I follow the build guide instructions, I have No_Sign=1, but for > > > > some reason the build script fails by telling me that the package is > > > > unsigned. > > > > > > > > Fedora 27 is my build system. > > > > > > > > Any ideas? > > > > > > > You'll really have to give us a clue - which package is unsigned? > > > You can turn on DEBUG and VERBOSE in builder.conf if you don't already > > > have them. > > > Then check the logs in build-logs and see exactly what is happening. > > > > Sorry about that, > > > > /qubes-builder/cache/fc23/base_rpms/acl-2.2.52-10.fc23.x86_64.rpm is not > > signed. Exiting! > > make[1]: *** > > [/home/liveuser/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86: > > /home/liveuser/qubes-builder/chroot-fc23/home/user/.prepared_base] Error 1 > > > > is the error I get, I turned on Debug and Verbose, but there's nothing in > > build-logs. > > > Ok, so that's an issue with that package from Fedora. It isn't to do with > signing or not signing the packages that you are building. > Just delete that rpm and try the build again. I deleted it, and it still is giving me the same error. -- 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/2d2ac64b-a3cf-4d5d-82da-059d44a63a6a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Can't seem to build qubes 3.2
On Tue, Feb 06, 2018 at 02:27:57PM -0800, Alchemist wrote: > On Tuesday, February 6, 2018 at 5:15:34 PM UTC-5, Unman wrote: > > On Tue, Feb 06, 2018 at 02:02:47PM -0800, Alchemist wrote: > > > So I follow the build guide instructions, I have No_Sign=1, but for some > > > reason the build script fails by telling me that the package is unsigned. > > > > > > Fedora 27 is my build system. > > > > > > Any ideas? > > > > > You'll really have to give us a clue - which package is unsigned? > > You can turn on DEBUG and VERBOSE in builder.conf if you don't already > > have them. > > Then check the logs in build-logs and see exactly what is happening. > > Sorry about that, > > /qubes-builder/cache/fc23/base_rpms/acl-2.2.52-10.fc23.x86_64.rpm is not > signed. Exiting! > make[1]: *** > [/home/liveuser/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86: > /home/liveuser/qubes-builder/chroot-fc23/home/user/.prepared_base] Error 1 > > is the error I get, I turned on Debug and Verbose, but there's nothing in > build-logs. > Ok, so that's an issue with that package from Fedora. It isn't to do with signing or not signing the packages that you are building. Just delete that rpm and try the build again. -- 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/20180206224726.ggd5zglyzqloi2ot%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: [qubes-devel] Qubes OS 4.0-rc4 has been released!
strange. starting VMs is much slower for me and a minion than 4rc3 or 3.2 were. even vm performance seems slower. for example typing in and scrolling in windows in firefox is slower, though videos on youtube still play fine, even in full screen. we expected a performance hit for mitigating the recent flaws. blender is much slower. i know blender is outside of qubes domain, but it shows the performance difference. On Tue, Feb 6, 2018 at 11:53 AM David Hobach wrote: > On 02/01/2018 03:44 AM, Andrew David Wong wrote: > > We're pleased to announce the fourth release candidate for Qubes 4.0! > > A big thanks for that! > > So far it seems more stable than the previous RCs and PVH doesn't only > provide the mentioned security gain, but also provides much better > performance over HVM on older machines. > > 4.0rc1 felt twice as slow as 3.2 and now rc4 feels like the same level > of speed as 3.2. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "qubes-users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/qubes-users/57reYSQsB00/unsubscribe. > To unsubscribe from this group and all its topics, 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/47ae1411-c153-7f19-bebf-bcda284ee628%40hackingthe.net > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CACr%3DtZcjH%2BKL0dkREW%2B6L-UYA2%3DAwf3fmipfD6z-zpH%2BcqK8Rg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Can't seem to build qubes 3.2
On Tuesday, February 6, 2018 at 5:15:34 PM UTC-5, Unman wrote: > On Tue, Feb 06, 2018 at 02:02:47PM -0800, Alchemist wrote: > > So I follow the build guide instructions, I have No_Sign=1, but for some > > reason the build script fails by telling me that the package is unsigned. > > > > Fedora 27 is my build system. > > > > Any ideas? > > > You'll really have to give us a clue - which package is unsigned? > You can turn on DEBUG and VERBOSE in builder.conf if you don't already > have them. > Then check the logs in build-logs and see exactly what is happening. Sorry about that, /qubes-builder/cache/fc23/base_rpms/acl-2.2.52-10.fc23.x86_64.rpm is not signed. Exiting! make[1]: *** [/home/liveuser/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86: /home/liveuser/qubes-builder/chroot-fc23/home/user/.prepared_base] Error 1 is the error I get, I turned on Debug and Verbose, but there's nothing in build-logs. -- 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/86b451a0-bd54-4f57-965b-f7d774a43468%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Can't seem to build qubes 3.2
So I follow the build guide instructions, I have No_Sign=1, but for some reason the build script fails by telling me that the package is unsigned. Fedora 27 is my build system. Any ideas? -- 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/ba1a090d-3b6e-47de-9e18-54df57a3cad6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [qubes-devel] Qubes OS 4.0-rc4 has been released!
On 02/01/2018 03:44 AM, Andrew David Wong wrote: We're pleased to announce the fourth release candidate for Qubes 4.0! A big thanks for that! So far it seems more stable than the previous RCs and PVH doesn't only provide the mentioned security gain, but also provides much better performance over HVM on older machines. 4.0rc1 felt twice as slow as 3.2 and now rc4 feels like the same level of speed as 3.2. -- 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/47ae1411-c153-7f19-bebf-bcda284ee628%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
[qubes-users] Re: Qubes 4.0 without IOMMU/VT-d/AMD-Vi or Interrupt Remapping
On Monday, February 5, 2018 at 10:34:34 AM UTC-5, Utility Panel wrote: > I installed Qubes 4.0-rc4 on a machine with hardware that cannot support the > following two features > > IOMMU/VT-d/AMD-Vi > Interrupt Remapping > > The installation went fine. I simply continued installing after the error > message appeared just after the installation ISO completed its hardware check. > > After installation, I was able to boot up to the desktop without any errors. > I didn't do much additional testing because I thought that there might be a > way to configure the BIOS on my machine to support the missing features; but > alas, there is no such way. > > Consequently, if I ever want to run 4.0, I am left with the following two > choices: > > A) Install 4.0 on this machine and live without the missing features. > B) Get a new computer that supports the missing features. > > I prefer option A. Can anyone tell me what I might expect without > IOMMU/VT-d/AMD-Vi and Interrupt Remapping? > > I've heard that PCI passthrough won't work, but I could live without it. > > What other problems might I encounter? Will 4.0 work without those features, > or must I get a new machine to run 4.0? Thank you for the confirmation, @awokd! Thanks also to @Brendan & @Taiidan for the laptop recommendations as well. I've known about the G505S for a while now, but the W520 is a new option for me to consider. Meanwhile, the machines I'm currently replacing are both server workstations with 96 gigs of EEC RAM. I'm looking to upgrade to something comparable, and I'm pretty certain at this point that I'll start building with either the KCMA-D8 or KGPE-D16. I've got one year after the release of 4.0 to make the transition, so I've got time to collect all the bits before 3.2 reaches end-of-life. It's just too bad that the Z800 turns out to have a manufacturing defect. I bought them last year because they meet the minimum requirements for Qubes 4.0; or, they would have if they hadn't been borked at the chip factory. -- 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/82e771f9-6801-466a-a5c2-cb5fd550f23f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] firefox addons in offline template VMs
Dear all, does anyone have a good solution for offline firefox addon installation & regular updates to template VMs? If so, I'd be delighted if you shared your idea or code. Otherwise I'd probably write a few lines to download the addons in a separate VM, pass it to the offline template via qvm-copy and update the respective firefox folders there. [1] [1] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Alternative_distribution_options/Sideloading_add-ons#Installation_using_the_standard_extension_folders KR David -- 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/89a2dd3f-7850-0aa3-e4df-f178ec4b81ef%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qubes-users] Fedora-minimal und Q. 4.0
Apologizes for being so unspecific, i actually meant missing both.T The command qvm-convert-pdf is not recognized. I found the pdf-converter on github, therefore, i will manually install it within the template. Another thing/bug i noticed actually right now: My sys-vpn (fedora-26-minimal) are missing the options "Copy/move to vm" and "open in Dispvm" in the GUI-context menu.However, the command qvm-copy-to-vm is recognized and working. Im unsure what is triggering this bug, since my usb-vm is also based on a fedora-26-minimal template but does have the gui-entrys/the qvm-copy function cheers On 02/06/18 02:21, Andrew David Wong wrote: > On 2018-02-05 08:47, Jo wrote: > > Cheers folks, > > > because of the switch to 4,0 im currently setting up a complete new > > system-structure, and therefore, i wanted to base all the sys-vms > > on fedora minimal templates. > > > However, im missing a few qubes-specific functions and couldnt > > find informations on what to install to get them. Ive installed > > all the necessary packages mentioned in the Documentation, but the > > "convert to trusted PDF/IMG function" is still missing. > > > Any hints which package i need to add? > > > When you say that it's "missing," does you mean that the CLI tool is > missing, or the option is missing from the GUI context menu, or both? > > In either case, this sounds like this might be an oversight. Tracking: > > https://github.com/QubesOS/qubes-issues/issues/3543 > > > -- 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/1ef6285d-42a9-4ec7-cf58-592f8aac0d0d%40seefelder-web.de. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes 4.0 - Inbound port forwarding
On Tue, February 6, 2018 11:35 am, 'awokd' via qubes-users wrote: > [Re-titling this sub-thread] > Anyone out there intimate with nft/iptables? My PR went through so the > document is up for grabs again if you want it! (Or please give suggestions > here and I can document it too.) For anyone coming across this without reading the entire thread- Alex grabbed it. Thank you, Alex! -- 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/4c3fa114b7bf17d5305398eda3956333.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Yubikey with smartcard and HOTP together
Hi, all: This is a different and a more nuanced problem than recently discussed, and I'm not sure if there's a solution, but I wanted to ask. :) Yubikey-4 can act in multiple capacities: - Smartcard - U2F device - HOTP HOTP functionality is really just a keyboard and registers with Linux as such (USB keyboard). With 3.2 I was attaching the USB controller directly to the VM where I was doing the work that required the smartcard/HOTP functionality and both worked just fine. With 4.0 I created a separate sys-usb VM and it seems I can use only one or the other, not both. When I plug in the yubikey, it registers correctly and I get a pop-up notification that it's available to be used. At that point, I am able to use HOTP-press without needing to attach the device to my work vm (because it's a "keyboard"). However, if I want to use the smartcard functionality, I have to assign the device to the work VM -- and gnupg interacts with it correctly. However, once I do that, I am no longer able to use HOTP -- pressing the button does nothing. Any ideas if this is fixable at all, or is it the downside of the way USB devices are assigned with usb-proxy? Best, -- Konstantin Ryabitsev Director, IT Infrastructure Security The Linux Foundation -- 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/0f889341-850c-23ba-8286-4b091bd2529b%40linuxfoundation.org. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
[qubes-users] template debian-9 no network (Q4r4) ?
you probably ticked update over Tor option when installing. templates do not connect to network directly, they use an updates proxy. I' not sure it can be changed in GUI, but you can find the appropriate rpc policy in /etc/qubes-rpc alternatively you can temporarily set template vm's network provider, but that is considered less secure. -- 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/d3845366-0dc3-4751-a377-83e1e97f4a80%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Trouble with enabling networking between two Vms
On Tuesday, 6 February 2018 21:21:31 UTC+8, dba...@gmail.com wrote: > Le jeudi 10 novembre 2016 18:09:30 UTC+1, Max a écrit : > > On Thursday, 10 November 2016 07:34:06 UTC+8, Drew White wrote: > > > On Thursday, 10 November 2016 04:36:18 UTC+11, Max wrote: > > > > Brief update on this. After attempting to use the Qubes Network Server > > > > from Manuel Amador (Rudd-O) to solve this issue with no luck I have > > > > gone back to looking at solving this by adjusting the iptables rules. > > > > > > > > I ran through the steps listed here again: > > > > https://www.qubes-os.org/doc/qubes-firewall/#enabling-networking-between-two-vms > > > > but instead of trying to ping my Debian 8 VM (10.137.2.18) from the > > > > Windows VM (10.137.2.19), I did this from a new Fedora VM (10.137.2.16) > > > > to test the results. > > > > > > > > I simply did the following: > > > > > > > > Firewall > > > > sudo iptables -I FORWARD 2 -s 10.137.2.16 -d 10.137.2.18 -j ACCEPT > > > > > > > > work-apps > > > > iptables -I INPUT -s 10.137.2.16 -j ACCEPT > > > > > > > > This enabled me to ping from Fedora to the Debian VM. No additional > > > > rules were required such as adding ports or adding an ACCEPT FORWARD > > > > rule in the Debian VM with the destination and source reversed. > > > > > > > > Given the ease of achieving this, it seems that the issue here stopping > > > > me pinging my Debian VM from Windows is specific to Windows being an > > > > HVM. Pinging from an HVM to a PVM does not seem to work but PVM to PVM > > > > networking does. Please note that the HVM can ping the firewall and > > > > vice versa. > > > > > > > > Does anyone have any suggestions given this information? > > > > > > > > Many thanks. > > > > > > As I have said in other places, including his qubes network server post, > > > I too use IPTables, because it's much simpler and cleaner. > > > > > > I have a dedicated ProxyVM that is my inter-vm network. > > > > > > > > > These are the 2 rules... > > > $intervm_internalnet = '10.137.2.0';// this can be generated from the > > > ifconfig if required. But conditions apply for success. > > > > > >iptables -I FORWARD 1 -i vif+ -o vif+ -s $intervm_internalnet/24 -d > > > $intervm_internalnet/24 -m state --state NEW -p tcp -m tcp -j ACCEPT > > >iptables -I FORWARD 1 -i vif+ -o vif+ -s $intervm_internalnet/24 -d > > > $intervm_internalnet/24 -p udp -m udp -j ACCEPT > > > > > > > > > > > > This has worked for me always. Never missed a beat. And it allows for > > > inter-vm comms, as well as it communicating to the outside world. > > > > Thanks Drew, unfortunately I tried this at the beginning (my step 3). It > > didn't work for me. > > > > Have you tried pinging from a Windows HVM to another Debian or Fedora AppVM? > > Hello Max, > > I am a newbie on Qubes, and i've the same issue on 3.2 version. > Did you finally succeeded in having interconnect between two HVM ? > Thanks for your feedback. > > Regards > > Mc Hi Mc, I was able to connect between Linux AppVMs only, not HVMs. To solve my particular issue, I went with syncthing to transfer a text file between VMs which was very straightforward as the Windows and Linux clients are very easy to install. Thanks -- 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/6d822ee3-0d14-49c9-a2f2-b2bdea20653f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Trouble with enabling networking between two Vms
On Tuesday, 6 February 2018 22:49:31 UTC+8, Alex Dubois wrote: > On Sunday, 23 October 2016 10:11:48 UTC+1, Max wrote: > > Hi, > > > > I am a new user of Qubes OS so apologies in advance if the question here > > has been answered already in a separate topic (there are similar issues) > > and I haven’t discovered this or it is not one suited to this mailing list. > > I am running Qubes 3.2 and attempting to ping from one VM to another VM, > > specifically from a Standalone Windows 7 VM to a Qubes VM based on the > > Debian 8 template. > > > > All my VM’s were initially connected in the default manner i.e. to a > > sys-firewall and through to the sys-net VM, both of which are Fedora 23. > > There are no firewall rules on these VMs restricting which IP addresses can > > be accessed. > > > > Current status: > > - I am able to ping from my Windows 7 VM (10.137.2.19) to the Firewall VM > > (10.137.1.8) using the IP address visible in the VM Manager > > > > - I am unable to ping the Debian 8 VM (10.137.2.18) from my Windows VM. > > > > Steps taken: > > 1) I followed the instructions here > > (https://www.qubes-os.org/doc/qubes-firewall/#enabling-networking-between-two-vms) > > and in the firewall VM’s terminal enter the following iptables rule... > > > > sudo iptables -I FORWARD 2 -s -d > of Debian 8 VM> -j ACCEPT > > > > … In VM B’s terminal (Debian 8) I entered the following iptables rule... > > > > sudo iptables -I INPUT -s -j ACCEPT > > > > ...but from here when using the ping function to my Debian 8 VM in the cmd > > prompt in Windows, all packets were lost. > > > > 2) As this was not successful I attempted to see if I could connect to VMs > > from an external machine and followed the instructions here > > https://www.qubes-os.org/doc/qubes-firewall/#port-forwarding-to-a-vm-from-the-outside-world. > > > > The Eth0 IP address (192.168.1.6) appeared to be what I should expose the > > service to. > > > > I put the below rule in the sys-net VM’s Terminal... > > > > iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 192.168.x.x -j > > DNAT --to-destination 10.137.1.x > > > > ...and this rule into the sys-firewall VM’s Terminal > > > > iptables -I FORWARD 2 -i eth0 -d 10.137.1.x -p tcp --dport 443 -m conntrack > > --ctstate NEW -j ACCEPT > > > > But using ping or Telnet resulted in lost packets and failed to increase > > the counters when using the iptables -t nat -L -v -n command in the > > sys-firewall VM's terminal. > > > > 3) With this not being successful either I attempted to add a “sys-proxy” > > VM as described here > > https://groups.google.com/forum/#!searchin/qubes-users/intervm%7Csort:relevance/qubes-users/lA2SgPcV9fU/U969uapYAAAJ > > and entered the following in the new sys-proxy VM's terminal: > > > > iptables -I FORWARD 1 -i vif+ -o vif+ -s $intervm_internalnet/24 -d > > $intervm_internalnet/24 -m state --state NEW -p tcp -m tcp -j ACCEPT > > > > iptables -I FORWARD 1 -i vif+ -o vif+ -s $intervm_internalnet/24 -d > > $intervm_internalnet/24 -p udp -m udp -j ACCEPT > > > > After this, I was still unable to ping the Debian 8 VM from my Windows VM. > > > > Questions: > > > > 1) Are there any obvious errors in the steps I took and does anyone have > > any suggestions how I can resolve this issue? > > > > 2) There are a number of other incidences of what seemed to be a similar > > issue here: > > https://groups.google.com/forum/?nomobile=true#!msg/qubes-users/59kOjfQFBI4/bjS47-jJJgAJ, > > > > https://groups.google.com/forum/#!msg/qubes-users/vSyUaOSloYU/ONZNJlhrBAAJ. > > Are the enabling networking between VMs steps described here still correct > > and applicable for Qubes 3.2? > > > > 3) The IP address assignment suggests that the VMs are on the same network > > – the Subnet Mask is 255.255.255.0 so surely any devices with an IP address > > of 10.137.2.x would be able to communicate with each other? What is unique > > in Xen / Qubes that stops this? > > > > 4) Is there a way in which the current routing rules can be displayed and > > reset back to the default if required? > > Hi Max, > > The documentation on how to open networking between 2 qubes is misleading as > it probably open much more than required and incomplete. > Could you please specify what you want to do between these 2 VM (which port > you want to open)? as I suppose you want more than pinging... Hi Alex Yes, I wanted to do a little more than pinging. For this particular issue, I wanted to be able to query a database connection between the two VMs. -- 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/033bc9ed-e0ad-45a3-9532-88cae4a0187
Re: [qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?
On Tuesday, 6 February 2018 10:32:16 UTC, awokd wrote: > On Mon, February 5, 2018 6:18 pm, 'awokd' via qubes-users wrote: > > On Mon, February 5, 2018 6:01 pm, 'Tom Zander' via qubes-users wrote: > > >> If someone can figure out how to port-forward in 4.0, please do update > >> the docs. I never managed to get that working. > > I see what you mean. If I follow > https://www.qubes-os.org/doc/firewall/#port-forwarding-to-a-qube-from-the-outside-world > on R4.0, I'm not getting past the first step of: > > Verify you are cutting through the sys-net VM firewall by looking at its > counters (column 2) > > iptables -t nat -L -v -n [counters increasing] > > iptables -L -v -n [not] > > I wonder if it's an nft vs. iptables thing? Interestingly, this procedure > works fine: > https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes > . I did this doc long long ago. 4.0 has a new networking model. I've just upodated to v4, I'll review it... sorry... -- 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/83343bc4-e65f-42e8-be2b-426bd8f54ace%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Problem with Qubes4 rc4 -- "GLX is not supported."
I've installed Qubes 4 rc4 on an external hard drive. It works pretty well. However, I tried to run a game "FreeOrion" and received the following error using the "personal" vm: Unable to create window. SDL reported: GLX is not supported ** I took a look at what drivers were loaded, and at least at the level of lsmod in dom0. The difference between Qubes and my "regular" linux distribution (KDE neon) was that under qubes, the module amdgpu was not loaded. %lsmod | grep radeon radeon1658880 1 ttm114688 1 radeon i2c_algo_bit16384 2 radeon, i915 drm_kms_helper 192512 2 radeon, i915 drm438272 8 radeon, i915, ttm, drm_kms_helper %lsmod | grep amd amdkfd147456 1 amd_iommu_v2 20480 1 amdkfd After running "modprobe amdgpu" in dome0: %lsmod | grep amd amdgpu 2072567 0 amdkfd 147456 1 amd_iommu_v2 20480 1 amdkfd ttm 114688 1 amdgpu, radeon i2c_algo_bit 16384 2 amdgpu, radeon, i915 drm_kms_helper 192512 2 amdgpu, radeon, i915 drm 438272 8 amdgpu, radeon, i915, ttm, drm_kms_helper I'm still not clear on how video works, since none of these show up when I run lsmod in the personal vm or the fedora 26 template. But in any case, nothing changed when I then tried to run the game. I closed the personal vm and restarted it, but nothing changed. lspci in dom0 reveals Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Sun XT [Radeon HD 8670A/8670M/8690M / R5 M330 ?M430 /R7 M520] (rev 81) (please excuse any typos, I'm having a little trouble copying and pasting text from dom0, so I typed the above in by hand). What should I try next? Thanks, billo -- 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/bda45025-c36f-40bf-9bc5-3aa48dd31c1a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?
On Monday, 5 February 2018 00:26:36 UTC, Tom Zander wrote: > On Monday, 5 February 2018 00:55:34 CET Unman wrote: > > On Sun, Feb 04, 2018 at 08:14:57PM +0100, 'Tom Zander' via qubes-users > wrote: > > > * Having nothing but python APIs for your operating system is something > > > that makes no sense. Python was never meant for servers, or even big > > > applications. Finding a full-stack python developer is more rare than > > > finding a Bitcoin C++ developer. > > > > I'm not sure how much of this is just trolling. > > It is not trolling. > > > You obviously dont mean uses like Google, DropBox, YouTube, Reddit etc. > > Perhaps you dont know about Eve Online? Mercurial? Blender? > > Absolutely none of these use python for anywhere near the same percentage of > components as Qubes does. Having developed a Yubikey component for Qubes, I prefer to use Python when possible for transparency. The C bit I've done are opaque to the user (unless he compiled his install of Qubes, and reviewed the code). Not saying it is the default choice but pointing that Python has this benefit. > Google is a good example, for instance they shipped proto-buffers. Which > have bindings in a long list of languages (20 or so). True that API use should be easy at least with Python and C. But C should only be used for core protocols. > > Check wikipedia for those examples, reality is much more sobering that you > think. > > > There are exceptional developers working in many companies -Google, > > NASA, Astra Zeneca, to name a few, all using python. The fact that > > you arent comfortable with it is fine, but not a reason to reject it. > > Thats moving the goalpost. Naturally there are many experienced python > developers. > > Let me re-state the point for your benefit; > > Having nothing but python bindings and having practically all your > components written in python is without a doubt very realistically limiting > the amount of people you can get hacking on Qubes. Add on top of that the > content matter, which is highly complex and in many cases includes > networking or cross-VM communication or hard-core linux components and you > limit the amount of people even more, to the extend I mentioned above. > > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel -- 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/8ae3abf0-1e0a-42ac-9891-babd9d3042b3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Trouble with enabling networking between two Vms
On Sunday, 23 October 2016 10:11:48 UTC+1, Max wrote: > Hi, > > I am a new user of Qubes OS so apologies in advance if the question here has > been answered already in a separate topic (there are similar issues) and I > haven’t discovered this or it is not one suited to this mailing list. I am > running Qubes 3.2 and attempting to ping from one VM to another VM, > specifically from a Standalone Windows 7 VM to a Qubes VM based on the Debian > 8 template. > > All my VM’s were initially connected in the default manner i.e. to a > sys-firewall and through to the sys-net VM, both of which are Fedora 23. > There are no firewall rules on these VMs restricting which IP addresses can > be accessed. > > Current status: > - I am able to ping from my Windows 7 VM (10.137.2.19) to the Firewall VM > (10.137.1.8) using the IP address visible in the VM Manager > > - I am unable to ping the Debian 8 VM (10.137.2.18) from my Windows VM. > > Steps taken: > 1) I followed the instructions here > (https://www.qubes-os.org/doc/qubes-firewall/#enabling-networking-between-two-vms) > and in the firewall VM’s terminal enter the following iptables rule... > > sudo iptables -I FORWARD 2 -s -d Debian 8 VM> -j ACCEPT > > … In VM B’s terminal (Debian 8) I entered the following iptables rule... > > sudo iptables -I INPUT -s -j ACCEPT > > ...but from here when using the ping function to my Debian 8 VM in the cmd > prompt in Windows, all packets were lost. > > 2) As this was not successful I attempted to see if I could connect to VMs > from an external machine and followed the instructions here > https://www.qubes-os.org/doc/qubes-firewall/#port-forwarding-to-a-vm-from-the-outside-world. > > The Eth0 IP address (192.168.1.6) appeared to be what I should expose the > service to. > > I put the below rule in the sys-net VM’s Terminal... > > iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 192.168.x.x -j > DNAT --to-destination 10.137.1.x > > ...and this rule into the sys-firewall VM’s Terminal > > iptables -I FORWARD 2 -i eth0 -d 10.137.1.x -p tcp --dport 443 -m conntrack > --ctstate NEW -j ACCEPT > > But using ping or Telnet resulted in lost packets and failed to increase the > counters when using the iptables -t nat -L -v -n command in the sys-firewall > VM's terminal. > > 3) With this not being successful either I attempted to add a “sys-proxy” VM > as described here > https://groups.google.com/forum/#!searchin/qubes-users/intervm%7Csort:relevance/qubes-users/lA2SgPcV9fU/U969uapYAAAJ > and entered the following in the new sys-proxy VM's terminal: > > iptables -I FORWARD 1 -i vif+ -o vif+ -s $intervm_internalnet/24 -d > $intervm_internalnet/24 -m state --state NEW -p tcp -m tcp -j ACCEPT > > iptables -I FORWARD 1 -i vif+ -o vif+ -s $intervm_internalnet/24 -d > $intervm_internalnet/24 -p udp -m udp -j ACCEPT > > After this, I was still unable to ping the Debian 8 VM from my Windows VM. > > Questions: > > 1) Are there any obvious errors in the steps I took and does anyone have any > suggestions how I can resolve this issue? > > 2) There are a number of other incidences of what seemed to be a similar > issue here: > https://groups.google.com/forum/?nomobile=true#!msg/qubes-users/59kOjfQFBI4/bjS47-jJJgAJ, > https://groups.google.com/forum/#!msg/qubes-users/vSyUaOSloYU/ONZNJlhrBAAJ. > Are the enabling networking between VMs steps described here still correct > and applicable for Qubes 3.2? > > 3) The IP address assignment suggests that the VMs are on the same network – > the Subnet Mask is 255.255.255.0 so surely any devices with an IP address of > 10.137.2.x would be able to communicate with each other? What is unique in > Xen / Qubes that stops this? > > 4) Is there a way in which the current routing rules can be displayed and > reset back to the default if required? Hi Max, The documentation on how to open networking between 2 qubes is misleading as it probably open much more than required and incomplete. Could you please specify what you want to do between these 2 VM (which port you want to open)? as I suppose you want more than pinging... -- 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/085ef9b6-1377-4ef2-8212-5798a62b8866%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] template debian-9 no network (Q4r4) ?
Hi, qvm- I have installed the debian-9 template on dom0 using: sudo qubes-dom0-update qubes-template-debian-9. When running this template to make it up to date, the network is not working. Even if using the same proxyVM and netVM than the other VMs, it still start sys-whonix ... Any idea ? -- 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/277d0104-7378-43ea-bc50-9b5eb401037b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] 4.0-rc4 Install Help
On Sat, 3 Feb 2018 09:22:08 -0800 (PST) Shashank wrote: > I guess I’ll not jump into booting into legacy mode and having to > mess up all the boot options again. If you do find a way to install > it in uefi mode like 3.2 please do post the solution. > HI again. Well I have managed to get rc4 installed in UEFI mode, but it's not a nice process :) The Qubes iso seems to contain two menus for EFI booting, but the Dell XPS15 won't display them at all, hence there is no possibility to edit the boot line and add the modprobe.blacklist option at bootup. There are two ways I've found to overcome this - in one, I edited the Qubes iso file before writing it to a usb stick, and the other was by following the Lenovo troubleshooting link, https://www.qubes-os.org/doc/thinkpad-troubleshooting/ 1. Binary edit the Qubes iso (I used gvim as plain vim could not handle the temp file!?!). Search for "i915.preliminary_hw_support=1" and REPLACE it with the string "modprobe.blacklist=nouveau ". This MUST be exactly the same length as the i915 string, so it add three spaces at its end. ANY change in the length of the text line will damage the iso and it definitely won't work. This probably only needs to be done for the "qubes-verbose" menu options, but I didn't check this, I just replaced all the repeats of the string in the two menus. There is a third menu for GRUB legacy, but I did not bother replacing them there. Then write out the iso to usb, and reboot. Interrupt the Dell boot screen with F2 and select the UEFI usb boot option. All should work OK. (Qubes-check will fail because the iso has been edited, but the check option only appears when legacy booting.) 2. Or, follow the Lenovo troubleshooting guide at the link above, and create the usb and change the Label to BOOT and mount it. I could not find the xen.cfg file, but there was a ".cfg" (can't remember the name) that contained the bootup command lines. I replaced the option "quiet" with the modprobe.blacklist=nouveau string. Length of the string does not matter in this case. Save the file, unmount the usb and try to boot from the it. It didn't provide an UEFI boot option on my DELL, but I was able to boot the "fallback boot on Anaconda" from my boot manager "refind". You may not want to go to the trouble of installing that if you are not multi-booting your laptop. In which case, you only have option 1. Some of the problems with the Dell (apart from the nVidia device), are that it seems to require that any EFI partition must have both the correct partition type (EFI) and the specific EFI disk identifier, otherwise its bios does not recognise an EFI boot partition. Mike. -- 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/20180206134312.4462d32d.mike%40keehan.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Trouble with enabling networking between two Vms
Le jeudi 10 novembre 2016 18:09:30 UTC+1, Max a écrit : > On Thursday, 10 November 2016 07:34:06 UTC+8, Drew White wrote: > > On Thursday, 10 November 2016 04:36:18 UTC+11, Max wrote: > > > Brief update on this. After attempting to use the Qubes Network Server > > > from Manuel Amador (Rudd-O) to solve this issue with no luck I have gone > > > back to looking at solving this by adjusting the iptables rules. > > > > > > I ran through the steps listed here again: > > > https://www.qubes-os.org/doc/qubes-firewall/#enabling-networking-between-two-vms > > > but instead of trying to ping my Debian 8 VM (10.137.2.18) from the > > > Windows VM (10.137.2.19), I did this from a new Fedora VM (10.137.2.16) > > > to test the results. > > > > > > I simply did the following: > > > > > > Firewall > > > sudo iptables -I FORWARD 2 -s 10.137.2.16 -d 10.137.2.18 -j ACCEPT > > > > > > work-apps > > > iptables -I INPUT -s 10.137.2.16 -j ACCEPT > > > > > > This enabled me to ping from Fedora to the Debian VM. No additional rules > > > were required such as adding ports or adding an ACCEPT FORWARD rule in > > > the Debian VM with the destination and source reversed. > > > > > > Given the ease of achieving this, it seems that the issue here stopping > > > me pinging my Debian VM from Windows is specific to Windows being an HVM. > > > Pinging from an HVM to a PVM does not seem to work but PVM to PVM > > > networking does. Please note that the HVM can ping the firewall and vice > > > versa. > > > > > > Does anyone have any suggestions given this information? > > > > > > Many thanks. > > > > As I have said in other places, including his qubes network server post, I > > too use IPTables, because it's much simpler and cleaner. > > > > I have a dedicated ProxyVM that is my inter-vm network. > > > > > > These are the 2 rules... > > $intervm_internalnet = '10.137.2.0';// this can be generated from the > > ifconfig if required. But conditions apply for success. > > > >iptables -I FORWARD 1 -i vif+ -o vif+ -s $intervm_internalnet/24 -d > > $intervm_internalnet/24 -m state --state NEW -p tcp -m tcp -j ACCEPT > >iptables -I FORWARD 1 -i vif+ -o vif+ -s $intervm_internalnet/24 -d > > $intervm_internalnet/24 -p udp -m udp -j ACCEPT > > > > > > > > This has worked for me always. Never missed a beat. And it allows for > > inter-vm comms, as well as it communicating to the outside world. > > Thanks Drew, unfortunately I tried this at the beginning (my step 3). It > didn't work for me. > > Have you tried pinging from a Windows HVM to another Debian or Fedora AppVM? Hello Max, I am a newbie on Qubes, and i've the same issue on 3.2 version. Did you finally succeeded in having interconnect between two HVM ? Thanks for your feedback. Regards Mc -- 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/317d2d23-cfe3-4326-b5b7-371875bbf9ae%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes 4.0 - Inbound port forwarding
[Re-titling this sub-thread] On Tue, February 6, 2018 11:12 am, 'Tom Zander' via qubes-users wrote: > On Tuesday, 6 February 2018 11:32:07 CET 'awokd' via qubes-users wrote: > >> I'm not getting past the first step of: >> >> >> Verify you are cutting through the sys-net VM firewall by looking at >> its counters (column 2) > > Yes, that sounds familiar. > > > The problem isn't limited to sys-net either, using netcat to listen on > any port on any (fedora based) appvm I could not get anything to connect > to those ports. So, for instance, starting netcat on sys-firewall I could > not connect to it from sys-net. Similarly, listening on a random VM and > connecting to it from sys-firewall failed too. And I tried a lot of ways to > convince the iptables to accept it... > > I mostly used archlinux templates for appvms, which do not have the qubes > networking packages and thus the iptables list is empty. [1] Listening > there and connecting from it worked fine. > > Hope that helps. I'm using the Debian-9 template, maybe that's why I was able to get https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes working first try. Doesn't explain sys-net though which is using it too. Anyone out there intimate with nft/iptables? My PR went through so the document is up for grabs again if you want it! (Or please give suggestions here and I can document it too.) -- 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/f876b8dbafa5d60e8ac109f2b1225fa5.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] noscript xss warning on qubes os site
Original Message On February 5, 2018 12:34 AM, Andrew David Wong wrote: > On 2018-02-04 09:02, 'Vincent Adultman' via qubes-users wrote: >>Confirm I get this too with noscript in firefox. Will try and get >> some details together if I can and file an issue... >> > Thank you! That would be very helpful! > > We've been investigating this problem for a while, but we haven't been > able to determine the cause. Looks like it may well be not our problem. With the below test version installed from https://noscript.net/getit#devel I no longer have the issue. Perhaps someone else could also give this version a go to confirm. v 10.1.6.5rc2 = x [XSS] More specific and unobtrusive handling of window.name sanitization -- 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/t_4M1Wx07fQbxh_SgcfAwBqdUuG9DW9m3nJf-oX9HI67xX4nSvnTOLA19U9FfMOYV1dPaJbz39151nyS1KgOD5_yFJVVwysnuZVdyiszP08%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Please help with Qubes 4.0 rc4 on 8th Generation Intel
On Mon, February 5, 2018 2:13 pm, Krišjānis Gross wrote: > Hi, > > > I have recently installed Qubes 4.0 rc4 on a new 8th generation Intel > hardware and have an issue that I would like to get help with. > > The issue is that graphics appear to be very very slow. Each time there > is some visual activity on the screen it is vary 'laggy'. I noticed that > whenever there is a GUI action, the process called Xorg is using 100% of > one of the processor cores. Haha I can definitely see it's using software rendering on that video. The Xorg.0.log file confirms it with "[ 131.769] (EE) AIGLX: reverting to software rendering" Looks like the kernel option got renamed. In your kernel command line, can you try replacing "i915.preliminary_hw_support=1" with "i915.alpha_support=1"? -- 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/417e96ea8a25bea123dcba85043116ce.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?
On Tuesday, 6 February 2018 11:32:07 CET 'awokd' via qubes-users wrote: > I'm not getting past the first step of: > > Verify you are cutting through the sys-net VM firewall by looking at its > counters (column 2) Yes, that sounds familiar. The problem isn't limited to sys-net either, using netcat to listen on any port on any (fedora based) appvm I could not get anything to connect to those ports. So, for instance, starting netcat on sys-firewall I could not connect to it from sys-net. Similarly, listening on a random VM and connecting to it from sys-firewall failed too. And I tried a lot of ways to convince the iptables to accept it... I mostly used archlinux templates for appvms, which do not have the qubes networking packages and thus the iptables list is empty. [1] Listening there and connecting from it worked fine. Hope that helps. 1) Personally I would say that simpler is better, or least surprises is better. The current design where any appvm gets those complex firewall rules is a bug. Only VMs that expose their network (providing) should run it. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- 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/2307203.OnATnpnmTp%40strawberry. For more options, visit https://groups.google.com/d/optout.
[qubes-users] size difference between 4.9 and 4.14 kernels
hi, on 3.2 I ran "sudo qubes-dom0-update" this morning, followed by "sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing --action=upgrade kernel-qubes-vm" which then prompted me with this: Installing: kernel x86_64 1000:4.14.13-3.pvops.qubes qubes-dom0-cached46 M kernel-qubes-vm x86_64 1000:4.14.13-3.pvops.qubes qubes-dom0-cached62 M Removing: kernel x86_64 1000:4.9.35-20.pvops.qubes @qubes-dom0-cached 179 M kernel-qubes-vm x86_64 1000:4.9.35-20.pvops.qubes @qubes-dom0-cached 206 M Is that really expected and correct that the new kernels are that much smaller? -- cheers, Holger -- 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/20180206110441.u47kzgpfwfzibgki%40layer-acht.org. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
[qubes-users] Re: GPU Passthrough Status - (Purely a meta-discussion, no specifics)
On Saturday, December 16, 2017 at 3:25:46 AM UTC+1, Yuraeitha wrote: > Aight, so the idea of this thread, is to get an overview of where we stand, > that is, how far are we away from archiving GPU Passthrough on Qubes. > > The underlying reason it's currently not working, appears to be because of > its current state a virtual GPU for a specific VM, would require direct > access to dom0. This is deemed a serious security threat breaking a central > pillar of what Qubes is all about, attempting to isolate dom0 as far as > possibly possible. Therefore, from what I can gather, what we need is virtual > GPU operating from an underlying DomU stub-domain, preferably, one separated > from another DomU stub-domain, which holds the important and critical VM data > and user operations. Thereby it's not only about single virtualization > anymore, but also about group segmenting and isolating entire virtual > stub-domains. That means, one group of VM's is isolated from another group of > VM's. Please correct me if I'm wrong here, it's great for the discussion to > have the most accurate information. > > Here is a scenario that stresses the above, > https://groups.google.com/forum/#!topic/qubes-users/cmPRMOkxkdA > Managing to make GPU passthrough work, but only by passing it directly to > Xen, instead of Libvirt, which in turn, exposes dom0. > > Initially, this is all the reasons I can think of for wanting V-GPU. > - Heavy graphic designer job or hobby (movies, animations, etc.). > - Running Qubes on many screens at desk. > - Extending a single Qubes machine around the house or company, using > multiple of screens, keyboards/mouses or other thinkable means. > - Gamers who take security and privacy seriously (there is surprisingly many > of them out there). > - Cryptocoin miners who wish to utilize a single machine for all round > purposes. > - Using a qube as a streaming TV, and want good graphics for the specific > TV-VM. For example 4k or even 8k+ or more on multiple tied screens. > > Some of these are exotic and probably not many around use them, however, > others are quite common. Whichever the case, it's all scenarios with a common > problem. The point here, is to underpin the possible use-cases. > > > > I must be tired, I initially wrote 'qubestions' instead of 'questions' > here... > aight, so possible questions for the discussion. > > - What would it take for Qubes to obtain stubdomains in a feasible means to > allow safe GPU Passthrough? > - Are there other problems that needs solving too? If so, which ones? > - What is the grand big picture status between the above two questions? > - Are there currently any plans for any of these required implementations? > For example Qubes stub-domains in Qubes 4.1? Qubes 5? or are they still > unplanned? If planned, or in part planned, like only halfway there, then, > what are these plans? Please elaborate. > - Other possible questions you can think of. > > > I'm sure there are aspects I did not think of, but that's fine, after all, > this is a discussion. This initial post is just to kick it off. The purpose > is to combine information that a few selected individuals might be sitting > on, with the many users who do not know about the current state. Thereby, > building community awareness of the current situation. Whatever you got to > say, or ask, about GPU Passthrough, this thread can be used for that! The > only limitation, is that it is a discussion, and not a place to ask how to > get your own specific case of GPU Passthrough to work. It's a general, meta > discussion. > > What is your thoughts on the matter? Just to add a use case is all developers doing something including the gpu. I found Qubes OS the other day and installed it on a secondary pc. It seems great, and besides the security concerns it also gives a great way to organize the computer. To keep work, private and open source projects separated. I work on TilelessMap, an open source project to keep huge amounts of map data locally (linux, windows or android). Can be view as a privacy project since it makes you independent of connection which reveals what maps you are interested in (where you are in other words). https://github.com/TilelessMap It renders the map in openGL som I have a problem adopting Qubes OS on my primary laptop. But I would really love to do it. write this just to point out that it isn't just gaming that is the use case. Anyway, Qubes OS looks fantastic, for more or less anything else. Thanks ! -- 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/6508adf7-c40f-4909-89ea-de3a13b903b2%40googlegroups
Re: [qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?
On Mon, February 5, 2018 6:18 pm, 'awokd' via qubes-users wrote: > On Mon, February 5, 2018 6:01 pm, 'Tom Zander' via qubes-users wrote: >> If someone can figure out how to port-forward in 4.0, please do update >> the docs. I never managed to get that working. I see what you mean. If I follow https://www.qubes-os.org/doc/firewall/#port-forwarding-to-a-qube-from-the-outside-world on R4.0, I'm not getting past the first step of: Verify you are cutting through the sys-net VM firewall by looking at its counters (column 2) iptables -t nat -L -v -n [counters increasing] iptables -L -v -n [not] I wonder if it's an nft vs. iptables thing? Interestingly, this procedure works fine: https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes . -- 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/4532ba5292b7dff28452fe49ae0d30ad.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: qvm-usb is broken in Qubes 4.0 rc4
I am not the OP but I have the same issue with webcam and storage device is not passing trough either. The only thing that seems to pass trough fine is the microphone On 02/05/2018 03:57 AM, Tim W wrote: > On Sunday, February 4, 2018 at 8:50:12 PM UTC-5, Fabrizio Romano Genovese > wrote: >> Hello all, >> >> When I try to attach my webcam to any appvm, I get the following message: >> >> Device attach failed: /usr/lib/qubes/usb-import: line 32: >> /sys/devices/platform/vhci_hcd/status: No such file or directoryNo unused >> port found!/usr/lib/qubes/usb-import: line 51: >> /sys/devices/platform/vhci_hcd/attach: No such file or directory >> >> In the meantime, the devices widget thinks that everything is ok. >> I was able to reproduce this error on two different machines, one upgraded >> from Qubes 4.0 rc3 and another coming from a fresh install. What should I do? >> >> Cheers, >> Fab > Does it work with a flash drive as storage device? > -- Best regards, Nuno Branco -- 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/19c85c52-94e0-8337-aae2-21a6c6d92dc5%40mulligans.pw. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 3.2 after patching
On Tue, January 30, 2018 4:54 pm, rob_66 wrote: > Hello. > > > So, I received Xen packages, version 4.6.6-36, via dom0 > --enablerepo=qubes-dom0-security-testing. > > > I changed 1) the (xscreensaver) password and 2) LUKS passphrase. > > > Now the questions: > > > Can I start with 3) disk reencrypting (reinstalling Qubes 3.2., restoring > from backup) and 4) generating new secrets (PGP, passwords …) now – or do > I have to wait until Xen > 4.6.6-36 has landed in the stable repository? I think you could start this now. > Or do I start 1)–4) of Qubes' »Suggested actions after patching« anew > after Xen 4.6.6-36 has landed in stable repository? > > > And how do I know when 4.6.6-36 has landed there? (I'm always updating > Qubes via dom0 with > --enablerepo=qubes-dom0-security-testing enabled and never faced problems > with that.) To the best of my knowledge, if you've already installed a package from the testing repository, it won't get re-installed again once it moves to stable. -- 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/04ea59e8d478d141e4e6d27ec72f576a.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.