[qubes-users] Re: Troubleshooting IOMMU compatibility
On Tuesday, January 16, 2018 at 8:52:15 AM UTC+1, jspieg...@airmail.cc wrote: > I cannot get HVMs with attached PCI devices to boot in Qubes 4.0-rc3. My > processor (AMD Phenom II X3 B75) does have IOMMU support as far as I can > tell from the sources I've found online, but I can't find much info > about whether my motherboard (HP 3047h) supports it. There is only one > generic "virtualization" option in the BIOS. I found a lot of statements > like this online about IOMMU: > > > Please note that just because a motherboard uses a chipset that > > supports IOMMU does not mean it is able to and the bios must have an > > ACPI IVRS table to enable the use of it. At least one Asus board is > > known to have faulty BIOSes with corrupt ACPI IVRS tables; for such > > cases, under Linux, it is possible to specify custom mappings to > > override the faulty and/or missing BIOS-provided ones through the use > > of the ivrs_ioapic and ivrs_hpet kernel parameters. > > What all specific things would I check to see if actions like above > would be advisable or if I could possibly get IOMMU working? How can I > probe my motherboard's support for it directly? And what kernel options > other than the above would be advisable to try for testing purposes? > (I'm not really sure how I'd set those kernel options either.) run qubes-hcl-report , see what it tells you. Bios should ideally have IOMMU and SVM settings, SR-IOV optional (and irrelevant for this purpose). Which PCI devices refuse to boot? -- 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/06dc6176-03e2-45b3-9316-d085fa78a693%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Troubleshooting IOMMU compatibility
I cannot get HVMs with attached PCI devices to boot in Qubes 4.0-rc3. My processor (AMD Phenom II X3 B75) does have IOMMU support as far as I can tell from the sources I've found online, but I can't find much info about whether my motherboard (HP 3047h) supports it. There is only one generic "virtualization" option in the BIOS. I found a lot of statements like this online about IOMMU: Please note that just because a motherboard uses a chipset that supports IOMMU does not mean it is able to and the bios must have an ACPI IVRS table to enable the use of it. At least one Asus board is known to have faulty BIOSes with corrupt ACPI IVRS tables; for such cases, under Linux, it is possible to specify custom mappings to override the faulty and/or missing BIOS-provided ones through the use of the ivrs_ioapic and ivrs_hpet kernel parameters. What all specific things would I check to see if actions like above would be advisable or if I could possibly get IOMMU working? How can I probe my motherboard's support for it directly? And what kernel options other than the above would be advisable to try for testing purposes? (I'm not really sure how I'd set those kernel options either.) -- 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/efcfd39420a49aadfa8431de8242cd3f%40airmail.cc. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: off topic - invite codes to 'riseup'
hi! is there anyone who can send me an invation code for riseup? i cant pay/donate you now but if soeone can help me i am willing to send him bzc hor sbout 5 euro if thats ok?! i need the invite codes fast too thanks in advance greets -- 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/56a314b2-14ff-4eec-950e-36541c590d85%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Lenovo ThinkPad, won't boot
On Monday, January 15, 2018 at 3:23:55 PM UTC-8, demio...@gmail.com wrote: > My Lenovo ThinkPad fails to boot after installing Qubes. I had to boot the > USB drive via legacy boot for Qubes to install at all, but the EFI setup > doesn't happen. what model? If its new, you'll probably have more luck with 4.x. -- 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/cc3c0e95-d24e-4849-adf7-06ad3dc9018b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Lenovo ThinkPad, won't boot
My Lenovo ThinkPad fails to boot after installing Qubes. I had to boot the USB drive via legacy boot for Qubes to install at all, but the EFI setup doesn't happen. -- 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/5d8e4285-bd78-47a7-98bf-f3170c1f8cfd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: GPU?
It might be possible, just no one has implemented it in a way that does not require complex processing by trusted parts of system. There is an attempt called XenGT (for Intel iGPUs), but I am not sure about its state and at least it is not integrated to Qubes yet. Regards, Vít Šesták 'v6ak' -- 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/8f99b20c-82c8-4771-9cfc-460883e2d10a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Monday, January 15, 2018 at 12:57:09 PM UTC+1, awokd wrote: > It matters a bit because Spectre is harder to exploit than Meltdown. IIUR, > Qubes' design allowed it to constrict Meltdown to a single VM Not in PV, which are primary type of VM in 3.2. > I'm still > somewhat unclear on how Spectre operates under hardware virtualization but > you're right, it needs to be fixed. As far as I understand, Spectre can read the memory available of victim. That is: * If an application does not mitigate Spectre and attacker finds useful entry point, attacker can read memory of the application (but nothing more). * If VM kernel does not mitigate Spectre and attacker finds useful entry point, attacker can probably read memory of whole VM (but other VMs are not affected). * If Xen does not mitigate Spectre and attacker finds useful entry point, attacker can probably read memory of whole system. Please note that: * Attacker needs a suitable entry point. It might be difficult to find it. * All code needs to be recompiled in order to mitigate Spectre. It is not binary that you are/aren't protected. Some parts of system might be protected at the same time when others aren't. * Lowlevel components might need additional work because of assembly code. * Microcode update is needed only for some variants of patches. But retpoline might be preferred for both performance reasons and not need of microcode update. Regards, Vít Šesták 'v6ak' -- 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/cb5afe86-bd1a--8bb8-4bc875eeab2d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Monday, January 15, 2018 at 2:15:34 AM UTC+1, Nik H wrote: > Thanks, this is good info. I found instructions to update microcode in linux > - seems very simple. Xen instructions seem simple as well but where do I > enter this? In the Dom0 terminal? I am a bit unclear as to how Dom0 and Xen > interact. Well, dom0 is a privileged domain and any administration of Xen should be done from it. So, dom0 terminal is probably a good start. You will probably need to adjust Xen parameters. It depends if you have UEFI or legacy BIOS. You can see both variants (but you need to write something else than „iommu=no-igfx“) in this (otherwise unrelated) article: https://www.qubes-os.org/doc/intel-igfx-troubleshooting/ > I am guessing normal VMs do not have enough privileges to update microcode > (well... hopefully, otherwise compromised VMs could install malicious > microcode...) I hope so. They are digitally signed (at least at Intel), but still… > As a side-note, spectre does compromise the entire qubes architecture. Not fully. > Good that meltdown is not an issue, yes As far as I understand, Meltdown _is_ an issue. It allows reading memory of whole system. It will be hopefully fixed soon. Spectre is harder to exploit, but it will also take longer to fix it. -- 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/d2a3b048-0494-47d1-bc31-00802d57395d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: GPU?
Why is it not possible to securely virtualize the GPU? On Sunday, January 14, 2018 at 6:08:37 AM UTC-5, Vít Šesták wrote: > Qubes does not have GPU virtualization for security reasons. As a result, > additional GPU is used only in dom0 (od GuiVM in future). GPU might be useful > for: > > * additional output like HDMI (well, good luck…) > * window manager acceleration (but integrated GPU usually does the job well > for less power) > * GPU passthrough to a VM (It might work, but it is not officially not > supported and much work will be needed. Also, if the VM can rewrite GPU > firmware, the GPU can perform a DMA attack during boot.) > > When selecting my last laptop, I've decided to choose one without additional > GPU. First, I don't need it much. Second, it adds some hassle. It would be > ideal to have it switched off in order not to comsume power (=> lower heat, > more quiet laptop, better battery life). On the other hand, I remember having > HDMI output wired to the additional GPU, which was rather PITA. I was able to > get it somehow working on my old laptop, but it used to crash X11. > > HDMI through additional GPU will reportedly get better with Wayland, but we > are not there yet. > > Regards, > Vít Šesták 'v6ak' -- 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/e7300b2d-4d9a-4070-bdb3-4c8ca6a3e9f3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Sporadic Inter-VM Routing Issues with Qubes Updates Proxy
Hi, I was hoping someone may be able to help make heads or tails of this frustrating issue I'm having. Background I use a VPN configured as-per the Qubes recommended config for VPNs ([https://www.qubes-os.org/doc/vpn/).](https://www.qubes-os.org/doc/vpn/)https://www.qubes-os.org/doc/vpn/ I have used this configuration with the following VM hierarchy for some months without a problem: sys-net -> sys-firewall -> vpn -> vpn-firewall -> * [where "vpn-firewall" runs the qubes-yum-proxy service (verified TCP listener is showing up in netstat on 0.0.0.0:8082)] Problem Recently I have encountered a problem where whenever I go to update a TemplateVM, or dom0 - any VM that is configured to use the qubes update proxy - the dnf update times out. The following is the output of "sudo dnf -vvv --refresh update" on a Fedora 26 TemplateVM: Cannot download 'https://mirrors.fedoraproject.org/metalink?repo=updates-released-f26&arch=x86_64': Cannot prepare internal mirrorlist: Curl error (28): Timeout was reached for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f26&arch=x86_64 [Connection timed out after 30003 milliseconds]. Error: Failed to synchronize cache for repo 'updates' If we watch netstat during this attempted update, we see that a SYN is sent to the correct update proxy address of 10.137.255.254:8082, but no SYN-ACK is received: tcp0 1 10.137.5.14:57914 10.137.255.254:8082 SYN_SENT Leaving this running, no TCP connection is ever established with the qubes-updates-proxy service at "vpn-firewall". Similarly, watching for inbound connections on "vpn-firewall" yields no results for an incoming connection from the TemplateVM. During this time, all AppVMs continue to have full network connectivity via the vpn-firewall gateway. Now here's the weird bit... The problem is sporadic. Sometimes I can reboot my host machine and the updates proxy is broken, other times it works fine. To my untrained eye, this appears to be a routing issue internal to Xen. Does anyone have some advice on how I can investigate further? Many thanks in advance, Alex Sent with [ProtonMail](https://protonmail.com) Secure Email. -- 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/Lth6ihnbfp4s5zsCVYegGf-9dijq0Jm7DsSoXVNj5Es2S1zk0Fa-liAh-0mRV7XZI3DywKoicTOdThqrcKbfUfMJesBz7C-YLAs-6epw47k%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Sunday, January 14, 2018 at 12:20:48 PM UTC-5, Vít Šesták wrote: > As far as I understand it, microcode update cannot fix it. It just brings > some new instructions that can be used for Spectre fix. (But they don't help > on their own.) > > You can try to update your BIOS if it is well supported by your vendor. Mine > is. > > Alternatively, you can try to update microcode via Xen. (In fact, the new > microcode is loaded on every boot, because CPU has no persistent storage for > that. It should be loaded in early stage of boot.*) Xen has some > documentation, it would be probably enough to use some Linux package and add > something like “ucode=scan” to Xen parameters: > https://wiki.xenproject.org/wiki/XenParavirtOps/microcode_update > > Regards, > Vít Šesták 'v6ak' > > *) Some μcode updates can be loaded even runtime, but this is not so general > and I don't recommend it. As far as I understand, the result of runtime > patching might vary on what instructions have been used before the attempt to > patch it, so you could end up with some race condition. do you mean you need bios microcode update AND software fixes together to prevent these attacks? Also did you notice the "20% increase in cpu utilization" they are talking about? Because I feel I have had a dramatic increase in performance. I'm becoming skeptical about some of the information out there. -- 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/01aaec7e-9e3c-4a18-b563-1c0b2044df21%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [SPAM] Re: [qubes-users] validate IOMMU support
Hello, Thanks, I overlooked the no-strict-reset option. I will give this a try and see how it works out. Wim -Original Message- From: awokd [mailto:aw...@danwin1210.me] Sent: Monday, January 15, 2018 12:26 PM To: Wim Vervoorn Cc: qubes-users@googlegroups.com Subject: RE: [SPAM] Re: [qubes-users] validate IOMMU support On Mon, January 15, 2018 9:40 am, Wim Vervoorn wrote: > Hello, > > > I can understand that but there is no general rule for that. In many > cases this won't be possible at all. In some cases this can be > achieved by changing some configurations in the chip but in many cases > this will not be documented in public documents. > > I do think some things in Qubes can be improved regarding this support. > > > What I noticed is that all PCI devices in the systems are listed and > can be assigned to a VM BUT when I try to do this the VM will not > start (without any message to the user). I think two things can be > improved here. 1) Only list the devices that can actually be used ( so > they should support FLR or PM reset or bus reset). Listing the others > is confusing and will cause frustration by the users 2) Provide some > user feedback anyhow when a VM fails to start. Now a user needs to > consult the log to check what happens. This is not really convenient. There is a FAQ entry on it at least: https://www.qubes-os.org/faq/ Often you can still use them if you disable the strict reset requirement. -- 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/cd995e70248246d29547dacb23742e74%40Eltsrv03.Eltan.local. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] HCL - G505s (HD 8650G + R5 M230 dual graphics)
On Sun, January 14, 2018 7:07 pm, 'Emil Novik' via qubes-users wrote: > I did, no idea why HVM still doesn't work. > > > --- > Emil Novik > > > Original Message > On Jan 14, 2018, 19:48, taii...@gmx.com wrote: > > >> On 01/14/2018 06:05 AM, 'Emil Novik' via qubes-users wrote: >> >> >>> Mostly works fine, but has some issues : >>> - Can't use any HVM(crashes the computer every time). >>> >> Have you applied awokd's patch? >> Thought I had HVM on 3.2 working but once the Xen&Qubes updates for Meltdown/Spectre ship I'll go back and reinstall and confirm. Have been running HVM in 4.0 with no trouble. -- 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/08b414db7ed9c3d3f28fbbe6756d8a12.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Mon, January 15, 2018 1:15 am, Nik H wrote: > On Monday, January 15, 2018 at 12:20:48 AM UTC+7, Vít Šesták wrote: > >> As far as I understand it, microcode update cannot fix it. It just >> brings some new instructions that can be used for Spectre fix. (But >> they don't help on their own.) >> >> You can try to update your BIOS if it is well supported by your vendor. >> Mine is. >> >> >> Alternatively, you can try to update microcode via Xen. (In fact, the >> new microcode is loaded on every boot, because CPU has no persistent >> storage for that. It should be loaded in early stage of boot.*) Xen has >> some documentation, it would be probably enough to use some Linux >> package and add something like “ucode=scan” to Xen parameters: >> https://wiki.xenproject.org/wiki/XenParavirtOps/microcode_update > > Thanks, this is good info. I found instructions to update microcode in > linux - seems very simple. Xen instructions seem simple as well but where > do I enter this? In the Dom0 terminal? I am a bit unclear as to how Dom0 > and Xen interact. If you're referring to the "ucode=scan" addition to the bootloader; yes, you'd enter those from dom0. > As a side-note, spectre does compromise the entire qubes architecture. I > know, nobody was thinking about these things, so no shame in that. But > one of the main premises in qubes is that VMs are isolated from each > other, and that is no longer the case as long as spectre is out there. > Good that meltdown is not an issue, yes, but doesn't really matter, > weakest link and all that. It matters a bit because Spectre is harder to exploit than Meltdown. IIUR, Qubes' design allowed it to constrict Meltdown to a single VM versus other OS designs where that would give access to the entire system. I'm still somewhat unclear on how Spectre operates under hardware virtualization but you're right, it needs to be fixed. -- 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/79d8c47ca62d358458e6850a36a74686.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
RE: [SPAM] Re: [qubes-users] validate IOMMU support
On Mon, January 15, 2018 9:40 am, Wim Vervoorn wrote: > Hello, > > > I can understand that but there is no general rule for that. In many > cases this won't be possible at all. In some cases this can be achieved > by changing some configurations in the chip but in many cases this will > not be documented in public documents. > > I do think some things in Qubes can be improved regarding this support. > > > What I noticed is that all PCI devices in the systems are listed and can > be assigned to a VM BUT when I try to do this the VM will not start > (without any message to the user). I think two things can be improved > here. 1) Only list the devices that can actually be used ( so they should > support FLR or PM reset or bus reset). Listing the others is confusing > and will cause frustration by the users 2) Provide some user feedback > anyhow when a VM fails to start. Now a user needs to consult the log to > check what happens. This is not really convenient. There is a FAQ entry on it at least: https://www.qubes-os.org/faq/ Often you can still use them if you disable the strict reset requirement. -- 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/0da70dac1395770635870eb6c07237e1.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes Manager is coming back in Qubes 4.0-rc4!
On Saturday, January 13, 2018 at 3:58:03 AM UTC+1, Andrew David Wong wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > The Qubes VM Manager will be returning in Qubes 4.0-rc4, which is > scheduled for release next week. The returning Qubes Manager will be > slightly different from the 3.2 version. Specifically, it will not > duplicate functionality that is already provided by the new 4.0 > widgets. Specific examples include attaching and detaching block > devices, attaching and detaching the microphone, and VM CPU usage. > > - -- > Andrew David Wong (Axon) > Community Manager, Qubes OS > https://www.qubes-os.org > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpZdZwACgkQ203TvDlQ > MDB4GBAAqKQKgbUHWuTpzfW8o2HOjvM/fSxt9gSlDi+tS3x/dogNC0riO6VgFIJr > zNUm2/7nYF4iAiES0HamgVfNBHFpKY1QZgRYyokrLMK78HmCyIKJ3A0cF2LOvlsS > x88xpwBL0zwUX0y/eqsaxGGIqr9D1c25psYdi/IeE3KhR35gz/2j8HiB1/mEl0Z4 > JvepszI6HD7vJ41ullWsygHemTT2JAeFSCG0zWrfdxvkwYFQgXEn+AeEhgOL6BhM > RXFuMWnl2w0cbnPgDpnmT0IVHlz8gRsljkyWLkqT4k/pldhy9OCjtMKuHGIaaen6 > KLF2rGkpVObfgQQrQOdll03KrFqPona5ywtdeQUMDGVoNJXuhFidyCLWEKPBlAhS > LDCb/UxRbbPhwol4eEYeOnxWbCMgEwnEtnkEZiT4m9y3lQQLK+8zSZpW5uMLDzs0 > om9Xd9iba7hZomXE1rEcg2UaYok0lSQmzGS2YKh3OQbEmXtrZdILXVo0NLtDcTun > q47PzYjKc82ZeUZSLBjfkgf0mhocPuwk3FLsMb3rwW0kEbzuRZjHKgxgnRbOK67b > qH0roZ8GHrX7Xu4AvjYxUvlkTU+h2ObPMvxf2IR1/S37UUyrwNFEaC6czA/VmVV6 > 5SzFVGJkH/SFZsQ9qvzgjz/8OnLOMvBi3X/ee21G8s4ACmcrmrM= > =fcWR > -END PGP SIGNATURE- Awesome that you guys brought the Qubes Manager back. Besides being useful, it's even become a sort of trade-mark for Qubes, or even a mascot if you may. It's one of the major a visible ways to tell it's a Qubes system by look alone. Also I definitely agree that it's nice to be able to keep track of CPU/Ram more easily, or pending updates from the various different repositories, which can be a big mess when having many templates. So all in all, love that you guys brought it back. I'm fully aware the Qubes Manager isn't officially released yet until Qubes RC-4, so things might change with updates etc. but below are some minor concerns. * It resets windows size each time you close it down and open it again. It's nice we can change its size now, but it won't stick to the size we give it between closing it and opening it? It's in particular nice to remember windows size if you dedicate it to a specific screen, or a specific place on a screen, or if you want to key-bind it to appear and disappear when needed. * Another minor issue, which is much less of an issue, is dead links in the Qube menu, for Logs and Attach block devices. Since you specifically announced you won't duplicate tasks that the widget is already handling, perhaps it might be best to remove these two dead links, which are also handled by the Qubes widget? No biggie, just something minor I noticed. Other than that, it's really nice to have again, and above issues really are minor issues, really. Although it'd sweet if it remembered the window size, but it's only like the dot above the i, a minor detail before perfection. -- 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/de1af2a5-b1fd-41f3-9f3c-a250a6e75935%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes Manager is coming back in Qubes 4.0-rc4!
On Monday, January 15, 2018 at 11:06:57 AM UTC+1, Roy Bernat wrote: > On Monday, 15 January 2018 03:18:27 UTC+2, Nik H wrote: > > Great news, thank you! > > regarding update to rc4 from rc3 ? should we install again ? > > R >From what I gather, this info whether to re-install or just update, will be >available again in the Qubes 4 RC-X news articles from the Qubes team. It >might be buried somewhere in a bit larger text like the last few times, so be >careful to read it through carefully. It should be posted right before the >RC-4 download is available according to the default schedule found on Qubes's >GitHub when releasing new RC's. -- 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/587bb043-7173-478d-a981-d7b9b2bc79c8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes Manager is coming back in Qubes 4.0-rc4!
On Monday, 15 January 2018 03:18:27 UTC+2, Nik H wrote: > Great news, thank you! regarding update to rc4 from rc3 ? should we install again ? R -- 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/6061672a-8ab9-4b60-840e-351cb3d40740%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Cannot execute qrexec-daemon
Github ticket number: #3459 Le lundi 15 janvier 2018 08:40:45 UTC+2, ThierryIT a écrit : > update: All type of VMs can run only if there is no selected devices. > > > > Le dimanche 14 janvier 2018 13:40:41 UTC+2, ThierryIT a écrit : > > Hello, > > > > R3.2 > > > > > > I have installed yesterday and this morning AEM and sys-usb. > > I had problem to make AEM working, but it seems now to work. > > When booting I should have my two VMs "netVM and proxyVM" running ... Not > > the case anymore. > > My wifi device doesn't seems to be up as it was before (internal not usb). > > > > I have removed sys-usb: same pb > > > > TemplateVM are still able to run > > StandaloneVM are not running (cannot execute qrexec-daemon) > > netVM and proxyVM same pb than above. > > > > Thx -- 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/49d5b731-8f91-4f43-9192-5d77d32eefcc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [SPAM] Re: [qubes-users] validate IOMMU support
Hello, I can understand that but there is no general rule for that. In many cases this won't be possible at all. In some cases this can be achieved by changing some configurations in the chip but in many cases this will not be documented in public documents. I do think some things in Qubes can be improved regarding this support. What I noticed is that all PCI devices in the systems are listed and can be assigned to a VM BUT when I try to do this the VM will not start (without any message to the user). I think two things can be improved here. 1) Only list the devices that can actually be used ( so they should support FLR or PM reset or bus reset). Listing the others is confusing and will cause frustration by the users 2) Provide some user feedback anyhow when a VM fails to start. Now a user needs to consult the log to check what happens. This is not really convenient. Best regards, Wim Vervoorn -Original Message- From: Frans Hendriks Sent: Monday, January 15, 2018 9:42 AM To: Wim Vervoorn Subject: FW: [SPAM] Re: [qubes-users] validate IOMMU support -Original Message- From: taii...@gmx.com [mailto:taii...@gmx.com] Sent: vrijdag 12 januari 2018 18:24 To: aw...@danwin1210.me; Wim Vervoorn Cc: qubes-users Subject: [SPAM] Re: [qubes-users] validate IOMMU support On 01/12/2018 06:31 AM, 'awokd' via qubes-users wrote: > On Fri, January 12, 2018 8:23 am, Wim Vervoorn wrote: >> Hello, >> >> >> Thanks. I tried this. Now I am running into problems with the PCI >> devices I am using. Qubes can't reset those. For some reason they are >> not exposing the FLR capability. I am trying to find out why because >> they should according to the datasheet. > I'm personally interested in this because I have the same issue with a > Corebooted laptop so please let me know if you figure it out, but > there are probably going to be more subject matter experts over on the > Coreboot mailing list! > > For purposes of validating IOMMU support though, as long as you can > get one PCI device passed through I think that would be all that matters? If you can pass through a device, you have quality IOMMU groups and IOMMU-IR is enabled in dmesg then you are good to go. I too would like to know how to modify the PCI capabilities list. -- 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/83f5b81ac92e44ed82771489374006b8%40Eltsrv03.Eltan.local. For more options, visit https://groups.google.com/d/optout.
