[qubes-users] Looking to explicitly not use mirrors to download fedora updates
Hi, I checked DNS queries being made as I was updating templateVMs today and I noticed that there is an extreme bias preference of using ftp.riken.jp which didn't sit well with me since that would mean that it was downloading updates in plaintext and thus, unprotected against MITM attacks. While I know that dnf has a verification system in place, I do not want to completely depend on it. With that, I've done some research about it which led me to this: https://askbot.fedoraproject.org/en/question/7960/how-to-choose-a-specific-mirror-source/ I noticed that on both fedora.repo and fedora-updates.repo, the baseurl is commented out and metalink is definitely the one being used. So I'm thinking that maybe it's enough to just comment out metalink and settle with the baseurl. Would this be enough for what I need to get done or am I missing something? Also, if you guys have suggestions for a mirror to trust then I would be willing to take you up on those -- 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/44d7f216-638d-4a64-9ecd-e44823ce9d77%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Does Qubes-OS 4.0.1 have support for KDE or GNOME desktop environment?
On 6/5/19 8:00 PM, Chris Laprise wrote: On 6/2/19 3:41 AM, Finn wrote: I've installed Qubes-OS 4.0.1 and it's XFCE desktop environment but I would rather prefer either KDE or GNOME desktop environment. I found this document[1] where mentioned that Qubes-OS is migrating towards GNOME but at the time of installation only XFCE (neither KDE nor GNOME) is available. I was wondering, is there a way I can use my preferred desktop environment? Or, I have to wait for GNOME until migration is not fully completed because it seems currently there is no support for KDE. [1]: https://www.qubes-os.org/doc/usability-ux/ KDE does have support AFAIK, although its no long the default. If you can get used to the blank-space network icon, then I recommend KDE as there are many pluses. I don't believe Qubes is actually going to migrate to Gnome. There was an aborted attempt and Gnome 3's paradigm (tablet touch UI, melded WM/app widgets) doesn't seem compatible with Qubes' concept. https://www.qubes-os.org/doc/kde/ suppose one follow these instructions but does *not want to use sddm nor change any windows management settings on reboot one is logged into XFCE then, in dom0 can type startkde or startkde --replace xfce ? but this seems to result in 2 taskbars running what would be the way to choose the DM on login or to startkde and close xfce or is that possible ? -- 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/0fbaf002-8da5-f751-2969-a5afd6646e34%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: desktop suspend breaks sys-usb/ CPU bug present
On 6/12/19 8:14 AM, Jon deps wrote: Hello, using the suspend function, when I awake the desktop, the usb mouse non longer functions. have a PS2 keyboard so was able to qvm-kill sys-usb and do qvm-start sys-usb but it complained couldn't connect to qrexec or so and failed. so qvm-start sys-usb a 2nd time and then the mouse functions again is this to be expected, or is there something to fix ? --- looking around journalctl I didn't find much but did find this un 12 07:52:01 dom0 kernel: sd 5:0:0:0: [sdb] Starting disk Jun 12 07:52:01 dom0 kernel: sd 1:0:0:0: [sda] Starting disk Jun 12 07:52:01 dom0 kernel: pcieport :00:1d.7: Intel SPT PCH root port ACS workaround enabled Jun 12 07:52:01 dom0 kernel: pcieport :00:1d.3: Intel SPT PCH root port ACS workaround enabled Jun 12 07:52:01 dom0 kernel: ACPI: Waking up from system sleep state S3 Jun 12 07:52:01 dom0 kernel: CPU3 is up Jun 12 07:52:01 dom0 kernel: cache: parent cpu3 should not be sleeping Jun 12 07:52:01 dom0 kernel: cpu 3 spinlock event irq 147 Jun 12 07:52:01 dom0 kernel: installing Xen timer for CPU 3 Jun 12 07:52:01 dom0 kernel: CPU2 is up Jun 12 07:52:01 dom0 kernel: MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details. Jun 12 07:52:01 dom0 kernel: cache: parent cpu2 should not be sleeping Jun 12 07:52:01 dom0 kernel: cpu 2 spinlock event irq 140 Jun 12 07:52:01 dom0 kernel: installing Xen timer for CPU 2 Jun 12 07:52:01 dom0 kernel: CPU1 is up Jun 12 07:52:01 dom0 kernel: cache: parent cpu1 should not be sleeping Jun 12 07:52:01 dom0 kernel: cpu 1 spinlock event irq 133 Jun 12 07:52:01 dom0 kernel: installing Xen timer for CPU 1 Jun 12 07:52:01 dom0 kernel: Enabling non-boot CPUs ... went to the URL says something like I should be "enable CPU buffer clearing" but can't find how to do that, curious if it's actual needed ? moral of the story don't suspend your qubes desktop ? .any idea on the "data leak possible"journal entry? sounds a bit scary, maybe I need to look around in my UEFI to disable some cache-ing ? BTW, kudos to qubes team for the dom0 copy to clipboard widget , sure makes it easier to get dom0 notes out ! -- 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/619dd1d0-45f6-e271-c4de-2eb2303a0a8c%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes: Unable to connect to VPN
> > Install per the instructions for Mr.Laprise's excellent > qubes-vpn-setup in an Template-based AppVM , don't miss any steps. > ELSE > > delete the AppVM and startover make sure openvpn is installed in > the Template chosen , make sure to enable proxy in the created AppVM > , and for services add the openvpn in the qubes manager tab > > Which VPN provider are you using ? > > Thanks. Turned out that we probably got it to work earlier, but didn't know how to test it properly. So, we spent days trying to figure out a problem that didn't exist. We were confused from Step 1 by fact that to create ProxyVM, one now has to know to create an AppVM, and check "provides network". Setting "vpn-handler-openvpn" in the the Services for that qubes, as some thread suggested, is still something we are not sure about. We've decided to move to a hardware device from the VPN provider. With so many manual steps and several different ways to set it up, on top of VPN provider script variations, a device seems the safest option to avoid making some mistake or misunderstanding, because we are not security experts or developers in the field. - > > 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/ac3b7cc3-eede-c2f3-d368-7de333dd3c2a%40riseup.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/ZMCpY0k63FxEEoDdmVtdC14qqJlZYEZTH-m9p7B5mUiIIKxzjT1TjRuQ8jSC0ONyt2DKRFHf0OC7XeDfTXd9J6TFdkjlamj967-cr97J1wM%3D%40protonmail.ch. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Full proper backup of Dom0 possible?
On 6/12/19 3:04 PM, Mike Keehan wrote: On Wed, 12 Jun 2019 10:29:54 -0400 Chris Laprise wrote: On 6/11/19 6:50 PM, Chris Laprise wrote: I think the best solution for a safe and comprehensive dom0 backup is to have Qubes simply snapshot the root lv at boot time, before its mounted as read-write. It shouldn't take more than a few script lines in the dom0 startup. Then dom0 can be backed up like any other vm. I created an issue with a 3-line (barely tested) example here: https://github.com/QubesOS/qubes-issues/issues/5094 Chris, have you some thoughts on how to restore such a backup? Mike. Good question. LVs can be renamed while they are active, so initiating a reboot process right after lvrename should work. Alternately, lvrename could be added to the shutdown process itself. Another approach is to just mount the restored lv and retrieve the files you need from it. The other issue with backing up dom0 is what to do about the boot partition. Its not active during normal use, so could be as simple as remounting as read-only, then 'dd' or 'tar' to a file on the root fs, then proceed with root snapshot and backup. Restoring it would be the reverse. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/39cc7d33-2a43-bc48-adb7-5cfe126c2d78%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Will AEM work with UEFI boot (A.K.A. GPT)?
"GRUB2. Should be UEFI with CSM disabled." As in GRUB2 is needed for AEM? (Just a good ol' yes or no will do, unless I'm missing an important piece of info.) -- 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/GtuPNV72A9zLC7dN5q3cB64bii8owhBY_cFwUYJ9yV-dg94EyH4D5srLSTlZGc8yxnur8ilkh9BlfwJh9bsr0b0EuEZPx9js5Kd1Bun2HdE%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: desktop suspend breaks sys-usb/ CPU bug present
On Wednesday, June 12, 2019 at 2:29:12 PM UTC-4, Jon deps wrote: > Hello, using the suspend function, when I awake the desktop, the usb > mouse non longer functions. > > have a PS2 keyboard so was able to qvm-kill sys-usb and do qvm-start > sys-usb but it complained couldn't connect to qrexec or so and failed. > > so qvm-start sys-usb a 2nd time and then the mouse functions again This is a long-standing issue for some, resolved for some but not for others at different times. See https://github.com/QubesOS/qubes-issues/issues/4042 The situation has improved for me by getting kernel 4.19.43-1 from qubes-dom0-security-testing. You could try the new kernel. (But note that our problems might be a bit different, I never had a qrexec problem when restarting sys-usb after resume.) If you need to automate restarting of sys-usb because you can't avoid this problem, you can add commands in /usr/lib64/pm-utils/sleep.d/52qubes-pause-vms for suspend and resume, e.g., qvm-shutdown sys-usb and qvm-start sys-usb. You might need to qvm-kill sys-usb before suspend to get this to work reliably. Daniel -- 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/9e6909ec-4055-416b-9db6-720f6c1363dd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes: Unable to connect to VPN
On 6/12/19 2:53 PM, Chris Laprise wrote: On 6/12/19 10:14 AM, 'Crypto Carabao Group' via qubes-users wrote: We've also been trying for days to get a VPN to resolve on a brand new R4.0 install, to either one of 2 different VPN providers, using the iptables and cli scripts: https://www.qubes-os.org/doc/vpn/#set-up-a-proxyvm-as-a-vpn-gateway-using-iptables-and-cli-scripts I've also set it up before on a 3.x cubes and it worked using the above. So far, what's pretty certain is that these instructions were carried over automatically, but actually don't work for the R4.0 version. BTW, there is no "/usr/lib/qubes/qubes-vpn-setup" in the Fedora 29 or Debian 9 templates. So, wherever that came from, it's not in the new installer version we got. There is no mention of a 'qubes-vpn-setup' in the vpn doc you linked to. That script is a part of my Qubes-vpn-support project on github. You might want to use that instead since the setup process is much simpler: https://github.com/tasket/Qubes-vpn-support Neither is there a path: /etc/openvpn/update-resolv-conf in the VMs based on Fedora 29. (Haven't tried Debian 9 for that yet.) That probably came from a particular VPN provider, and would have to be installed in the template anyway to persist, right? There is no mention of 'update-resolv-conf' in the vpn doc, either. One of the most frequent causes of failed vpn setups is when the user decides to mix or combine different instructions because 'more is better' or because they saw different people discussing the merits of different approaches. This does NOT work; you have to pick one and follow it. It seems that the update-resolve-conf is a default script that ships with some distros, such as Mint (attached), and works on our other machine, and does the function that the "|qubes-vpn-handler.sh|" does in the Qubes VPN instructions, but it doesn't work on Qubes in our case for the same VPN provider either. Seems to require a lot of modification and merge the two maybe, which will take us another several days to figure out, if ever. Updating resolv.conf is not required at all to get DNS working for downstream appVMs. The instructions avoid doing this to help keep the VPN VM in a locked-down state, so it doesn't inadvertently try to access the tunnel for its internal programs (i.e. only downstream VMs get to access the tunnel). What IS necessary is populating the DNAT rules in the firewall. Check the PR-QBS chain to see if your DNS server IPs were added: iptables -L -v -t nat PR-QBS Install per the instructions for Mr.Laprise's excellent qubes-vpn-setup in an Template-based AppVM , don't miss any steps. ELSE delete the AppVM and startover make sure openvpn is installed in the Template chosen , make sure to enable proxy in the created AppVM , and for services add the openvpn in the qubes manager tab Which VPN provider are you using ? -- 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/ac3b7cc3-eede-c2f3-d368-7de333dd3c2a%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Full proper backup of Dom0 possible?
On Wed, 12 Jun 2019 10:29:54 -0400 Chris Laprise wrote: > On 6/11/19 6:50 PM, Chris Laprise wrote: > > I think the best solution for a safe and comprehensive dom0 backup > > is to have Qubes simply snapshot the root lv at boot time, before > > its mounted as read-write. It shouldn't take more than a few script > > lines in the dom0 startup. Then dom0 can be backed up like any > > other vm. > > I created an issue with a 3-line (barely tested) example here: > > https://github.com/QubesOS/qubes-issues/issues/5094 > Chris, have you some thoughts on how to restore such a backup? 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/20190612200415.1932e84d.mike%40keehan.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] desktop suspend breaks sys-usb/ CPU bug present
Hello, using the suspend function, when I awake the desktop, the usb mouse non longer functions. have a PS2 keyboard so was able to qvm-kill sys-usb and do qvm-start sys-usb but it complained couldn't connect to qrexec or so and failed. so qvm-start sys-usb a 2nd time and then the mouse functions again is this to be expected, or is there something to fix ? --- looking around journalctl I didn't find much but did find this un 12 07:52:01 dom0 kernel: sd 5:0:0:0: [sdb] Starting disk Jun 12 07:52:01 dom0 kernel: sd 1:0:0:0: [sda] Starting disk Jun 12 07:52:01 dom0 kernel: pcieport :00:1d.7: Intel SPT PCH root port ACS workaround enabled Jun 12 07:52:01 dom0 kernel: pcieport :00:1d.3: Intel SPT PCH root port ACS workaround enabled Jun 12 07:52:01 dom0 kernel: ACPI: Waking up from system sleep state S3 Jun 12 07:52:01 dom0 kernel: CPU3 is up Jun 12 07:52:01 dom0 kernel: cache: parent cpu3 should not be sleeping Jun 12 07:52:01 dom0 kernel: cpu 3 spinlock event irq 147 Jun 12 07:52:01 dom0 kernel: installing Xen timer for CPU 3 Jun 12 07:52:01 dom0 kernel: CPU2 is up Jun 12 07:52:01 dom0 kernel: MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details. Jun 12 07:52:01 dom0 kernel: cache: parent cpu2 should not be sleeping Jun 12 07:52:01 dom0 kernel: cpu 2 spinlock event irq 140 Jun 12 07:52:01 dom0 kernel: installing Xen timer for CPU 2 Jun 12 07:52:01 dom0 kernel: CPU1 is up Jun 12 07:52:01 dom0 kernel: cache: parent cpu1 should not be sleeping Jun 12 07:52:01 dom0 kernel: cpu 1 spinlock event irq 133 Jun 12 07:52:01 dom0 kernel: installing Xen timer for CPU 1 Jun 12 07:52:01 dom0 kernel: Enabling non-boot CPUs ... went to the URL says something like I should be "enable CPU buffer clearing" but can't find how to do that, curious if it's actual needed ? moral of the story don't suspend your qubes desktop ? -- 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/3e735f62-644d-9f80-d580-ceb5ff07da94%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes: Unable to connect to VPN
On 6/12/19 10:14 AM, 'Crypto Carabao Group' via qubes-users wrote: We've also been trying for days to get a VPN to resolve on a brand new R4.0 install, to either one of 2 different VPN providers, using the iptables and cli scripts: https://www.qubes-os.org/doc/vpn/#set-up-a-proxyvm-as-a-vpn-gateway-using-iptables-and-cli-scripts I've also set it up before on a 3.x cubes and it worked using the above. So far, what's pretty certain is that these instructions were carried over automatically, but actually don't work for the R4.0 version. BTW, there is no "/usr/lib/qubes/qubes-vpn-setup" in the Fedora 29 or Debian 9 templates. So, wherever that came from, it's not in the new installer version we got. There is no mention of a 'qubes-vpn-setup' in the vpn doc you linked to. That script is a part of my Qubes-vpn-support project on github. You might want to use that instead since the setup process is much simpler: https://github.com/tasket/Qubes-vpn-support Neither is there a path: /etc/openvpn/update-resolv-conf in the VMs based on Fedora 29. (Haven't tried Debian 9 for that yet.) That probably came from a particular VPN provider, and would have to be installed in the template anyway to persist, right? There is no mention of 'update-resolv-conf' in the vpn doc, either. One of the most frequent causes of failed vpn setups is when the user decides to mix or combine different instructions because 'more is better' or because they saw different people discussing the merits of different approaches. This does NOT work; you have to pick one and follow it. It seems that the update-resolve-conf is a default script that ships with some distros, such as Mint (attached), and works on our other machine, and does the function that the "|qubes-vpn-handler.sh|" does in the Qubes VPN instructions, but it doesn't work on Qubes in our case for the same VPN provider either. Seems to require a lot of modification and merge the two maybe, which will take us another several days to figure out, if ever. Updating resolv.conf is not required at all to get DNS working for downstream appVMs. The instructions avoid doing this to help keep the VPN VM in a locked-down state, so it doesn't inadvertently try to access the tunnel for its internal programs (i.e. only downstream VMs get to access the tunnel). What IS necessary is populating the DNAT rules in the firewall. Check the PR-QBS chain to see if your DNS server IPs were added: iptables -L -v -t nat PR-QBS -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/30080605-e0c5-4610-4279-1007b1e3b56f%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Full proper backup of Dom0 possible?
On 6/11/19 6:50 PM, Chris Laprise wrote: I think the best solution for a safe and comprehensive dom0 backup is to have Qubes simply snapshot the root lv at boot time, before its mounted as read-write. It shouldn't take more than a few script lines in the dom0 startup. Then dom0 can be backed up like any other vm. I created an issue with a 3-line (barely tested) example here: https://github.com/QubesOS/qubes-issues/issues/5094 -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5cb89da3-e586-88a0-5513-5a2b0a141010%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes: Unable to connect to VPN
We've also been trying for days to get a VPN to resolve on a brand new R4.0 install, to either one of 2 different VPN providers, using the iptables and cli scripts: https://www.qubes-os.org/doc/vpn/#set-up-a-proxyvm-as-a-vpn-gateway-using-iptables-and-cli-scripts I've also set it up before on a 3.x cubes and it worked using the above. So far, what's pretty certain is that these instructions were carried over automatically, but actually don't work for the R4.0 version. BTW, there is no "/usr/lib/qubes/qubes-vpn-setup" in the Fedora 29 or Debian 9 templates. So, wherever that came from, it's not in the new installer version we got. Neither is there a path: /etc/openvpn/update-resolv-conf in the VMs based on Fedora 29. (Haven't tried Debian 9 for that yet.) That probably came from a particular VPN provider, and would have to be installed in the template anyway to persist, right? It seems that the update-resolve-conf is a default script that ships with some distros, such as Mint (attached), and works on our other machine, and does the function that the "`qubes-vpn-handler.sh`" does in the Qubes VPN instructions, but it doesn't work on Qubes in our case for the same VPN provider either. Seems to require a lot of modification and merge the two maybe, which will take us another several days to figure out, if ever. Openvpn actually does connect, but there's no DNS resolution, because the resolv.conf doesn't get updated. One thing we noticed is that in the resolvctl the 8.8.8.8 and 8.8.4.4 and a couple of IPv6 servers are listed as "Fallback DNS Servers". We can even resolve manually using them with dig. However, the systemd-resolved or whatever is doing the resolution in this systemd mess, actually doesn't use them as a "Fallback" to resolve. Don't know what to do next to fix this, except just more trial and error, and messy hack arounds... On Tuesday, November 20, 2018 at 7:38:17 PM UTC, Otto Kratik wrote: > Further update: I decided to try a completely different VPN provider's config > file, and to my surprise that one worked fine using the old simple method of > calling openvpn from the AppVM. > > Examining both files and looking for the difference between the two, it > appears the broken one did not ever invoke resolvconf include the following > lines: > > script-security 2 > up /etc/openvpn/update-resolv-conf > down /etc/openvpn/update-resolv-conf > > > Adding those lines to the non-functioning file and running it resulted in > success. -- 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/J1cmNix8ygkshY3RKFWTEOuBvaV8rx7JRFEnnrurBo5JaFl-mRz9r9Osn1o3oh2vah8J4G7YPFcQ2ThmDp2U0TGQx7kV192unHv9mKU9H_M%3D%40protonmail.ch. For more options, visit https://groups.google.com/d/optout. update-resolv-conf Description: Binary data publickey - cryptocarabao@protonmail.ch - 0x3F7D5EFD.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Will AEM work with UEFI boot (A.K.A. GPT)?
'interested_in_QubesOS' via qubes-users: GRUB or GRUB2? Probably seems trivial but avoiding ambiguity makes things simpler. :-) A question I have to go along with this is what boot loader will the OS installer give me with CSM disabled? GRUB2. Should be UEFI with CSM disabled. -- 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/6b39168a-21f2-9021-1cfb-9ba1fc0a4896%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
