[Touch-packages] [Bug 2047447] Re: No valid source.list found while upgrading from mantic to noble
Will do, thanks! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/2047447 Title: No valid source.list found while upgrading from mantic to noble Status in python-apt package in Ubuntu: Fix Released Status in ubuntu-release-upgrader package in Ubuntu: Invalid Status in python-apt source package in Mantic: Confirmed Status in ubuntu-release-upgrader source package in Mantic: Invalid Bug description: Checking package manager Reading package lists... Done Building dependency tree... Done Reading state information... Done Hit http://fr.archive.ubuntu.com/ubuntu mantic InRelease Hit http://fr.archive.ubuntu.com/ubuntu mantic-updates InRelease Hit http://fr.archive.ubuntu.com/ubuntu mantic-security InRelease Hit http://fr.archive.ubuntu.com/ubuntu mantic-backports InRelease Hit https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu lunar InRelease Fetched 0 B in 0s (0 B/s) Reading package lists... Done Building dependency tree... Done Reading state information... Done Checking for installed snaps Calculating snap size requirements Updating repository information No valid sources.list entry found While scanning your repository information no entry about mantic could be found. An upgrade might not succeed. Do you want to continue anyway? Continue [yN] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/2047447/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2047447] Re: No valid source.list found while upgrading from mantic to noble
I can confirm that I have the same issue on two separate 23.10-based systems, but removing vscode.list from /etc/apt/sources.list.d/ has no effect. I get the following warning with "sudo do-release-upgrade -d": Updating repository information No valid sources.list entry found While scanning your repository information no entry about mantic could be found. An upgrade might not succeed. Do you want to continue anyway? Obviously, I don't want to attempt the upgrade if it may bork the system. Any ideas on when this might see a fix? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/2047447 Title: No valid source.list found while upgrading from mantic to noble Status in python-apt package in Ubuntu: Fix Released Status in ubuntu-release-upgrader package in Ubuntu: Invalid Status in python-apt source package in Mantic: Confirmed Status in ubuntu-release-upgrader source package in Mantic: Invalid Bug description: Checking package manager Reading package lists... Done Building dependency tree... Done Reading state information... Done Hit http://fr.archive.ubuntu.com/ubuntu mantic InRelease Hit http://fr.archive.ubuntu.com/ubuntu mantic-updates InRelease Hit http://fr.archive.ubuntu.com/ubuntu mantic-security InRelease Hit http://fr.archive.ubuntu.com/ubuntu mantic-backports InRelease Hit https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu lunar InRelease Fetched 0 B in 0s (0 B/s) Reading package lists... Done Building dependency tree... Done Reading state information... Done Checking for installed snaps Calculating snap size requirements Updating repository information No valid sources.list entry found While scanning your repository information no entry about mantic could be found. An upgrade might not succeed. Do you want to continue anyway? Continue [yN] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/2047447/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1797734] Re: slow calculator startup
Hey, if my assertion incentivizes someone to figure out how to do that, I'm more than willing to admit I was wrong :). The thing is, IMO "fast enough" for a desktop calculator is pretty darn fast. In my opinion the current integrated DEB version is already slow enough to be frustrating, so there's plenty of work in this area without even considering the issue of snaps. People just don't expect to have to wait for a calculator on their computer: isn't calculating the thing that computers were built for and are best at?! I'm not suggesting we should do something like waste users' memory by preloading the calculator app just so it can be ready to display a window quickly, though. In reality probably not enough people use the app often enough to justify that. Cheers! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1797734 Title: slow calculator startup Status in gnome-calculator package in Ubuntu: Confirmed Status in ubuntu-meta package in Ubuntu: New Bug description: The calculator starts very slowly. It's a tiny program, but it runs like a very big one. In previous versions of Ubuntu, the launch was normal, very fast. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gnome-calculator (not installed) ProcVersionSignature: Ubuntu 4.15.0-36.39-generic 4.15.18 Uname: Linux 4.15.0-36-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.20.9-0ubuntu7.4 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Sun Oct 14 08:40:06 2018 InstallationDate: Installed on 2018-05-06 (160 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=ru_RU.UTF-8 SHELL=/bin/bash SourcePackage: gnome-calculator UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-calculator/+bug/1797734/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
Is this going to be fixed in disco? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: New Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: In Progress Status in systemd source package in Bionic: Fix Committed Status in network-manager source package in Cosmic: New Status in systemd source package in Cosmic: Fix Committed Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1778946] Re: No dns resolution after closing a vpn/pptp connection
Although this problem is easy to fix once you know what to do, I don't know if it should be only "Medium" importance because the impact is massive: no DNS is available. If you're not technically inclined enough to know to go poking around /etc/resolv.conf if DNS breaks, you would never be able to figure out what was wrong with your system and you can't search the internet to find a solution... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1778946 Title: No dns resolution after closing a vpn/pptp connection Status in network-manager package in Ubuntu: Confirmed Status in ppp package in Ubuntu: Confirmed Status in resolvconf package in Ubuntu: Confirmed Bug description: step to reproduce set a VPN connection configured to connect a Microsoft vpn server (pptp) internet acces is ok enable the vpn connection using the applet on the top right corner of the desktop internet still ok ping works disable the vpn connection ping doesn't works with a host but works if i specify an ip address ping: xx.net: Nom ou service inconnu As a workaround, i disable the ethernet link and re-enable it name resolution is now ok ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: network-manager 1.10.6-2ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18 Uname: Linux 4.15.0-23-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Jun 27 18:09:30 2018 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2014-06-03 (1484 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) IpRoute: default via 192.168.0.254 dev eth0 proto dhcp metric 20100 169.254.0.0/16 dev eth0 scope link metric 1000 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.47 metric 100 IwConfig: lono wireless extensions. eth0 no wireless extensions. NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true RfKill: SourcePackage: network-manager UpgradeStatus: Upgraded to bionic on 2018-05-10 (48 days ago) nmcli-dev: DEVICE TYPE STATE DBUS-PATH CONNECTION CON-UUID CON-PATH eth0ethernet connected /org/freedesktop/NetworkManager/Devices/2 Connexion filaire 1 94806bba-1c68-46b6-87f4-a3aff6dd /org/freedesktop/NetworkManager/ActiveConnection/6 lo loopback unmanaged /org/freedesktop/NetworkManager/Devices/1 -- ---- nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.10.6 connected (site only) started limited enabled enabled enabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1778946/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1080978] Re: apport forcefully overrides sysctl kernel.core_pattern from values set in /etc/sysctl.*
This is quite frustrating. I wish it would be addressed... somehow... (still getting this problem on 18.04 LTS). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1080978 Title: apport forcefully overrides sysctl kernel.core_pattern from values set in /etc/sysctl.* Status in apport package in Ubuntu: Confirmed Bug description: I think that the way apport registers itself as a core dump handler with the system is badly behaved with respect to other configuration processes one would expect to follow on a Debian or Ubuntu based system. It forcibly overrides settings specified by a user in /etc/sysctl.conf, and does not employ /etc/sysctl.d. Thus it is overriding settings that have been configured elsewhere upon start and upon shutdown. I think perhaps it should be checking for non-default values in these settings and not dynamically playing with them while it starts and stops. Thanks, Matthew. mhall@mhsm:src$ sudo fgrep kernel.core /etc/sysctl.conf kernel.core_pattern = /var/crash/core.%e.%u.%t kernel.core_uses_pid = 1 mhall@mhsm:src$ $ sudo sysctl -a | fgrep -i kernel.core kernel.core_uses_pid = 1 kernel.core_pattern = |/usr/share/apport/apport %p %s %c kernel.core_pipe_limit = 0 $ cat /etc/init/apport.conf ... SNIP ... pre-start script ... SNIP ... echo "|/usr/share/apport/apport %p %s %c" > /proc/sys/kernel/core_pattern ... SNIP ... post-stop script ... SNIP ... if [ "`dd if=/proc/sys/kernel/core_pattern count=1 bs=1 2>/dev/null`" != "|" ] then exit 1 else echo "core" > /proc/sys/kernel/core_pattern fi end script To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1080978/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1726124] Re: DNS domain search paths not updated when VPN started
I'm not sure why it's being asserted that these two uses are mutually incompatible, especially since I've been using them in a coordinated way forever and can still do so (at the expense of junking systemd-resolve and going back to using dnsmasq and a custom configuration, which is obviously a big pain). I've even, in the past, used MULTIPLE VPNs, even at the same time, and it still just works. If the resolver library (e.g., gethostbyname etc.) gets an unqualified hostname, it uses the search path just as it always has including ndots and all that stuff, to generate FQ hostnames. No change there. When the local resolver caching service (dnsmasq, systemd-resolv) gets a FQ hostname it looks through the extensions provided by the VPN DHCP information and if the hostname matches that extension it forwards the lookup to the DNS server for that VPN. If it doesn't match, it doesn't forward the request. If it doesn't match any of the VPN search paths, it forwards the request to the default DNS servers. I honestly don't understand why we're considering these uses incompatible. They seem to me to be exactly compatible and exactly what you want to do, at least the vast majority of the time. -- You received this bug notification because you are a member of Ubuntu Touch seeded 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
[Touch-packages] [Bug 1726124] Re: DNS domain search paths not updated when VPN started
Andreas: unfortunately disallowing short name lookups is not acceptable: many environments use short names in embedded URLs all over the place, and without domain search paths the entire environment is rendered completely unusable (e.g., URLs are simply https://tools/foo or https://wiki/foo or whatever; this means no cross-links work). Connecting to an untrusted VPN is a tiny sliver of a minority of the usage of VPN; 99.99% of the time when someone connects to a VPN they're trying to create a secure link to another trusted network (e.g., working remotely). If you want to provide support for both modes of handling short names with some kind of checkbox to select between them that's fine with me, but the current behavior is a serious loss of functionality from previous solutions. -- You received this bug notification because you are a member of Ubuntu Touch seeded 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: New Status in network-manager-openvpn package in Ubuntu: New Status in systemd package in Ubuntu: New 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
[Touch-packages] [Bug 1726124] Re: DNS domain search paths not updated when VPN started
Hi Sebastien, thanks for your interest. This issue is causing me extreme pain. I believe I'm going to have to reconfigure N-M to use the old-style dnsmasq setup and throw out systemd-resolve pretty soon. It's not clear to me whether this is an N-M bug vs. a systemd bug, but I'm happy to file more bugs. Did you want me to file a bug with N-M? -- You received this bug notification because you are a member of Ubuntu Touch seeded 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: New Status in network-manager-openvpn package in Ubuntu: New Status in systemd package in Ubuntu: New 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:
[Touch-packages] [Bug 1726124] Re: DNS domain search paths not updated when VPN started
I'm not sure I understand what you mean. In a typical configuration you never send "foo" to the nameservice, there's always a search domain and those lookups are always tried first (because the default value for the ndots is 1). This is handled by the libc resolver linked into every program, it's not handled by a central service. I don't have any idea how systemd-resolve works. But, my understanding of how it used to work with dnsmasq using split tunneling was that the nameservice mapped domains to DNS servers, and the resolver would only forward requests to the DNS server that matched the domain for the host being requested. If you have a VPN interface that adds "mycorp.com" to the search domain that appears in /etc/resolv.conf search, so it contains "mycorp.com localdomain" for example. Then when someone tries to resolve "myhost", the libc resolver sees that there are no dots here and so it starts appending search paths to the hostname, in order, and sending them to the DNS service to look up. So first it will send "myhost.mycorp.com" to the resolver. The resolver sees that the hostname ends in "mycorp.com" and it knows that the VPN DNS servers "own" that domain, so it forwards that request to those servers for lookup. If that doesn't match, then the libc resolver will try to look up "myhost.localdomain". That does NOT match the VPN domain, so it will not try to forward that to the DNS servers for the VPN connection and instead use a different resolver. I don't think there's any information leakage here. -- You received this bug notification because you are a member of Ubuntu Touch seeded 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: New Status in network-manager-openvpn package in Ubuntu: New Status in systemd package in Ubuntu: New 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
[Touch-packages] [Bug 1726124] Re: DNS domain search paths not updated when VPN started
To be clear, they are NOT updated in /etc/resolv.conf. They ARE updated in /run/NetworkManager/resolv.conf, but that has no effect since we're not using that for resolution: instead we're using systemd-resolve. And as I noted above, it does appear that systemd-resolve is notified about the search domains, because "systemd-resolve --status" does show them associated with the openvpn tun0 device. However, those search domains are never manifested in the /run/systemd/resolve/stub-resolv.conf which is what /etc/resolv.conf is pointing to, so they never take effect. -- You received this bug notification because you are a member of Ubuntu Touch seeded 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: New Status in network-manager-openvpn package in Ubuntu: New Status in systemd package in Ubuntu: New 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
[Touch-packages] [Bug 1726124] [NEW] DNS domain search paths not updated when VPN started
Public bug reported: 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 ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug artful -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1726124 Title: DNS domain search paths not updated when VPN started Status in systemd package in Ubuntu: New 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
[Touch-packages] [Bug 1639776] Re: name resolution (dnsmasq) fails to send queries out after suspend/resume reconnects the interface
Yes, that version is OK (I'm on 16.10 so mine is a bit newer). If you
check /usr/share/doc/dnsmasq-base/changelog.Debian.gz on your system you
should see info related to this bug in that changelog.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1639776
Title:
name resolution (dnsmasq) fails to send queries out after
suspend/resume reconnects the interface
Status in dnsmasq package in Ubuntu:
Fix Released
Status in network-manager package in Ubuntu:
Invalid
Status in dnsmasq source package in Xenial:
Fix Released
Status in network-manager source package in Xenial:
Invalid
Status in dnsmasq source package in Yakkety:
Fix Released
Status in network-manager source package in Yakkety:
Invalid
Status in dnsmasq package in Debian:
Fix Released
Bug description:
[Impact]
* suspend/resume (which involves disconnection of network devices)
leads to dnsmasq failures.
[Test Case]
* suspend/resume on 16.04 or 16.10 when using dnsmasq, and see
failures upon resume.
[Regression Potential]
* The fix was NMU'd in Debian in the version immediately after
16.10's. I believe the regression potential is very low as this is a
clear bug-fix from upstream.
---
Failure is caused by ENODEV return for all dns queries like:
sendto(11, "\232\325\1\0\0\1\0\0\0\0\0\0\4mail\6google\3com\0\0\1\0"..., 33,
0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("62.241.198.245")}, 16) = -1 ENODEV (No such device)
Problem is reported and fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=1367772
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=2675f2061525bc954be14988d64384b74aa7bf8b
I didn't yet test if applying that patch to ubuntu package works. I
will try the patch in a few hours.
ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: dnsmasq-base 2.76-4
ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0
Uname: Linux 4.8.0-26-generic x86_64
ApportVersion: 2.20.3-0ubuntu8
Architecture: amd64
CurrentDesktop: GNOME
Date: Mon Nov 7 14:11:51 2016
InstallationDate: Installed on 2037-12-25 (-7718 days ago)
InstallationMedia: Lubuntu 16.04 LTS "Xenial Xerus" - Release amd64
(20160420.1)
SourcePackage: dnsmasq
UpgradeStatus: Upgraded to yakkety on 2016-10-21 (16 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1639776/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1639776] Re: name resolution (dnsmasq) fails to send queries out after suspend/resume reconnects the interface
Shawn B it sounds like your issue might be related to this one, since
it's fixed by restarting dnsmasq. Do you have the newer dnsmasq version
(you need dnsmasq-base 2.76-4ubuntu0.1 or better)?
Just to note: it's definitely true that this bug will impact VPN users;
that's how I ran into it. Basically, anything that causes changes to
DNS configuration will hit this: so starting / stopping VPN and also
suspend / resume.
However, if your problem is solved by switching versions of
NetworkManager then it's not this bug. Also if the problem is NOT
solved by restarting dnsmasq then it's not this bug.
In general, the above version of dnsmasq definitely fixes _this_ bug, so
if you have that version and you're still seeing problems then it's not
_this_ bug. You should file a new issue in Launchpad, with all the
details you can obtain.
Feel free to add a comment here with a link to the bug you create so
people can follow it if they come here first.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1639776
Title:
name resolution (dnsmasq) fails to send queries out after
suspend/resume reconnects the interface
Status in dnsmasq package in Ubuntu:
Fix Released
Status in network-manager package in Ubuntu:
Invalid
Status in dnsmasq source package in Xenial:
Fix Released
Status in network-manager source package in Xenial:
Invalid
Status in dnsmasq source package in Yakkety:
Fix Released
Status in network-manager source package in Yakkety:
Invalid
Status in dnsmasq package in Debian:
Fix Released
Bug description:
[Impact]
* suspend/resume (which involves disconnection of network devices)
leads to dnsmasq failures.
[Test Case]
* suspend/resume on 16.04 or 16.10 when using dnsmasq, and see
failures upon resume.
[Regression Potential]
* The fix was NMU'd in Debian in the version immediately after
16.10's. I believe the regression potential is very low as this is a
clear bug-fix from upstream.
---
Failure is caused by ENODEV return for all dns queries like:
sendto(11, "\232\325\1\0\0\1\0\0\0\0\0\0\4mail\6google\3com\0\0\1\0"..., 33,
0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("62.241.198.245")}, 16) = -1 ENODEV (No such device)
Problem is reported and fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=1367772
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=2675f2061525bc954be14988d64384b74aa7bf8b
I didn't yet test if applying that patch to ubuntu package works. I
will try the patch in a few hours.
ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: dnsmasq-base 2.76-4
ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0
Uname: Linux 4.8.0-26-generic x86_64
ApportVersion: 2.20.3-0ubuntu8
Architecture: amd64
CurrentDesktop: GNOME
Date: Mon Nov 7 14:11:51 2016
InstallationDate: Installed on 2037-12-25 (-7718 days ago)
InstallationMedia: Lubuntu 16.04 LTS "Xenial Xerus" - Release amd64
(20160420.1)
SourcePackage: dnsmasq
UpgradeStatus: Upgraded to yakkety on 2016-10-21 (16 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1639776/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1639776] Re: name resolution (dnsmasq) fails to send queries out after suspend/resume reconnects the interface
It sounds like a different bug to me, if changing networkmanager fixes
it without changing dnsmasq. I would file a new Launchpad bug with all
the details you can provide. You can add a comment to this issue with a
link.
In particular, please specify:
* If you're using IPv4 vs. IPv6
* If you have checked or unchecked the "Use this connection only for resources
on its network"
* If you have this checked, try unchecking it and see if that makes a difference
* 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?
* Are you using fully-qualified hostnames, or relying on the DNS domain search
path? Does it make a difference if you do it differently?
FYI, if you choose "Use this connection only for resources on its
network" then different DNS lookups going to different servers is
expected: the decision is made based on the DNS domain name; lookups for
hosts with domains that are served via the VPN (as determined by
information obtained from the DHCP response when you got an IP address
over the VPN) will be sent to DNS servers in the VPN (again, based on
DHCP). Lookups for hosts with domains that are not registered by the
VPN will not be sent to the VPN's DNS server.
I assume (but have not tried) that if you don't check that box then all
DNS lookups would go to the VPN DNS servers. However, this does mean
that no local LAN hostnames can be resolved since your local DNS server
will not be consulted. It also means if you have multiple VPN
connections going, only one of them will have DNS available.
If you either use fully-qualified hostnames, and/or you ensure that the
VPN's DNS domains come first in the search path, then I don't think
there should be a security issue (unless you don't trust your normal DNS
server, but that's an entirely different situation).
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1639776
Title:
name resolution (dnsmasq) fails to send queries out after
suspend/resume reconnects the interface
Status in dnsmasq package in Ubuntu:
Fix Released
Status in network-manager package in Ubuntu:
Invalid
Status in dnsmasq source package in Xenial:
Fix Released
Status in network-manager source package in Xenial:
Invalid
Status in dnsmasq source package in Yakkety:
Fix Released
Status in network-manager source package in Yakkety:
Invalid
Status in dnsmasq package in Debian:
Fix Released
Bug description:
[Impact]
* suspend/resume (which involves disconnection of network devices)
leads to dnsmasq failures.
[Test Case]
* suspend/resume on 16.04 or 16.10 when using dnsmasq, and see
failures upon resume.
[Regression Potential]
* The fix was NMU'd in Debian in the version immediately after
16.10's. I believe the regression potential is very low as this is a
clear bug-fix from upstream.
---
Failure is caused by ENODEV return for all dns queries like:
sendto(11, "\232\325\1\0\0\1\0\0\0\0\0\0\4mail\6google\3com\0\0\1\0"..., 33,
0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("62.241.198.245")}, 16) = -1 ENODEV (No such device)
Problem is reported and fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=1367772
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=2675f2061525bc954be14988d64384b74aa7bf8b
I didn't yet test if applying that patch to ubuntu package works. I
will try the patch in a few hours.
ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: dnsmasq-base 2.76-4
ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0
Uname: Linux 4.8.0-26-generic x86_64
ApportVersion: 2.20.3-0ubuntu8
Architecture: amd64
CurrentDesktop: GNOME
Date: Mon Nov 7 14:11:51 2016
InstallationDate: Installed on 2037-12-25 (-7718 days ago)
InstallationMedia: Lubuntu 16.04 LTS "Xenial Xerus" - Release amd64
(20160420.1)
SourcePackage: dnsmasq
UpgradeStatus: Upgraded to yakkety on 2016-10-21 (16 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1639776/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1639776] Re: name resolution (dnsmasq) fails to send queries out after suspend/resume reconnects the interface
I think the problems being reported by NJ and Lukas at least, are
different issues and you should file a new report about them. I can't
say about GammaPoint because the description there ("DNS leaks") is not
understandable to me.
This issue has the following characteristics: DNS lookups fail, often
with an error of REFUSED. Restarting dnsmasq and/or "pkill -HUP
NetworkManager" fixes the problem.
If your issue doesn't meet those characteristics (particularly if it
isn't fixed by restarting dnsmasq or sending SIGHUP to NetworkManager to
restart it) then it's probably not this bug and you should open a new
bug.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1639776
Title:
name resolution (dnsmasq) fails to send queries out after
suspend/resume reconnects the interface
Status in dnsmasq package in Ubuntu:
Fix Released
Status in network-manager package in Ubuntu:
Invalid
Status in dnsmasq source package in Xenial:
Fix Released
Status in network-manager source package in Xenial:
Invalid
Status in dnsmasq source package in Yakkety:
Fix Released
Status in network-manager source package in Yakkety:
Invalid
Status in dnsmasq package in Debian:
Fix Released
Bug description:
[Impact]
* suspend/resume (which involves disconnection of network devices)
leads to dnsmasq failures.
[Test Case]
* suspend/resume on 16.04 or 16.10 when using dnsmasq, and see
failures upon resume.
[Regression Potential]
* The fix was NMU'd in Debian in the version immediately after
16.10's. I believe the regression potential is very low as this is a
clear bug-fix from upstream.
---
Failure is caused by ENODEV return for all dns queries like:
sendto(11, "\232\325\1\0\0\1\0\0\0\0\0\0\4mail\6google\3com\0\0\1\0"..., 33,
0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("62.241.198.245")}, 16) = -1 ENODEV (No such device)
Problem is reported and fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=1367772
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=2675f2061525bc954be14988d64384b74aa7bf8b
I didn't yet test if applying that patch to ubuntu package works. I
will try the patch in a few hours.
ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: dnsmasq-base 2.76-4
ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0
Uname: Linux 4.8.0-26-generic x86_64
ApportVersion: 2.20.3-0ubuntu8
Architecture: amd64
CurrentDesktop: GNOME
Date: Mon Nov 7 14:11:51 2016
InstallationDate: Installed on 2037-12-25 (-7718 days ago)
InstallationMedia: Lubuntu 16.04 LTS "Xenial Xerus" - Release amd64
(20160420.1)
SourcePackage: dnsmasq
UpgradeStatus: Upgraded to yakkety on 2016-10-21 (16 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1639776/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1639776] Re: name resolution (dnsmasq) fails to send queries out after suspend/resume reconnects the interface
Just curious if there's more work needed here before this fix moves out
of proposed and into standard updates for xenial / yakkety, or if not
then is there a timeline when that transition is normally expected?
I'm currently recommending to users that they reset NetworkManager by
hand when they have a DNS error: once this package makes it into the
normal update queue then I can just tell them to update their systems.
Thanks!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1639776
Title:
name resolution (dnsmasq) fails to send queries out after
suspend/resume reconnects the interface
Status in dnsmasq package in Ubuntu:
Fix Released
Status in network-manager package in Ubuntu:
Invalid
Status in dnsmasq source package in Xenial:
Fix Committed
Status in network-manager source package in Xenial:
Invalid
Status in dnsmasq source package in Yakkety:
Fix Committed
Status in network-manager source package in Yakkety:
Invalid
Status in dnsmasq package in Debian:
Fix Released
Bug description:
[Impact]
* suspend/resume (which involves disconnection of network devices)
leads to dnsmasq failures.
[Test Case]
* suspend/resume on 16.04 or 16.10 when using dnsmasq, and see
failures upon resume.
[Regression Potential]
* The fix was NMU'd in Debian in the version immediately after
16.10's. I believe the regression potential is very low as this is a
clear bug-fix from upstream.
---
Failure is caused by ENODEV return for all dns queries like:
sendto(11, "\232\325\1\0\0\1\0\0\0\0\0\0\4mail\6google\3com\0\0\1\0"..., 33,
0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("62.241.198.245")}, 16) = -1 ENODEV (No such device)
Problem is reported and fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=1367772
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=2675f2061525bc954be14988d64384b74aa7bf8b
I didn't yet test if applying that patch to ubuntu package works. I
will try the patch in a few hours.
ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: dnsmasq-base 2.76-4
ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0
Uname: Linux 4.8.0-26-generic x86_64
ApportVersion: 2.20.3-0ubuntu8
Architecture: amd64
CurrentDesktop: GNOME
Date: Mon Nov 7 14:11:51 2016
InstallationDate: Installed on 2037-12-25 (-7718 days ago)
InstallationMedia: Lubuntu 16.04 LTS "Xenial Xerus" - Release amd64
(20160420.1)
SourcePackage: dnsmasq
UpgradeStatus: Upgraded to yakkety on 2016-10-21 (16 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1639776/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1639776] Re: dnsmasq fails to send queries out after suspend disconnects the interface
Just to add a note: this issue also occurs when using VPNs: I use
NetworkManager OpenVPN and when I start up the connection I can't
resolve DNS hosts from the VPN DNS server until I run "sudo killall -HUP
NetworkManager" or similar. This has to be done every time the VPN goes
down / comes back up.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1639776
Title:
dnsmasq fails to send queries out after suspend disconnects the
interface
Status in dnsmasq package in Ubuntu:
Fix Released
Status in dnsmasq source package in Xenial:
In Progress
Status in dnsmasq source package in Yakkety:
In Progress
Status in dnsmasq package in Debian:
Fix Released
Bug description:
[Impact]
* suspend/resume (which involves disconnection of network devices)
leads to dnsmasq failures.
[Test Case]
* suspend/resume on 16.04 or 16.10 when using dnsmasq, and see
failures upon resume.
[Regression Potential]
* The fix was NMU'd in Debian in the version immediately after
16.10's. I believe the regression potential is very low as this is a
clear bug-fix from upstream.
---
Failure is caused by ENODEV return for all dns queries like:
sendto(11, "\232\325\1\0\0\1\0\0\0\0\0\0\4mail\6google\3com\0\0\1\0"..., 33,
0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("62.241.198.245")}, 16) = -1 ENODEV (No such device)
Problem is reported and fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=1367772
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=2675f2061525bc954be14988d64384b74aa7bf8b
I didn't yet test if applying that patch to ubuntu package works. I
will try the patch in a few hours.
ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: dnsmasq-base 2.76-4
ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0
Uname: Linux 4.8.0-26-generic x86_64
ApportVersion: 2.20.3-0ubuntu8
Architecture: amd64
CurrentDesktop: GNOME
Date: Mon Nov 7 14:11:51 2016
InstallationDate: Installed on 2037-12-25 (-7718 days ago)
InstallationMedia: Lubuntu 16.04 LTS "Xenial Xerus" - Release amd64
(20160420.1)
SourcePackage: dnsmasq
UpgradeStatus: Upgraded to yakkety on 2016-10-21 (16 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1639776/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1676597] [NEW] dnsmasq doesn't manage destruction/recreation of tun interface
Public bug reported: This issue happens in Ubuntu 16.04 LTS as well. When I connect via tun to an OpenVPN server, my DNS lookups do not succeed even though the OpenVPN service is started correctly and does provide the correct information. If I force NetworkManager to load its configuration via "killall -HUP NetworkManager" then it works. $ host git.my.domain.com Host git.my.domain.com not found: 5(REFUSED) $ sudo killall -HUP NetworkManager $ host git git.my.domain.com has address 192.168.1.7 Looking around I see that this appears to be an instance of this bug, in dnsmasq: https://bugzilla.redhat.com/show_bug.cgi?id=1367772 There are TWO patches (already applied to the dnsmasq source and queued for the next release, which is not out yet) needed to fix this problem, both mentioned in the above bug: http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=2675f2061525bc954be14988d64384b74aa7bf8b http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=16800ea072dd0cdf14d951c4bb8d2808b3dfe53d ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: dnsmasq-base 2.76-4 ProcVersionSignature: Ubuntu 4.8.0-41.44-generic 4.8.17 Uname: Linux 4.8.0-41-generic x86_64 ApportVersion: 2.20.3-0ubuntu8.2 Architecture: amd64 CurrentDesktop: GNOME Date: Mon Mar 27 16:00:03 2017 InstallationDate: Installed on 2014-04-28 (1064 days ago) InstallationMedia: Ubuntu-GNOME 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.2) SourcePackage: dnsmasq UpgradeStatus: Upgraded to yakkety on 2017-03-25 (1 days ago) ** Affects: dnsmasq (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug yakkety -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1676597 Title: dnsmasq doesn't manage destruction/recreation of tun interface Status in dnsmasq package in Ubuntu: New Bug description: This issue happens in Ubuntu 16.04 LTS as well. When I connect via tun to an OpenVPN server, my DNS lookups do not succeed even though the OpenVPN service is started correctly and does provide the correct information. If I force NetworkManager to load its configuration via "killall -HUP NetworkManager" then it works. $ host git.my.domain.com Host git.my.domain.com not found: 5(REFUSED) $ sudo killall -HUP NetworkManager $ host git git.my.domain.com has address 192.168.1.7 Looking around I see that this appears to be an instance of this bug, in dnsmasq: https://bugzilla.redhat.com/show_bug.cgi?id=1367772 There are TWO patches (already applied to the dnsmasq source and queued for the next release, which is not out yet) needed to fix this problem, both mentioned in the above bug: http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=2675f2061525bc954be14988d64384b74aa7bf8b http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=16800ea072dd0cdf14d951c4bb8d2808b3dfe53d ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: dnsmasq-base 2.76-4 ProcVersionSignature: Ubuntu 4.8.0-41.44-generic 4.8.17 Uname: Linux 4.8.0-41-generic x86_64 ApportVersion: 2.20.3-0ubuntu8.2 Architecture: amd64 CurrentDesktop: GNOME Date: Mon Mar 27 16:00:03 2017 InstallationDate: Installed on 2014-04-28 (1064 days ago) InstallationMedia: Ubuntu-GNOME 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.2) SourcePackage: dnsmasq UpgradeStatus: Upgraded to yakkety on 2017-03-25 (1 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1676597/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1658921] Re: NetworkManager does not manage wired connection
Just want to point out that "chroot installs" or netboot installs are NOT the only places this breaks. I did a a straightforward upgrade (via do-release-upgrade) from Ubuntu GNOME 16.04.n (latest packages installed) to Ubuntu GNOME 16.10, on a standard desktop system where the wired network was managed by NM before. After the upgrade, no wired interface was available. Luckily my desktop also has a wireless interface (which I never used before); that still worked so I could continue to search for help: it took two days on and off but I finally found this bug (I was searching NetworkManager documentation and looking through nmcli output, journalctl output, etc. but there is nothing shown anywhere about this; most likely NM should be modified so that it prints something useful to the logs if it skips interfaces due to the unmanaged-devices setting). The solution above (replacing with an empty file) then running "sudo killall -HUP NetworkManager" caused my wired connection to immediately reappear and connect. In any event, this change is kind of a disaster; regardless of the intentions behind it the results are far too disruptive and the reasons for the problem and the solution are far too obscure and difficult for the average desktop user to be expected to figure out. This change should be reverted until some alternative solution that is more carefully targeted to only impact the correct set of systems can be devised and implemented. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1658921 Title: NetworkManager does not manage wired connection Status in network-manager package in Ubuntu: Confirmed Bug description: NetworkManager does not manage my wired eth0 connection, no matter how I set /etc/network/interfaces or /etc/NetworkManager/NetworkManager.conf Using ubuntu 16.04, /etc/network/interfaces only managed lo, and [ifupdown] section of NetworkManager.conf had set managed=false. With these same settings, after upgrading to ubuntu 16.10, eth0 appears as unmanaged in nm-applet. If I modify /etc/network/interfaces and add auto eth0 iface eth0 inet dhcp And set managed=true in NetworkManager.conf [ifupdown] section, eth0 is still unmanaged despite it does get an IP from DHCP server. This is happening in my five computers (two laptops and three desktops). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1658921/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1476702] Re: Xorg crash when using Spotify client
Updating the BIOS seems to have fixed it: no crashes since then. Thanks for the support! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1476702 Title: Xorg crash when using Spotify client Status in xorg package in Ubuntu: Expired Bug description: Ever since I upgraded from Ubuntu GNOME 14.04 to Ubuntu GNOME 15.04, I've had my entire desktop crash relatively quickly when using Spotify, if I mess around with the client much. Just starting the client is no problem, and it plays songs OK, but for a while whenever I clicked one of my playlists it would immediately crash. I stopped using the client for a while, but last week started using again and it was working for these simple cases. Today I started the client, picked a playlist, and grabbed the scrollbar and dragged it all the way to the top; as I was dragging my desktop crashed. In my home directory I see a gnome-shell core: (gdb) thr a a bt Thread 2 (Thread 0x7f3da0ebd700 (LWP 16545)): #0 0x7f3db4d3b8dd in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x7f3db5271ebc in g_main_context_iterate (priority=2147483647, n_fds=1, fds=0x7f3d9c0008e0, timeout=-1, context=0x1363e20) at /build/buildd/glib2.0-2.44.1/./glib/gmain.c:4103 #2 0x7f3db5271ebc in g_main_context_iterate (context=context@entry=0x1363e20, block=block@entry=1, dispatch=dispatch@entry=1, self=) at /build/buildd/glib2.0-2.44.1/./glib/gmain.c:3803 #3 0x7f3db5271fcc in g_main_context_iteration (context=0x1363e20, may_block=may_block@entry=1) at /build/buildd/glib2.0-2.44.1/./glib/gmain.c:3869 #4 0x7f3db5272009 in glib_worker_main (data=) at /build/buildd/glib2.0-2.44.1/./glib/gmain.c:5618 #5 0x7f3db5298955 in g_thread_proxy (data=0x1364000) at /build/buildd/glib2.0-2.44.1/./glib/gthread.c:764 #6 0x7f3db50116aa in start_thread (arg=0x7f3da0ebd700) at pthread_create.c:333 #7 0x7f3db4d46eed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 1 (Thread 0x7f3db81a4a40 (LWP 16538)): #0 0x7f3db5278d00 in g_logv (log_domain=0x7f3db6bfc260 "mutter", log_level=G_LOG_LEVEL_ERROR, format=, args=args@entry=0x7ffd6e47ad40) at /build/buildd/glib2.0-2.44.1/./glib/gmessages.c:1046 #1 0x7f3db5278f3f in g_log (log_domain=log_domain@entry=0x7f3db6bfc260 "mutter", log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x7f3db6bf4838 "Unable to initialize Clutter.\n") at /build/buildd/glib2.0-2.44.1/./glib/gmessages.c:1079 #2 0x7f3db6b71a7e in meta_clutter_init () at backends/meta-backend.c:469 #3 0x7f3db6ba1072 in meta_init () at core/main.c:358 #4 0x00401ddb in main (argc=1, argv=0x7ffd6e47b1b8) at main.c:429 but I think this is just a symptom of the X server crashing; in my X session log file (Xorg.0.log.old probably attached below) I see: [939562.032] (EE) [939562.064] (EE) Backtrace: [939562.212] (EE) 0: /usr/bin/X (xorg_backtrace+0x56) [0x7f5a10ef6556] [939562.212] (EE) 1: /usr/bin/X (0x7f5a10d43000+0x1b7749) [0x7f5a10efa749] [939562.212] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (0x7f5a0ea09000+0x352f0) [0x7f5a0ea3e2f0] [939562.212] (EE) 3: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f5a0afe8000+0xfa6c3) [0x7f5a0b0e26c3] [939562.213] (EE) 4: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f5a0afe8000+0x10cf60) [0x7f5a0b0f4f60] [939562.213] (EE) 5: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f5a0afe8000+0x10e3ac) [0x7f5a0b0f63ac] [939562.213] (EE) 6: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f5a0afe8000+0x10f343) [0x7f5a0b0f7343] [939562.213] (EE) 7: /usr/bin/X (DRI2SwapBuffers+0x1d0) [0x7f5a10ec9100] [939562.213] (EE) 8: /usr/bin/X (0x7f5a10d43000+0x187a7c) [0x7f5a10ecaa7c] [939562.213] (EE) 9: /usr/bin/X (0x7f5a10d43000+0x580a7) [0x7f5a10d9b0a7] [939562.213] (EE) 10: /usr/bin/X (0x7f5a10d43000+0x5c29b) [0x7f5a10d9f29b] [939562.213] (EE) 11: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf0) [0x7f5a0ea29a40] [939562.213] (EE) 12: /usr/bin/X (0x7f5a10d43000+0x4662e) [0x7f5a10d8962e] [939562.213] (EE) [939562.215] (EE) Segmentation fault at address 0x7f5a1119b004 [939562.215] (EE) Fatal server error: [939562.215] (EE) Caught signal 11 (Segmentation fault). Server aborting So maybe an issue with the Intel display driver? ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: xorg 1:7.7+7ubuntu4 ProcVersionSignature: Ubuntu 3.19.0-22.22-generic 3.19.8-ckt1 Uname: Linux 3.19.0-22-generic x86_64 .tmp.unity.support.test.0: ApportVersion: 2.17.2-0ubuntu1.1 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: GNOME Date: Tue Jul 21 10:25:08 2015 DistUpgraded: 2015-04-27 12:05:00,462 DEBUG enabling apt cron job DistroCodename:
[Touch-packages] [Bug 1476702] Re: Xorg crash when using Spotify client
OK I've updated my bios: $ sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date 0708 12/25/2012 I used to get crashes just by semi-vigorous scrolling in the Spotify window but a session of clicking and scrolling so far hasn't reproduced the crash. I'll keep trying for a while. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1476702 Title: Xorg crash when using Spotify client Status in xorg package in Ubuntu: Incomplete Bug description: Ever since I upgraded from Ubuntu GNOME 14.04 to Ubuntu GNOME 15.04, I've had my entire desktop crash relatively quickly when using Spotify, if I mess around with the client much. Just starting the client is no problem, and it plays songs OK, but for a while whenever I clicked one of my playlists it would immediately crash. I stopped using the client for a while, but last week started using again and it was working for these simple cases. Today I started the client, picked a playlist, and grabbed the scrollbar and dragged it all the way to the top; as I was dragging my desktop crashed. In my home directory I see a gnome-shell core: (gdb) thr a a bt Thread 2 (Thread 0x7f3da0ebd700 (LWP 16545)): #0 0x7f3db4d3b8dd in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x7f3db5271ebc in g_main_context_iterate (priority=2147483647, n_fds=1, fds=0x7f3d9c0008e0, timeout=-1, context=0x1363e20) at /build/buildd/glib2.0-2.44.1/./glib/gmain.c:4103 #2 0x7f3db5271ebc in g_main_context_iterate (context=context@entry=0x1363e20, block=block@entry=1, dispatch=dispatch@entry=1, self=) at /build/buildd/glib2.0-2.44.1/./glib/gmain.c:3803 #3 0x7f3db5271fcc in g_main_context_iteration (context=0x1363e20, may_block=may_block@entry=1) at /build/buildd/glib2.0-2.44.1/./glib/gmain.c:3869 #4 0x7f3db5272009 in glib_worker_main (data=) at /build/buildd/glib2.0-2.44.1/./glib/gmain.c:5618 #5 0x7f3db5298955 in g_thread_proxy (data=0x1364000) at /build/buildd/glib2.0-2.44.1/./glib/gthread.c:764 #6 0x7f3db50116aa in start_thread (arg=0x7f3da0ebd700) at pthread_create.c:333 #7 0x7f3db4d46eed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 1 (Thread 0x7f3db81a4a40 (LWP 16538)): #0 0x7f3db5278d00 in g_logv (log_domain=0x7f3db6bfc260 "mutter", log_level=G_LOG_LEVEL_ERROR, format=, args=args@entry=0x7ffd6e47ad40) at /build/buildd/glib2.0-2.44.1/./glib/gmessages.c:1046 #1 0x7f3db5278f3f in g_log (log_domain=log_domain@entry=0x7f3db6bfc260 "mutter", log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x7f3db6bf4838 "Unable to initialize Clutter.\n") at /build/buildd/glib2.0-2.44.1/./glib/gmessages.c:1079 #2 0x7f3db6b71a7e in meta_clutter_init () at backends/meta-backend.c:469 #3 0x7f3db6ba1072 in meta_init () at core/main.c:358 #4 0x00401ddb in main (argc=1, argv=0x7ffd6e47b1b8) at main.c:429 but I think this is just a symptom of the X server crashing; in my X session log file (Xorg.0.log.old probably attached below) I see: [939562.032] (EE) [939562.064] (EE) Backtrace: [939562.212] (EE) 0: /usr/bin/X (xorg_backtrace+0x56) [0x7f5a10ef6556] [939562.212] (EE) 1: /usr/bin/X (0x7f5a10d43000+0x1b7749) [0x7f5a10efa749] [939562.212] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (0x7f5a0ea09000+0x352f0) [0x7f5a0ea3e2f0] [939562.212] (EE) 3: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f5a0afe8000+0xfa6c3) [0x7f5a0b0e26c3] [939562.213] (EE) 4: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f5a0afe8000+0x10cf60) [0x7f5a0b0f4f60] [939562.213] (EE) 5: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f5a0afe8000+0x10e3ac) [0x7f5a0b0f63ac] [939562.213] (EE) 6: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f5a0afe8000+0x10f343) [0x7f5a0b0f7343] [939562.213] (EE) 7: /usr/bin/X (DRI2SwapBuffers+0x1d0) [0x7f5a10ec9100] [939562.213] (EE) 8: /usr/bin/X (0x7f5a10d43000+0x187a7c) [0x7f5a10ecaa7c] [939562.213] (EE) 9: /usr/bin/X (0x7f5a10d43000+0x580a7) [0x7f5a10d9b0a7] [939562.213] (EE) 10: /usr/bin/X (0x7f5a10d43000+0x5c29b) [0x7f5a10d9f29b] [939562.213] (EE) 11: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf0) [0x7f5a0ea29a40] [939562.213] (EE) 12: /usr/bin/X (0x7f5a10d43000+0x4662e) [0x7f5a10d8962e] [939562.213] (EE) [939562.215] (EE) Segmentation fault at address 0x7f5a1119b004 [939562.215] (EE) Fatal server error: [939562.215] (EE) Caught signal 11 (Segmentation fault). Server aborting So maybe an issue with the Intel display driver? ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: xorg 1:7.7+7ubuntu4 ProcVersionSignature: Ubuntu 3.19.0-22.22-generic 3.19.8-ckt1 Uname: Linux 3.19.0-22-generic x86_64 .tmp.unity.support.test.0: ApportVersion: 2.17.2-0ubuntu1.1 Architecture: amd64 CompizPlugins: No value set for
[Touch-packages] [Bug 1476702] [NEW] Xorg crash when using Spotify client
Public bug reported: Ever since I upgraded from Ubuntu GNOME 14.04 to Ubuntu GNOME 15.04, I've had my entire desktop crash relatively quickly when using Spotify, if I mess around with the client much. Just starting the client is no problem, and it plays songs OK, but for a while whenever I clicked one of my playlists it would immediately crash. I stopped using the client for a while, but last week started using again and it was working for these simple cases. Today I started the client, picked a playlist, and grabbed the scrollbar and dragged it all the way to the top; as I was dragging my desktop crashed. In my home directory I see a gnome-shell core: (gdb) thr a a bt Thread 2 (Thread 0x7f3da0ebd700 (LWP 16545)): #0 0x7f3db4d3b8dd in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x7f3db5271ebc in g_main_context_iterate (priority=2147483647, n_fds=1, fds=0x7f3d9c0008e0, timeout=-1, context=0x1363e20) at /build/buildd/glib2.0-2.44.1/./glib/gmain.c:4103 #2 0x7f3db5271ebc in g_main_context_iterate (context=context@entry=0x1363e20, block=block@entry=1, dispatch=dispatch@entry=1, self=optimized out) at /build/buildd/glib2.0-2.44.1/./glib/gmain.c:3803 #3 0x7f3db5271fcc in g_main_context_iteration (context=0x1363e20, may_block=may_block@entry=1) at /build/buildd/glib2.0-2.44.1/./glib/gmain.c:3869 #4 0x7f3db5272009 in glib_worker_main (data=optimized out) at /build/buildd/glib2.0-2.44.1/./glib/gmain.c:5618 #5 0x7f3db5298955 in g_thread_proxy (data=0x1364000) at /build/buildd/glib2.0-2.44.1/./glib/gthread.c:764 #6 0x7f3db50116aa in start_thread (arg=0x7f3da0ebd700) at pthread_create.c:333 #7 0x7f3db4d46eed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 1 (Thread 0x7f3db81a4a40 (LWP 16538)): #0 0x7f3db5278d00 in g_logv (log_domain=0x7f3db6bfc260 mutter, log_level=G_LOG_LEVEL_ERROR, format=optimized out, args=args@entry=0x7ffd6e47ad40) at /build/buildd/glib2.0-2.44.1/./glib/gmessages.c:1046 #1 0x7f3db5278f3f in g_log (log_domain=log_domain@entry=0x7f3db6bfc260 mutter, log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x7f3db6bf4838 Unable to initialize Clutter.\n) at /build/buildd/glib2.0-2.44.1/./glib/gmessages.c:1079 #2 0x7f3db6b71a7e in meta_clutter_init () at backends/meta-backend.c:469 #3 0x7f3db6ba1072 in meta_init () at core/main.c:358 #4 0x00401ddb in main (argc=1, argv=0x7ffd6e47b1b8) at main.c:429 but I think this is just a symptom of the X server crashing; in my X session log file (Xorg.0.log.old probably attached below) I see: [939562.032] (EE) [939562.064] (EE) Backtrace: [939562.212] (EE) 0: /usr/bin/X (xorg_backtrace+0x56) [0x7f5a10ef6556] [939562.212] (EE) 1: /usr/bin/X (0x7f5a10d43000+0x1b7749) [0x7f5a10efa749] [939562.212] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (0x7f5a0ea09000+0x352f0) [0x7f5a0ea3e2f0] [939562.212] (EE) 3: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f5a0afe8000+0xfa6c3) [0x7f5a0b0e26c3] [939562.213] (EE) 4: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f5a0afe8000+0x10cf60) [0x7f5a0b0f4f60] [939562.213] (EE) 5: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f5a0afe8000+0x10e3ac) [0x7f5a0b0f63ac] [939562.213] (EE) 6: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f5a0afe8000+0x10f343) [0x7f5a0b0f7343] [939562.213] (EE) 7: /usr/bin/X (DRI2SwapBuffers+0x1d0) [0x7f5a10ec9100] [939562.213] (EE) 8: /usr/bin/X (0x7f5a10d43000+0x187a7c) [0x7f5a10ecaa7c] [939562.213] (EE) 9: /usr/bin/X (0x7f5a10d43000+0x580a7) [0x7f5a10d9b0a7] [939562.213] (EE) 10: /usr/bin/X (0x7f5a10d43000+0x5c29b) [0x7f5a10d9f29b] [939562.213] (EE) 11: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf0) [0x7f5a0ea29a40] [939562.213] (EE) 12: /usr/bin/X (0x7f5a10d43000+0x4662e) [0x7f5a10d8962e] [939562.213] (EE) [939562.215] (EE) Segmentation fault at address 0x7f5a1119b004 [939562.215] (EE) Fatal server error: [939562.215] (EE) Caught signal 11 (Segmentation fault). Server aborting So maybe an issue with the Intel display driver? ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: xorg 1:7.7+7ubuntu4 ProcVersionSignature: Ubuntu 3.19.0-22.22-generic 3.19.8-ckt1 Uname: Linux 3.19.0-22-generic x86_64 .tmp.unity.support.test.0: ApportVersion: 2.17.2-0ubuntu1.1 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: GNOME Date: Tue Jul 21 10:25:08 2015 DistUpgraded: 2015-04-27 12:05:00,462 DEBUG enabling apt cron job DistroCodename: vivid DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0162] (rev 09) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. P8 series motherboard [1043:84ca] InstallationDate: Installed on 2014-04-28 (449 days ago) InstallationMedia: Ubuntu-GNOME 14.04 LTS Trusty Tahr - Release amd64 (20140416.2) MachineType: ASUSTeK COMPUTER INC. CM6870
[Touch-packages] [Bug 1378625] [NEW] Failure of nested substring processing inside double-quotes
Public bug reported:
lsb_release -rd:
Description:Ubuntu 14.04.1 LTS
Release:14.04
apt-cache policy dash
dash:
Installed: 0.5.7-4ubuntu1
Candidate: 0.5.7-4ubuntu1
Version table:
*** 0.5.7-4ubuntu1 0
500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
100 /var/lib/dpkg/status
FYI, I reported the bug below on the dash mailing list and got this
response from Herbert Xu:
This is already fixed in the current git tree, by the commit:
commit a7c21a6f4cb42d967854cae954efd4ee66bdea9c
Author: Herbert Xu herb...@gondor.apana.org.au
Date: Fri Aug 23 20:04:12 2013 +1000
[EXPAND] Propagate EXP_QPAT in subevalvar
I checked dash_0.5.8-1_amd64.deb from Debian experimental and this bug
seems to be fixed there as well (but still broken in Debian sid, where
the current version is dash_0.5.7-4_amd64.deb).
--
Hi all. I recently found a bug in dash's handling of substring
processing, when the variable is contained within quotes.
In bash, this works:
bash$ echo $PWD
/home/psmith
bash$ echo ${PWD%${PWD##*/}}.
/home/.
bash$ echo ${PWD%${PWD##*/}}.
/home/.
which is what I expect. However, in dash we get:
dash$ echo $PWD
/home/psmith
dash$ echo ${PWD%${PWD##*/}}.
/home/.
dash$ echo ${PWD%${PWD##*/}}.
.
Whoops! Inside double-quotes dash is mishandling the nested string
substitution. If I break it up into two steps it works OK, regardless
of whether or not it's quoted.
** Affects: dash (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dash in Ubuntu.
https://bugs.launchpad.net/bugs/1378625
Title:
Failure of nested substring processing inside double-quotes
Status in “dash” package in Ubuntu:
New
Bug description:
lsb_release -rd:
Description:Ubuntu 14.04.1 LTS
Release:14.04
apt-cache policy dash
dash:
Installed: 0.5.7-4ubuntu1
Candidate: 0.5.7-4ubuntu1
Version table:
*** 0.5.7-4ubuntu1 0
500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
100 /var/lib/dpkg/status
FYI, I reported the bug below on the dash mailing list and got this
response from Herbert Xu:
This is already fixed in the current git tree, by the commit:
commit a7c21a6f4cb42d967854cae954efd4ee66bdea9c
Author: Herbert Xu herb...@gondor.apana.org.au
Date: Fri Aug 23 20:04:12 2013 +1000
[EXPAND] Propagate EXP_QPAT in subevalvar
I checked dash_0.5.8-1_amd64.deb from Debian experimental and this bug
seems to be fixed there as well (but still broken in Debian sid, where
the current version is dash_0.5.7-4_amd64.deb).
--
Hi all. I recently found a bug in dash's handling of substring
processing, when the variable is contained within quotes.
In bash, this works:
bash$ echo $PWD
/home/psmith
bash$ echo ${PWD%${PWD##*/}}.
/home/.
bash$ echo ${PWD%${PWD##*/}}.
/home/.
which is what I expect. However, in dash we get:
dash$ echo $PWD
/home/psmith
dash$ echo ${PWD%${PWD##*/}}.
/home/.
dash$ echo ${PWD%${PWD##*/}}.
.
Whoops! Inside double-quotes dash is mishandling the nested string
substitution. If I break it up into two steps it works OK, regardless
of whether or not it's quoted.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dash/+bug/1378625/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1365007] [NEW] update-rc.d always throws a warning when enable or disable is used
Public bug reported:
After a lot of puzzling and confusion I've discovered that update-rc.d
has a bug in it, in Ubuntu (I've checked the Debian sid version of this
script and the bug doesn't exist there).
If you run update-rc.d svc enable or update-rc.d svc disable for
any service (with or without extra runlevel arguments) it will always,
if the sysvinit control script in /etc/init.d/svc DOES contain correct
LSB init info settings, throw this warning:
update-rc.d: warning: start runlevel arguments (none) do not match
svc Default-Start values (2 3 4 5)
I thought there was something wrong with my init scripts, but it happens
for all of them. Looking at the implementation of update-
rc.d:cmp_args_with_defaults() it's clear there's a bug in the script
though.
When you run update-rc.d with the enable or disable action and this
function is called, there is an if-statement that tries to operate
differently depending on the action you give and there's no operation
for the actions enable or disable:
if ($act eq 'defaults') {
...
} elsif ($act eq 'start' or $act eq 'stop') {
...
}
As a result of this oversight, the values of @arg_start_lvls and
@arg_stop_lvls are never set to anything and there's no way they can
match the values provided in the LSB init info settings in the init
script and the warning is always printed.
In fact it seems there are a lot of issues with this function and this
script; for example if you give an illegal start command you get this:
$ sudo update-rc.d svc start
update-rc.d: warning: start runlevel arguments (none) do not match svc
Default-Start values (2 3 4 5)
update-rc.d: warning: stop runlevel arguments (none) do not match svc
Default-Stop values (0 1 6)
Use of uninitialized value $argv[1] in pattern match (m//) at
/usr/sbin/update-rc.d line 299.
update-rc.d: error: expected NN after start
usage: update-rc.d [-n] [-f] basename remove
update-rc.d [-n] basename defaults [NN | SS KK]
update-rc.d [-n] basename start|stop NN runlvl [runlvl] [...] .
update-rc.d [-n] basename disable|enable [S|2|3|4|5]
-n: not really
-f: force
which is clearly unpleasant.
** Affects: sysvinit (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sysvinit in Ubuntu.
https://bugs.launchpad.net/bugs/1365007
Title:
update-rc.d always throws a warning when enable or disable is used
Status in “sysvinit” package in Ubuntu:
New
Bug description:
After a lot of puzzling and confusion I've discovered that update-rc.d
has a bug in it, in Ubuntu (I've checked the Debian sid version of
this script and the bug doesn't exist there).
If you run update-rc.d svc enable or update-rc.d svc disable
for any service (with or without extra runlevel arguments) it will
always, if the sysvinit control script in /etc/init.d/svc DOES
contain correct LSB init info settings, throw this warning:
update-rc.d: warning: start runlevel arguments (none) do not match
svc Default-Start values (2 3 4 5)
I thought there was something wrong with my init scripts, but it
happens for all of them. Looking at the implementation of update-
rc.d:cmp_args_with_defaults() it's clear there's a bug in the script
though.
When you run update-rc.d with the enable or disable action and
this function is called, there is an if-statement that tries to
operate differently depending on the action you give and there's no
operation for the actions enable or disable:
if ($act eq 'defaults') {
...
} elsif ($act eq 'start' or $act eq 'stop') {
...
}
As a result of this oversight, the values of @arg_start_lvls and
@arg_stop_lvls are never set to anything and there's no way they can
match the values provided in the LSB init info settings in the init
script and the warning is always printed.
In fact it seems there are a lot of issues with this function and this
script; for example if you give an illegal start command you get
this:
$ sudo update-rc.d svc start
update-rc.d: warning: start runlevel arguments (none) do not match svc
Default-Start values (2 3 4 5)
update-rc.d: warning: stop runlevel arguments (none) do not match svc
Default-Stop values (0 1 6)
Use of uninitialized value $argv[1] in pattern match (m//) at
/usr/sbin/update-rc.d line 299.
update-rc.d: error: expected NN after start
usage: update-rc.d [-n] [-f] basename remove
update-rc.d [-n] basename defaults [NN | SS KK]
update-rc.d [-n] basename start|stop NN runlvl [runlvl] [...] .
update-rc.d [-n] basename disable|enable [S|2|3|4|5]
-n: not really
-f: force
which is clearly unpleasant.
To manage notifications about this bug go to:
