[Touch-packages] [Bug 1531184] Re: [SRU] dnsmasq doesn't start on boot because its interface isn't up yet
Terrence Houlahan's fix also works for me on 18.04 Many 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/1531184 Title: [SRU] dnsmasq doesn't start on boot because its interface isn't up yet Status in One Hundred Papercuts: Confirmed Status in dnsmasq package in Ubuntu: Confirmed Status in dnsmasq package in Debian: New Bug description: [Impact] dnsmasq will fail to respond on network devices that weren't up when its service started, thus not binding as expected. [Test Case] TBD [Regression Potential] The fix is just configuring the order of service startup, so is unlikely to create any regressions. Things to watch would be service related misbehaviors and general availability of the dnsmasq functionality. [Fix] Straightforward packaging fix to the service to make it delay startup until after the network is online. https://bugs.debian.org/cgi- bin/bugreport.cgi?att=1;bug=774970;filename=774970-network- online.debdiff;msg=22 [Discussion] [Original Report] My dnsmasq instance uses "interface=br-vz0" and the interface br-vz0 is managed manually in /etc/network/interfaces. During boot, dnsmasq is started before br-vz0 is created and this causes dnsmasq to exit: Jan 5 08:56:16 simon-laptop dnsmasq[1008]: dnsmasq: unknown interface br-vz0 Jan 5 08:56:16 simon-laptop dnsmasq[1008]: unknown interface br-vz0 Jan 5 08:56:16 simon-laptop dnsmasq[1008]: FAILED to start up Jan 5 08:56:17 simon-laptop NetworkManager[937]: NetworkManager (version 1.0.4) is starting... ... Jan 5 08:56:18 simon-laptop NetworkManager[937]: interface-parser: parsing file /etc/network/interfaces ... Jan 5 08:56:18 simon-laptop NetworkManager[937]: found bridge ports none for br-vz0 Jan 5 08:56:18 simon-laptop NetworkManager[937]: adding bridge port none to eni_ifaces Jan 5 08:56:18 simon-laptop NetworkManager[937]: management mode: unmanaged ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: dnsmasq 2.75-1 ProcVersionSignature: Ubuntu 4.3.0-5.16-generic 4.3.3 Uname: Linux 4.3.0-5-generic x86_64 ApportVersion: 2.19.3-0ubuntu2 Architecture: amd64 CurrentDesktop: Unity Date: Tue Jan 5 09:53:30 2016 PackageArchitecture: all SourcePackage: dnsmasq UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1531184/+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 1511735] Re: libnl: fail to bind() netlink sockets
I should read my post before submitting them. The above fix got me back _online_. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libnl3 in Ubuntu. https://bugs.launchpad.net/bugs/1511735 Title: libnl: fail to bind() netlink sockets Status in libnl3 package in Ubuntu: Fix Released Status in libnl3 source package in Trusty: In Progress Status in libnl3 package in Debian: Fix Released Bug description: [Triage Notes] The proposed fix for this bug in libnl3 caused a regression in trusty- proposed, tracked in bug 1539634. The regression is caused by a latent bug in Network Manager. We expect to fix this by landing a fix for the bug in Network Manager in trusty-updates at the same time as this fix. [Impact] * Applications in Trusty using libnl-3-200 which frequently open and close netlink sockets can easily fail when attempting to bind the local socket. The problem happens when libnl choose a port id already used by another application and subsequently libnl fails instead of trying another port id. The original bug was discovered when attempting to start a virtual machine under libvirt, which is a user of this library. * Backporting fixes from upstream release fixes a real bug in the current version of the library in Trusty. The alternative is for all applications to manually manage their local port allocation, or as upstream has accepted allowing libnl to attempt to try for other local ports. * All patches applied are already accepted upstream and newer Ubuntu releases are not affected. [Test Case] * On a Trusty 14.04 system 1. sudo apt-get install libnl-3-200 libnl-3-dev libnl-3-dev \ libnl-genl-3-dev libnl-route-3-200 \ make gcc build-essential libnl1 2. download and unpack attachment: lp_1511735_test.tar 3. Run testcases: % if ./example.sh; then echo "libnl OK"; else echo "libnl FAILED"; fi gcc -o example -I/usr/include/libnl3 example.c -lnl-3 -lnl-genl-3 set manually the local port to 6975 (pid: 6974) local port has been set by the libnl to 6975 (pid: 6975) ERROR: genl_connect(): Object exists (local port: 6975, pid: 6975) libnl FAILED % python libnl3-test-rh1249158.py a b c d ulimit(NOFILE) = (2048, 4096) Test: PID=6978 TEST (a)... Traceback (most recent call last): File "libnl3-test-rh1249158.py", line 226, in locals()["TEST_" + arg]() File "libnl3-test-rh1249158.py", line 140, in TEST_a sk = nl_get_socket() File "libnl3-test-rh1249158.py", line 115, in nl_get_socket raise IOError(-err, _nl_geterror()) OSError: [Errno 6] b'Unspecific failure' 4. After applying the updated packages: % if ./example.sh; then echo "libnl OK"; else echo "libnl FAILED"; fi gcc -o example -I/usr/include/libnl3 example.c -lnl-3 -lnl-genl-3 set manually the local port to 11295 (pid: 11294) local port has been set by the libnl to 2894081055 (pid: 11295) libnl OK % python libnl3-test-rh1249158.py a b c d ulimit(NOFILE) = (2048, 4096) Test: PID=11296 TEST (a)... ...done TEST (b)... ...done TEST (c)... ...done TEST (d)... ...done [Regression Potential] * There are quite a few high profile packages that depend on this package, notably libvirt and network-manager. The complete list is here: # on Trusty % apt-rdepends -r libnl-3-200 | head -n 33 libnl-3-200 Reverse Depends: batctl (>= 2013.4.0-2) Reverse Depends: bmon (>= 1:3.1-1) Reverse Depends: crda (>= 1.1.2-1ubuntu2) Reverse Depends: hostapd (>= 1:2.1-0ubuntu1) Reverse Depends: ipvsadm (>= 1:1.26-2ubuntu1) Reverse Depends: iw (>= 3.4-1) Reverse Depends: keepalived (>= 1:1.2.7-1ubuntu1) Reverse Depends: kismet (>= 2013.03.R1b-3) Reverse Depends: knemo (>= 0.7.6-2) Reverse Depends: libfsobasics3 (>= 0.12.0-4) Reverse Depends: libnetcf1 (>= 1:0.2.3-4ubuntu1) Reverse Depends: libnl-3-200-dbg (= 3.2.21-1) Reverse Depends: libnl-3-dev (= 3.2.21-1) Reverse Depends: libnl-cli-3-200 (= 3.2.21-1) Reverse Depends: libnl-genl-3-200 (= 3.2.21-1) Reverse Depends: libnl-nf-3-200 (= 3.2.21-1) Reverse Depends: libnl-route-3-200 (= 3.2.21-1) Reverse Depends: libnl-utils (>= 3.2.21-1) Reverse Depends: libnss-gw-name (>= 0.3-2) Reverse Depends: libvirt-bin (>= 1.2.2-0ubuntu13) Reverse Depends: libvirt0 (>= 1.2.2-0ubuntu13) Reverse Depends: lowpan-test-tools (>= 0.3-1) Reverse Depends: lowpan-tools (>= 0.3-1) Reverse Depends: neard (>= 0.11-1) Reverse Depends: neard-tools (>= 0.11-1) Reverse
[Touch-packages] [Bug 1511735] Re: libnl: fail to bind() netlink sockets
This fix got me back one line. https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1581535/comments/13 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libnl3 in Ubuntu. https://bugs.launchpad.net/bugs/1511735 Title: libnl: fail to bind() netlink sockets Status in libnl3 package in Ubuntu: Fix Released Status in libnl3 source package in Trusty: In Progress Status in libnl3 package in Debian: Fix Released Bug description: [Triage Notes] The proposed fix for this bug in libnl3 caused a regression in trusty- proposed, tracked in bug 1539634. The regression is caused by a latent bug in Network Manager. We expect to fix this by landing a fix for the bug in Network Manager in trusty-updates at the same time as this fix. [Impact] * Applications in Trusty using libnl-3-200 which frequently open and close netlink sockets can easily fail when attempting to bind the local socket. The problem happens when libnl choose a port id already used by another application and subsequently libnl fails instead of trying another port id. The original bug was discovered when attempting to start a virtual machine under libvirt, which is a user of this library. * Backporting fixes from upstream release fixes a real bug in the current version of the library in Trusty. The alternative is for all applications to manually manage their local port allocation, or as upstream has accepted allowing libnl to attempt to try for other local ports. * All patches applied are already accepted upstream and newer Ubuntu releases are not affected. [Test Case] * On a Trusty 14.04 system 1. sudo apt-get install libnl-3-200 libnl-3-dev libnl-3-dev \ libnl-genl-3-dev libnl-route-3-200 \ make gcc build-essential libnl1 2. download and unpack attachment: lp_1511735_test.tar 3. Run testcases: % if ./example.sh; then echo "libnl OK"; else echo "libnl FAILED"; fi gcc -o example -I/usr/include/libnl3 example.c -lnl-3 -lnl-genl-3 set manually the local port to 6975 (pid: 6974) local port has been set by the libnl to 6975 (pid: 6975) ERROR: genl_connect(): Object exists (local port: 6975, pid: 6975) libnl FAILED % python libnl3-test-rh1249158.py a b c d ulimit(NOFILE) = (2048, 4096) Test: PID=6978 TEST (a)... Traceback (most recent call last): File "libnl3-test-rh1249158.py", line 226, in locals()["TEST_" + arg]() File "libnl3-test-rh1249158.py", line 140, in TEST_a sk = nl_get_socket() File "libnl3-test-rh1249158.py", line 115, in nl_get_socket raise IOError(-err, _nl_geterror()) OSError: [Errno 6] b'Unspecific failure' 4. After applying the updated packages: % if ./example.sh; then echo "libnl OK"; else echo "libnl FAILED"; fi gcc -o example -I/usr/include/libnl3 example.c -lnl-3 -lnl-genl-3 set manually the local port to 11295 (pid: 11294) local port has been set by the libnl to 2894081055 (pid: 11295) libnl OK % python libnl3-test-rh1249158.py a b c d ulimit(NOFILE) = (2048, 4096) Test: PID=11296 TEST (a)... ...done TEST (b)... ...done TEST (c)... ...done TEST (d)... ...done [Regression Potential] * There are quite a few high profile packages that depend on this package, notably libvirt and network-manager. The complete list is here: # on Trusty % apt-rdepends -r libnl-3-200 | head -n 33 libnl-3-200 Reverse Depends: batctl (>= 2013.4.0-2) Reverse Depends: bmon (>= 1:3.1-1) Reverse Depends: crda (>= 1.1.2-1ubuntu2) Reverse Depends: hostapd (>= 1:2.1-0ubuntu1) Reverse Depends: ipvsadm (>= 1:1.26-2ubuntu1) Reverse Depends: iw (>= 3.4-1) Reverse Depends: keepalived (>= 1:1.2.7-1ubuntu1) Reverse Depends: kismet (>= 2013.03.R1b-3) Reverse Depends: knemo (>= 0.7.6-2) Reverse Depends: libfsobasics3 (>= 0.12.0-4) Reverse Depends: libnetcf1 (>= 1:0.2.3-4ubuntu1) Reverse Depends: libnl-3-200-dbg (= 3.2.21-1) Reverse Depends: libnl-3-dev (= 3.2.21-1) Reverse Depends: libnl-cli-3-200 (= 3.2.21-1) Reverse Depends: libnl-genl-3-200 (= 3.2.21-1) Reverse Depends: libnl-nf-3-200 (= 3.2.21-1) Reverse Depends: libnl-route-3-200 (= 3.2.21-1) Reverse Depends: libnl-utils (>= 3.2.21-1) Reverse Depends: libnss-gw-name (>= 0.3-2) Reverse Depends: libvirt-bin (>= 1.2.2-0ubuntu13) Reverse Depends: libvirt0 (>= 1.2.2-0ubuntu13) Reverse Depends: lowpan-test-tools (>= 0.3-1) Reverse Depends: lowpan-tools (>= 0.3-1) Reverse Depends: neard (>= 0.11-1) Reverse Depends: neard-tools (>=
[Touch-packages] [Bug 1581535] Re: libnl upgrade breaks Network Manager
*** This bug is a duplicate of bug 1511735 *** https://bugs.launchpad.net/bugs/1511735 I followed Vassil Peytchev's directions to do a manual update of network-manager via USB key, and I'm back online. Thanks for your help! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libnl3 in Ubuntu. https://bugs.launchpad.net/bugs/1581535 Title: libnl upgrade breaks Network Manager Status in libnl3 package in Ubuntu: Invalid Status in libnl3 source package in Trusty: Confirmed Bug description: I appear to have been hit by a regression problem in the libnl update described here: https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1511735 After running a regular software update this morning and rebooting, I've completely lost networking access. Network Manager is down. I'm running Trusty 14.04. I tried this workaround: http://askubuntu.com/questions/727127/last-upgrade-crashes-network- manager-no-internet-connection-no-applet ... and step 1 didn't work. I'll be trying step 2 tonight when I've got more time. I'm filing this as a new bug with a regression-update, as indicated in the above-linked bug report. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1581535/+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 1581535] [NEW] libnl upgrade breaks Network Manager
Public bug reported: I appear to have been hit by a regression problem in the libnl update described here: https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1511735 After running a regular software update this morning and rebooting, I've completely lost networking access. Network Manager is down. I'm running Trusty 14.04. I tried this workaround: http://askubuntu.com/questions/727127/last-upgrade-crashes-network- manager-no-internet-connection-no-applet ... and step 1 didn't work. I'll be trying step 2 tonight when I've got more time. I'm filing this as a new bug with a regression-update, as indicated in the above-linked bug report. ** Affects: libnl3 (Ubuntu) Importance: Undecided Status: New ** Tags: regression-update -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libnl3 in Ubuntu. https://bugs.launchpad.net/bugs/1581535 Title: libnl upgrade breaks Network Manager Status in libnl3 package in Ubuntu: New Bug description: I appear to have been hit by a regression problem in the libnl update described here: https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1511735 After running a regular software update this morning and rebooting, I've completely lost networking access. Network Manager is down. I'm running Trusty 14.04. I tried this workaround: http://askubuntu.com/questions/727127/last-upgrade-crashes-network- manager-no-internet-connection-no-applet ... and step 1 didn't work. I'll be trying step 2 tonight when I've got more time. I'm filing this as a new bug with a regression-update, as indicated in the above-linked bug report. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1581535/+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 1511735] Re: libnl: fail to bind() netlink sockets
I'm in the same boat, this update just broke Network Manager on my system. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libnl3 in Ubuntu. https://bugs.launchpad.net/bugs/1511735 Title: libnl: fail to bind() netlink sockets Status in libnl3 package in Ubuntu: Fix Released Status in libnl3 source package in Trusty: Fix Released Status in libnl3 package in Debian: Fix Released Bug description: [Triage Notes] The proposed fix for this bug in libnl3 caused a regression in trusty- proposed, tracked in bug 1539634. The regression is caused by a latent bug in Network Manager. We expect to fix this by landing a fix for the bug in Network Manager in trusty-updates at the same time as this fix. [Impact] * Applications in Trusty using libnl-3-200 which frequently open and close netlink sockets can easily fail when attempting to bind the local socket. The problem happens when libnl choose a port id already used by another application and subsequently libnl fails instead of trying another port id. The original bug was discovered when attempting to start a virtual machine under libvirt, which is a user of this library. * Backporting fixes from upstream release fixes a real bug in the current version of the library in Trusty. The alternative is for all applications to manually manage their local port allocation, or as upstream has accepted allowing libnl to attempt to try for other local ports. * All patches applied are already accepted upstream and newer Ubuntu releases are not affected. [Test Case] * On a Trusty 14.04 system 1. sudo apt-get install libnl-3-200 libnl-3-dev libnl-3-dev \ libnl-genl-3-dev libnl-route-3-200 \ make gcc build-essential libnl1 2. download and unpack attachment: lp_1511735_test.tar 3. Run testcases: % if ./example.sh; then echo "libnl OK"; else echo "libnl FAILED"; fi gcc -o example -I/usr/include/libnl3 example.c -lnl-3 -lnl-genl-3 set manually the local port to 6975 (pid: 6974) local port has been set by the libnl to 6975 (pid: 6975) ERROR: genl_connect(): Object exists (local port: 6975, pid: 6975) libnl FAILED % python libnl3-test-rh1249158.py a b c d ulimit(NOFILE) = (2048, 4096) Test: PID=6978 TEST (a)... Traceback (most recent call last): File "libnl3-test-rh1249158.py", line 226, in locals()["TEST_" + arg]() File "libnl3-test-rh1249158.py", line 140, in TEST_a sk = nl_get_socket() File "libnl3-test-rh1249158.py", line 115, in nl_get_socket raise IOError(-err, _nl_geterror()) OSError: [Errno 6] b'Unspecific failure' 4. After applying the updated packages: % if ./example.sh; then echo "libnl OK"; else echo "libnl FAILED"; fi gcc -o example -I/usr/include/libnl3 example.c -lnl-3 -lnl-genl-3 set manually the local port to 11295 (pid: 11294) local port has been set by the libnl to 2894081055 (pid: 11295) libnl OK % python libnl3-test-rh1249158.py a b c d ulimit(NOFILE) = (2048, 4096) Test: PID=11296 TEST (a)... ...done TEST (b)... ...done TEST (c)... ...done TEST (d)... ...done [Regression Potential] * There are quite a few high profile packages that depend on this package, notably libvirt and network-manager. The complete list is here: # on Trusty % apt-rdepends -r libnl-3-200 | head -n 33 libnl-3-200 Reverse Depends: batctl (>= 2013.4.0-2) Reverse Depends: bmon (>= 1:3.1-1) Reverse Depends: crda (>= 1.1.2-1ubuntu2) Reverse Depends: hostapd (>= 1:2.1-0ubuntu1) Reverse Depends: ipvsadm (>= 1:1.26-2ubuntu1) Reverse Depends: iw (>= 3.4-1) Reverse Depends: keepalived (>= 1:1.2.7-1ubuntu1) Reverse Depends: kismet (>= 2013.03.R1b-3) Reverse Depends: knemo (>= 0.7.6-2) Reverse Depends: libfsobasics3 (>= 0.12.0-4) Reverse Depends: libnetcf1 (>= 1:0.2.3-4ubuntu1) Reverse Depends: libnl-3-200-dbg (= 3.2.21-1) Reverse Depends: libnl-3-dev (= 3.2.21-1) Reverse Depends: libnl-cli-3-200 (= 3.2.21-1) Reverse Depends: libnl-genl-3-200 (= 3.2.21-1) Reverse Depends: libnl-nf-3-200 (= 3.2.21-1) Reverse Depends: libnl-route-3-200 (= 3.2.21-1) Reverse Depends: libnl-utils (>= 3.2.21-1) Reverse Depends: libnss-gw-name (>= 0.3-2) Reverse Depends: libvirt-bin (>= 1.2.2-0ubuntu13) Reverse Depends: libvirt0 (>= 1.2.2-0ubuntu13) Reverse Depends: lowpan-test-tools (>= 0.3-1) Reverse Depends: lowpan-tools (>= 0.3-1) Reverse Depends: neard (>= 0.11-1) Reverse Depends: neard-tools (>= 0.11-1) Reverse Depends:
