Re: [qubes-users] Re: sys-firewall freezing on resume from suspend
On 6/10/22 23:45, Demi Marie Obenour wrote: On Fri, Jun 03, 2022 at 04:00:20PM +0200, Qubes OS Users Mailing List wrote: So, apparently, this is not a sys-firewall, but a clocksync issue. To root out any causes, I moved the clocksync service to a separate, brand new qube (named sys-clock). And voila: sys-firewall no longer 'crashes' on resume from suspend, now it's sys-clock. The cause is probably somewhere in some logfile, but with the many moving parts, Qubes really needs a better bugfixing howto. With relatively many minor bugs like this, bugfixing takes too much time. I don't mind spending some time fixing bugs, but lately it is really becoming too much, to the extend that I am considering switching back to an easier regular Linux distro. I have been a paid Linux sysadmin, no total expert, but that is also not a requirement to use Qubes. I should be able to diagnose bugs on my own laptop (and contribute to the project by properly reporting them). Indeed, you should be able to. The fact that you cannot is itself a bug. Please report it. To prevent soiling the issues list, and make it a little more actionable, let's first discuss this here. What I need is a little more help with fixing or adequately diagnosing bugs, as a sysadmin level person, no programmer or Xen or Qubes expert. As said, to be able to fix or report & diagnose bugs and other issues better. For instance, a list of logfiles added to standard fedora by qubes/zen would be helpfull. So just a list, no further explanation of how to use logfiles. I don't have more ideas currently, but there probably are. What worries me a little bit is that documentation like this might encourage less skilled people to start doing things above their level of ability (although this is also a good start to become more skilled). Like, in the case of logfiles, soiling communication channels with non-relevant information. So it should come with a clear warning. Suggestions (or critique) welcome. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ead8c970-e4cc-435e-7d74-fc35422bcbd0%40disroot.org.
Re: [qubes-users] Re: sys-firewall freezing on resume from suspend
Yes, it! https://github.com/QubesOS/qubes-issues/issues/7510#issuecomment-1146258366_ On 6/10/22 23:49, Demi Marie Obenour wrote: On Fri, Jun 03, 2022 at 04:00:20PM +0200, Qubes OS Users Mailing List wrote: So, apparently, this is not a sys-firewall, but a clocksync issue. To root out any causes, I moved the clocksync service to a separate, brand new qube (named sys-clock). And voila: sys-firewall no longer 'crashes' on resume from suspend, now it's sys-clock. https://github.com/QubesOS/qubes-core-admin/pull/473 will (hopefully) fix this. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/03c1c15d-d193-941b-4da5-870d8e697441%40disroot.org.
Re: [qubes-users] Re: sys-firewall freezing on resume from suspend
On 6/4/22 11:56, tetrahe...@danwin1210.de wrote: On Fri, Jun 03, 2022 at 04:00:20PM +0200, 'qtpie' via qubes-users wrote: So, apparently, this is not a sys-firewall, but a clocksync issue. To root out any causes, I moved the clocksync service to a separate, brand new qube (named sys-clock). And voila: sys-firewall no longer 'crashes' on resume from suspend, now it's sys-clock. This should probably be filed as an issue: github.com/QubesOS/qubes-issues Someone else filed an issue where this was solved for me: https://github.com/QubesOS/qubes-issues/issues/7510. Briefly put: Manually applying the patch from https://github.com/QubesOS/qubes-core-admin/pull/473 to dom0:/usr/lib/python3.8/site-packages/qubes/vm/qubesvm.py and then restarting seems to have solved the issue. Also clock syncing trouble after suspend seem to have improved. So this was a suspend and not a clock or firewall issue. This should come soon to dom0 as an update I guess -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6f7a39d1-a13a-b7a6-184e-3dee407ae852%40disroot.org.
[qubes-users] Re: sys-firewall freezing on resume from suspend
So, apparently, this is not a sys-firewall, but a clocksync issue. To root out any causes, I moved the clocksync service to a separate, brand new qube (named sys-clock). And voila: sys-firewall no longer 'crashes' on resume from suspend, now it's sys-clock. The cause is probably somewhere in some logfile, but with the many moving parts, Qubes really needs a better bugfixing howto. With relatively many minor bugs like this, bugfixing takes too much time. I don't mind spending some time fixing bugs, but lately it is really becoming too much, to the extend that I am considering switching back to an easier regular Linux distro. I have been a paid Linux sysadmin, no total expert, but that is also not a requirement to use Qubes. I should be able to diagnose bugs on my own laptop (and contribute to the project by properly reporting them). On 5/28/22 01:15, qtpie wrote: Hi, I have a really annoying issue with resume from suspend. On resume, sys-firewall is crashed/freezed/unresponsive. So on every resume from suspend, I need to kill and restart this VM if I want to use networking. Other qubes are fine, except that sys-whonix also freezes, but this is because it can't get a network connection to sys-firewall. The VM is based on the default debian 11 template without any special modifications. It has worked fine this way for years. Qubes is the latest version. Kernel used 4.10.112. Symptoms: - High reported ram/cpu use, cpu hovering around 10-20% - vm terminal: shows a blank window, no input/output shown - xen console in dom0: no output - does not pass networktraffic from connected VM's - stopped connected VM's can't start because of failed vif (network connection) creation. - sometimes, after a shorter suspend, the VM still works, or it does pass networktraffic while the vm still can't open a terminal window. I've tried: - checking both before and after suspend the VM console and syslog, dom0 journal, dmesg, xen logs. It doesn't show any relevant error as far as I can tell. - creating a fresh sys-firewall VM. No change. - switching the VM to a fedora 35 template, fully upgraded. No change - checking possibly related issues on qubes github. But those are all either fixed with updates, or about VM's with PCI devices connected, which this VM doesn't. What is this problem? Why does it only occur with sys-firewall VM? Which logs to doublecheck? Any suggestions welcome. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a8bc0e8d-0183-808c-7a0e-3927dd11b41b%40disroot.org.
[qubes-users] sys-firewall freezing on resume from suspend
Hi, I have a really annoying issue with resume from suspend. On resume, sys-firewall is crashed/freezed/unresponsive. So on every resume from suspend, I need to kill and restart this VM if I want to use networking. Other qubes are fine, except that sys-whonix also freezes, but this is because it can't get a network connection to sys-firewall. The VM is based on the default debian 11 template without any special modifications. It has worked fine this way for years. Qubes is the latest version. Kernel used 4.10.112. Symptoms: - High reported ram/cpu use, cpu hovering around 10-20% - vm terminal: shows a blank window, no input/output shown - xen console in dom0: no output - does not pass networktraffic from connected VM's - stopped connected VM's can't start because of failed vif (network connection) creation. - sometimes, after a shorter suspend, the VM still works, or it does pass networktraffic while the vm still can't open a terminal window. I've tried: - checking both before and after suspend the VM console and syslog, dom0 journal, dmesg, xen logs. It doesn't show any relevant error as far as I can tell. - creating a fresh sys-firewall VM. No change. - switching the VM to a fedora 35 template, fully upgraded. No change - checking possibly related issues on qubes github. But those are all either fixed with updates, or about VM's with PCI devices connected, which this VM doesn't. What is this problem? Why does it only occur with sys-firewall VM? Which logs to doublecheck? Any suggestions welcome. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3deeb6b8-4fd3-e5fb-511b-627570b63647%40disroot.org.
[qubes-users] Re: usb keyboard not working on debian 11 template
Installing qubes-input-proxy-sender in the template it was. Problem solved. Thanks awokd! Note: to avoid this problem, these should either be default installed packages in all templates, or be documented in https://www.qubes-os.org/doc/usb-qubes/. If the latter is preferred, I can adapt the documentation. Please let me know. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/fdddae23-40df-6fe6-23f8-99b78d06bbc6%40disroot.org.
[qubes-users] usb keyboard not working on debian 11 template
Hi, Question: does a template qube need some kind of modification to let a sys-usb qube based on that template work with usb keyboards? Issue: On a debian 10 template, my usb keyboard/mouse combo 'just worked'(tm): 1. I have a default sys-usb qube 2. I attach the keyboard device (either before or after startup, tried both) 3. I get the 'Device X is available' notification 4. I can use the device both inside the sys-usb qube and in other qubes and in dom0 When I switch the sys-usb to a debian 11 template: (same) 4. I can use the keyboard inside the sys-usb qube, not in other qubes. The mousepointer does not respond at all. How can I troubleshoot this? thanks for your suggestions. --- fyi, this is my only problem with debian 11 as the default template, multiple applications seem to work smoother when compared to debian 10. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6ab45cb8-2d62-c3fe-fd6a-66e8c5db083a%40disroot.org.
[qubes-users] DNS issues: servfail on selected subdomains, Qubes modifying DNS replies by stripping IPv6?
I have a very annoying issue with DNS recently. I'm using the standard DNS device and servers provided by my internetprovider which runs a full dual-stack IPv4/6. Other non-qubes devices have no issues. I think this might be a Qubes bug but I want to ask for help first to rule out an error on my side. Selected domainnames (all subdomains, eg www.qubes.org, so not qubes.org) get a SERVFAIL when trying to resolve them within applications, and on the commandline with 'host' and 'nslookup'. Strangely enough, 'dig' has no issues, (querying the same default resolver ip of course). At times, the domainname will resolve inside sys-net and certain app-vm's, and not in another app-vm. At other times, it resolves nowhere. When quering resolvers directly (like my isp's resolvers or 1.1.1.1) the issue does not occur. What can be happening here? One of the only consistent hints I found is that Qubes does not seem to pass the full nslookup response from sys-net to the appvm (compare nslookup examples below). My router gives a servfail when quering it via ipv4, nslookup then tries it's ipv6 address, where it does get a reply, but this reply is not passed to the appvm. The servfail might be an ipv6 issue or an issue with my router, but I think still Qubes should pass the full response, right? some affected domainnames: www.duckduckgo.com www.startpage.com textsecure-service.whispersystems.org user@chat-1:~$ host -v www.startpage.com Trying "www.startpage.com" Host www.startpage.com not found: 2(SERVFAIL) Received 35 bytes from 10.139.1.2#53 in 2 ms - user@chat-1:~$ nslookup www.startpage.com ;; Got SERVFAIL reply from 10.139.1.1, trying next server Server: 10.139.1.2 Address: 10.139.1.2#53 ** server can't find www.startpage.com: SERVFAIL user@sys-net:~$ host -v www.startpage.com Trying "www.startpage.com" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22135 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.startpage.com. IN A ;; ANSWER SECTION: www.startpage.com. 2393 IN CNAME startpage.com. startpage.com. 10 IN A 145.131.132.72 Received 65 bytes from 192.168.0.1#53 in 4 ms Trying "startpage.com" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8508 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;startpage.com. IN ;; AUTHORITY SECTION: startpage.com. 2598 IN SOA dns1.p01.nsone.net. hostmaster.nsone.net. 1619470914 3600 600 1209600 3600 Received 96 bytes from 192.168.0.1#53 in 3 ms Trying "startpage.com" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;startpage.com. IN MX ;; ANSWER SECTION: startpage.com. 2598 IN MX 10 mx2.startmail.com. startpage.com. 2598 IN MX 10 mx1.startmail.com. Received 81 bytes from 192.168.0.1#53 in 1 ms user@sys-net:~$ nslookup www.startpage.com ;; Got SERVFAIL reply from 192.168.0.1, trying next server Server: fd00::(redacted):ee5e Address: fd00::(redacted):ee5e#53 Non-authoritative answer: www.startpage.com canonical name = startpage.com. Name: startpage.com Address: 37.0.87.39 -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/cf58fe9c-c3f8-be3c-42be-1e40fd64b135%40disroot.org.
Re: [qubes-users] Replacing the wpa_supplicant wifi daemon with iwd
On 3/18/21 12:46 PM, haaber wrote: > On 3/3/21 5:19 PM, 'qtpie' via qubes-users wrote: >> Due to mysterious, unsolvable Wifi issues, I decided to replace the >> wpa_supplicant wifi daemon with iwd. > -- snip -- >> $ dnf remove wpa_supplicant >> $ echo -e "[device] \nwifi.backend=iwd" | tee -a >> /etc/NetworkManager/NetworkManager.conf >> $ systemctl enable iwd.service >> $ systemctl start iwd.service > > interesting. I tried that in my debian-minimal-net but I cannot start > iwd with systemctl. Errors similar to here > > https://bbs.archlinux.org/viewtopic.php?id=250220 > > but the proposed "solution" does not work. The thread suggests > > sudo cp /usr/lib/systemd/system/iwd.service /etc/systemd/system/ > > but that file does simply not exist, so I cannot copy it. So I stopped > that experiment for the moment. Maybe @unman has a suggestion for a > well-working debian-based 'minimal' solution without networkmanager > and/or wpa_applicant ? Best, > > For those who want to stick to NetworkManager, II found out that the $ systemctl enable iwd.service $ systemctl start iwd.service from my initial post, should not be necessary and can cause conflict. Because NetworkManager is supposed to handle starting iwd, after iwd is added to the NetworkManager config file. That networkmanager does not handle iwd correctly, is a known issue with NetworkManager. We can only wait for it to get updated with future Fedora releases I guess. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/101 I am now also curious about non-networkmanager alternatives and their usability though. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/73c466a3-2c9e-6227-343b-be8197d2b618%40disroot.org.
[qubes-users] Replacing the wpa_supplicant wifi daemon with iwd
Hi, Due to mysterious, unsolvable Wifi issues, I decided to replace the wpa_supplicant wifi daemon with iwd. iwd itself is excellent and a definite improvement over wpa_supplicant. I can't find Fedora working on this though. In the Fedora 33 template, it currently comes down to: $ dnf remove wpa_supplicant $ echo -e "[device] \nwifi.backend=iwd" | tee -a /etc/NetworkManager/NetworkManager.conf $ systemctl enable iwd.service $ systemctl start iwd.service $ systemctl restart NetworkManager There are just two integration issues remaining that I hope people can help me with. I am using the standard Qubes Fedora template, and want to stay as close to it as possible, so I'm not interested in ditching NetworkManager unless it is unavoidable. 1. /etc/dbus-1/system.d/org.freedesktop.GeoClue2.conf: this is the only other file in /etc/ that mentions wpa_supplicant. It contains policy to allow wpa_supplicant to be used for geolocation. Since I don't care for geolocation, I just removed it (don't comment it out. But if someone cares to adapt this to iwd, it would be nice. 2. Occasionally, NetworkManager says 'device not ready' under wifi, and wifi stops working. It is solved temporarily by ``$ systemctl restart iwd.service && systemctl restart NetworkManager.service`` in sys-net. I don't get from the log what the exact issue is though. -- Resources: - I used this howto from Josh Stoik as a starter: https://blobfolio.com/2019/replacing-wpa-supplicant-with-iwd-in-ubuntu-eoan/ - https://wiki.archlinux.org/index.php/Iwd GeoClue2 policy: -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a92da205-6c3d-5ae7-3a9e-78ad19cefaaa%40disroot.org.
[qubes-users] Re: issues with i3, xrandr and keyboard
On 1/19/21 6:27 PM, qtpie wrote: > Also, how do you change your keyboard settings under i3/Fedora/Qubes? I > want to use the us-altgr-intl keymap. Under i3 when I do $ localectl > set-keymap us-altgr-intl in a qube vm terminal, this has no effect in > applications. The right alt key instead remains used to open menu's > (altgr+f for File, altgr+e for Edit, etc.) If I could use altgr-intl and > retain that functionality that would actually be great. To answer my own question for other peoples reference: in i3 the way to change the keyboard layout is basically suggested in the qubes faq, but you really have to dig into the workings of localectl and keyboard configuration in general. I ended up doing in dom0: $ localectl set-x11-keymap us pc105 altgr-intl compose:ralt $ localeclt status localectl howto: https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/basic-system-configuration/System_Locale_and_Keyboard_Configuration/#s2-Setting_the_Keymap List of possible keyboard options. This page is about setxkbmap, do not actually use setxkbmap (I've tried), but these options are generic: https://gist.github.com/jatcwang/ae3b7019f219b8cdc6798329108c9aee https://www.qubes-os.org/faq/#my-keyboard-layout-settings-are-not-behaving-correctly-what-should-i-do -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e4197a36-2fcf-a5f7-369a-00933864877d%40disroot.org.
Re: [qubes-users] issues with i3, xrandr and keyboard
On 1/20/21 12:32 PM, Patrik Hagara wrote: >> I'm using the i3 window manager with Qubes in a multi-monitor setup. The >> laptop monitor is 1920x1080, the external monitor is 2560x1440. To >> enable the second monitor I do $ xrandr --output eDP1 --auto --right-of >> DP1 --output DP1 --auto. >> >> The issue I keep running in to is that about half of the time, my mouse >> will not work on the the external monitor on the rightmost quarter and >> lowest quarter (approximately). The pointer will move there, but clicks >> are not registered. It is as if the mousedriver sees the second monitor >> as 1920x1080 instead of its actual resolution. The status bar is >> displayed on both monitors. > > Hi, > > This can be fixed by increasing the dom0 Qubes GUI video memory [1]. > > [1] > https://www.qubes-os.org/doc/gui-configuration/#video-ram-adjustment-for-high-resolution-displays > > > Cheers, > Patrik > Patrik, Thanks for this excellent answer, an immediate fix! Dual monitors now seem to work flawlessly withouth having to use any fancy xrandr options. I will at some point propose an update to the qubes-i3 documentation with this addition among others. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/611f5eda-a594-0de7-2e9f-6644e4fe0ef4%40disroot.org.
[qubes-users] issues with i3, xrandr and keyboard
Hi, A few questions about using Qubes with i3. I think the idea behind i3 is great, but getting everything to work is a bit of a struggle. I'm using the i3 window manager with Qubes in a multi-monitor setup. The laptop monitor is 1920x1080, the external monitor is 2560x1440. To enable the second monitor I do $ xrandr --output eDP1 --auto --right-of DP1 --output DP1 --auto. The issue I keep running in to is that about half of the time, my mouse will not work on the the external monitor on the rightmost quarter and lowest quarter (approximately). The pointer will move there, but clicks are not registered. It is as if the mousedriver sees the second monitor as 1920x1080 instead of its actual resolution. The status bar is displayed on both monitors. I have read much of what there is to read on xrandr and tried many options, like switching monitor postitions, scaling, panning, positioning, but to to avail, the issue keeps returning. I have tried comparing the output of $ xrandr -q, but there is no difference between working and error situations. - Does anyone have a comparable setup and what xrandr command do you use? - Is there an alternative to using xrandr under i3? Also, how do you change your keyboard settings under i3/Fedora/Qubes? I want to use the us-altgr-intl keymap. Under i3 when I do $ localectl set-keymap us-altgr-intl in a qube vm terminal, this has no effect in applications. The right alt key instead remains used to open menu's (altgr+f for File, altgr+e for Edit, etc.) If I could use altgr-intl and retain that functionality that would actually be great. thanks! qtpie -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8705a851-50ff-3cb2-bc2f-bf53d07ef7a2%40disroot.org.
