[Desktop-packages] [Bug 1880405] Re: Unresponsive GUI and journal flooded with: JS ERROR: TypeError: null has no properties _onFocusChanged@resource:///org/gnome/shell/ui/closeDialog.js:135:9
Would be very nice if it will be available in 20.04 ubuntu. Very annoying issue :( -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to mutter in Ubuntu. https://bugs.launchpad.net/bugs/1880405 Title: Unresponsive GUI and journal flooded with: JS ERROR: TypeError: null has no properties _onFocusChanged@resource:///org/gnome/shell/ui/closeDialog.js:135:9 Status in GNOME Shell: Unknown Status in mutter package in Ubuntu: Fix Released Status in mutter source package in Focal: Fix Committed Status in mutter source package in Hirsute: Fix Released Status in mutter package in Debian: Fix Released Bug description: [ Impact ] Shell becomes slow and unresponsive flooding journal with JS errors [ Test case ] 1. Resize the terminal to use half the screen (using CMD+LEFT) 2. switch it to fullscreen (F11) and back (F11) 3. Repeat this some number of times ensure we don't end up in a loop with 100% CPU usage. 4. Ensure that it's still possible to get window focus and the UI is responsive. [ Regression potential ] Events are ignored for windows which are still visible. --- O.k. it is an old Lenovo thinkpad T410. However, in 18.04, 19.04 and 19.10 I did face these problems. The sometimes I have to wait 10 seconds to see if a window reacts or not. It is hard to use. Installiert: 3.36.1-5ubuntu2 Installationskandidat: 3.36.2-1ubuntu1~20.04.1 Versionstabelle: 3.36.2-1ubuntu1~20.04.1 500 500 http://it.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages *** 3.36.1-5ubuntu2 100 100 /var/lib/dpkg/status 3.36.1-5ubuntu1 500 500 http://it.archive.ubuntu.com/ubuntu focal/main amd64 Packages ProblemType: BugDistroRelease: Ubuntu 20.04 Package: gnome-shell 3.36.1-5ubuntu2 ProcVersionSignature: Ubuntu 5.4.0-29.33-generic 5.4.30 Uname: Linux 5.4.0-29-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: GNOME-Classic:GNOME Date: Sun May 24 15:43:34 2020 DisplayManager: gdm3 InstallationDate: Installed on 2020-02-05 (109 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) RelatedPackageVersions: mutter-common 3.36.2-1ubuntu1~20.04.1SourcePackage: gnome-shell UpgradeStatus: Upgraded to focal on 2020-05-08 (15 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell/+bug/1880405/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1726124] Re: DNS domain search paths not updated when VPN started
Still an issue in 20.04 LTS -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1726124 Title: DNS domain search paths not updated when VPN started Status in network-manager package in Ubuntu: Confirmed Status in network-manager-openvpn package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I connect to work with openvpn through network-manager-openvpn. I'm selecting automatic (DHCP) to get an IP address, and "Use this connection only for resources on its network" to support split tunneling. In the last few versions of Ubuntu I used, this all worked fine. In Ubuntu 17.10 (fresh install, not upgrade) I can access hosts on both my VPN network and the internet, BUT I have to use FQDN for my VPN network hosts: the updates to the DNS search path provided by my VPN DHCP server are never being applied. Investigating the system I see that /etc/resolv.conf is pointing to /run/systemd/resolve/stub-resolv.conf and that resolv.conf does not have any of the VPN's search path settings in it: # This file is managed by man:systemd-resolved(8). Do not edit. # # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 127.0.0.53 search home In previous versions of Ubuntu, where NetworkManager controlled the resolver not systemd, /etc/resolv.conf pointed to /run/NetworkManager/resolv.conf and there was a local dnsmasq instance that managed all the complexity. In Ubuntu 17.10 when I look in /run/NetworkManager/resolv.conf file, I see that the search paths ARE properly updated there: $ cat /run/NetworkManager/resolv.conf # Generated by NetworkManager search internal.mycorp.com other.mycorp.com home nameserver 127.0.1.1 However this file isn't being used, and also there's no dnsmasq running on the system so if I switch my /etc/resolv.conf to point to this file instead, then all lookups fail. Strangely, if I look at the systemd-resolv status I see that in theory systemd-resolve does seem to know about the proper search paths: $ systemd-resolve --status ... Link 3 (tun0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 10.3.0.10 10.8.42.2 DNS Domain: ~internal.mycorp.com ~other.mycorp.com but for whatever reason the search domains are not getting put into the resolv.conf file: $ host mydesk ;; connection timed out; no servers could be reached $ host mydesk.internal.mycorp.com mydesk.internal.mycorp.com has address 10.8.37.74 (BTW, the timeout in the failed attempt above takes 10s: it is SUPER frustrating when all your host lookups are taking that long just to fail). ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: systemd 234-2ubuntu12 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: GNOME Date: Sun Oct 22 15:08:57 2017 InstallationDate: Installed on 2017-10-21 (1 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018) MachineType: System manufacturer System Product Name ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.13.0-16-generic root=UUID=4384306c-5fed-4b48-97a6-a6d594c4f72b ro quiet splash vt.handoff=7 SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/02/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 2101 dmi.board.asset.tag: To Be Filled By O.E.M. dmi.board.name: M5A78L-M/USB3 dmi.board.vendor: ASUSTeK Computer INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Asset-1234567890 dmi.chassis.type: 3 dmi.chassis.vendor: Chassis Manufacture dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2101:bd12/02/2014:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnM5A78L-M/USB3:rvrRevX.0x:cvnChassisManufacture:ct3:cvrChassisVersion: dmi.product.family: To Be Filled By O.E.M. dmi.product.name: System Product Name dmi.product.version: System Version dmi.sys.vendor: System manufacturer To manage notifications
[Desktop-packages] [Bug 1688018] Re: DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6
18.04.3 LTS !, still reproduced, which makes me sad. As a workaround: `sudo apt-get install resolvconf-admin` -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1688018 Title: DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6 Status in network-manager package in Ubuntu: Triaged Status in network-manager source package in Xenial: In Progress Status in network-manager source package in Yakkety: Won't Fix Bug description: This was initially opened as #1671606 then later duped to #1639776. Discussion in #1639776 indicate that we need new bug for this so I am opening one ... Please don't mark this as duplicate to #1639776 or other similar bug report. We already lost several months and we are again at beginning ... TL;DR; -> network-manager-1.2.2-0ubuntu0.16.04.4 use DNS defined by VPN (correct). network-manager-1.2.6-0ubuntu0.16.04.1 use DNS from DHCP instead of one defined by VPN (wrong). DNS resolver should query only DNS servers defined by VPN while connection is active. = Test steps / result: - upgraded network-manager to 1.2.6-0ubuntu0.16.04.1 (dnsmasq-base-2.75-1ubuntu0.16.04.2) - restated my laptop to ensure clean start - connected to VPN using openconnect / network-manager-openconnect-gnome Observed results -> DNS queries are forwarded only to DNS servers defined by LAN connection (this is wrong / connection not working at all) - "killall dnsmasq" - dnsmasq get automatically restarted by system Observed results -> most of the the queries are forwarded to DNS servers defined by VPN, but lot of queries get forwarded to DNS servers defined by LAN connection (this is still wrong / DNS leaks, attacker can hijack connection even if VPN is enabled) - I downgraded back network-manager to 1.2.2-0ubuntu0.16.04.4 (dnsmasq-base stay same) - restated my laptop to ensure clean test - connected to same VPN using openconnect Observed results -> DNS queries are forwarded only to DNS servers defined by VPN connection. There are no leaks to LAN DNS server (this is correct behavior). = Paul Smith requested additional details in #1639776. Here are: * If you're using IPv4 vs. IPv6 -> IPv4 only. I have IPv6 set to ignore on all network definition (lan / wifi /vpn) * If you have checked or unchecked the "Use this connection only for resources on its network" -> unchecked on all nw definition * If you have this checked, try unchecking it and see if that makes a difference -> no change if I toggle this option. Behavior is same. * When you say "DNS lookups" please be clear about whether the hostnames being looked up are public (e.g., www.google.com or whatever), on your local LAN, or in the network accessed via the VPN. Does it make a difference which one you choose? -> No difference. * Are you using fully-qualified hostnames, or relying on the DNS domain search path? Does it make a difference if you do it differently? -> I normaly use FQDN due to nature of HTTPs cert validation. I don't see difference when I try same using hostname + domain search. = I am using openconnect (cisco) and openvpn. Test result are by using openconnect but I saw same behaviour also while using openvpn. = Thanks Lukas To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1688018/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1749484] Re: [snap] fail to launch after logging in to a wayland session then back into an X11 session
Same for 18.04 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libreoffice in Ubuntu. https://bugs.launchpad.net/bugs/1749484 Title: [snap] fail to launch after logging in to a wayland session then back into an X11 session Status in libreoffice package in Ubuntu: Confirmed Bug description: My default session is "Ubuntu" (/usr/share/xsessions/ubuntu.desktop). If I log out, then log in to "Ubuntu on Wayland", then out again and in to "Ubuntu" again (so I'm back to my initial session), the libreoffice snap fails to start: osomon@bribon:~$ /snap/bin/libreoffice /snap/libreoffice/49/lib/libreoffice/program/soffice.bin X11 error: Can't open display: Set DISPLAY environment variable, use -display option or check permissions of your X-Server (See "man X" resp. "man xhost" for details) osomon@bribon:~$ env | grep DISPLAY DISPLAY=:0 Rebooting my machine "fixes" the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1749484/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
