[Touch-packages] [Bug 1783994] Re: systemd spams log with "Failed to dissect: Input/output error" on systems with mmc
I can confirm, that the package in -proposed fixed the problem. -- 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/1783994 Title: systemd spams log with "Failed to dissect: Input/output error" on systems with mmc Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Bug description: [impact] on systems with mmc device installed, systemd-gpt-auto-generator fails. [test case] on a system with mmc device installed, run systemd-gpt-auto-generator and check log for: systemd-gpt-auto-generator[207]: Failed to dissect: Input/output error [regression potential] as this is related to boot, regressions might occur at boot, or while modifying or configuring a boot loader. [other info] original description: --- If a device has an mmc installed, systemd-gpt-auto-generator will fail because of "special partition" (rpmb, boot) and record a log message: systemd-gpt-auto-generator[207]: Failed to dissect: Input/output error This issue was discussed here: https://github.com/systemd/systemd/issues/5806 and a fix is proposed for new systemd versions. Please include in bionic. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1783994/+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 1752411] Re: bind9-host, avahi-daemon-check-dns.sh hang forever causes network connections to get stuck
I found a source reference here: https://github.com/fanf2/bind-9/blob/master/lib/isc/unix/socket.c#L4127 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to avahi in Ubuntu. https://bugs.launchpad.net/bugs/1752411 Title: bind9-host, avahi-daemon-check-dns.sh hang forever causes network connections to get stuck Status in avahi package in Ubuntu: Fix Released Status in bind9 package in Ubuntu: Confirmed Status in openconnect package in Ubuntu: Invalid Status in strongswan package in Ubuntu: Invalid Status in avahi source package in Bionic: Triaged Status in bind9 source package in Bionic: Confirmed Status in avahi source package in Cosmic: Fix Released Status in bind9 source package in Cosmic: Confirmed Status in avahi package in Debian: New Bug description: [Impact] * Network connections for some users fail (in some cases a direct interface, in others when connecting a VPN) because the 'host' command to check for .local in DNS called by /usr/lib/avahi/avahi-daemon- check-dns.sh never times out like it should - leaving the script hanging indefinitely blocking interface up and start-up. This appears to be a bug in host caused in some circumstances however we implement a workaround to call it under 'timeout' as the issue with 'host' has not easily been identified, and in any case acts as a fall-back. [Test Case] * Multiple people have been unable to create a reproducer on a generic machine (e.g. it does not occur in a VM), I have a specific machine I can reproduce it on (a Skull Canyon NUC with Intel I219-LM) by simply "ifdown br0; ifup br0" and there are clearly 10s of other users affected in varying circumstances that all involve the same symptoms but no clear test case exists. Best I can suggest is that I test the patch on my system to ensure it works as expected, and the change is only 1 line which is fairly easily auditible and understandable. [Regression Potential] * The change is a single line change to the shell script to call host with "timeout". When tested on working and non-working system this appears to function as expected. I believe the regression potential for this is subsequently low. * In attempt to anticipate possible issues, I checked that the timeout command is in the same path (/usr/bin) as the host command that is already called without a path, and the coreutils package (which contains timeout) is an Essential package. I also checked that timeout is not a built-in in bash, for those that have changed /bin/sh to bash (just in case). [Other Info] * N/A [Original Bug Description] On 18.04 Openconnect connects successfully to any of multiple VPN concentrators but network traffic does not flow across the VPN tunnel connection. When testing on 16.04 this works flawlessly. This also worked on this system when it was on 17.10. I have tried reducing the mtu of the tun0 network device but this has not resulted in me being able to successfully ping the IP address. Example showing ping attempt to the IP of DNS server: ~$ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 172.29.88.11 nameserver 127.0.0.53 liam@liam-lat:~$ netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG0 0 0 wlp2s0 105.27.198.106 192.168.1.1 255.255.255.255 UGH 0 0 0 wlp2s0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0 172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0 172.29.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun0 172.29.88.110.0.0.0 255.255.255.255 UH0 0 0 tun0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlp2s0 liam@liam-lat:~$ ping 172.29.88.11 PING 172.29.88.11 (172.29.88.11) 56(84) bytes of data. ^C --- 172.29.88.11 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3054ms ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: openconnect 7.08-3 ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3 Uname: Linux 4.15.0-10-generic x86_64 ApportVersion: 2.20.8-0ubuntu10 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Feb 28 22:11:33 2018 InstallationDate: Installed on 2017-06-15 (258 days ago) InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) SourcePackage: openconnect UpgradeStatus: Upgraded to bionic on 2018-02-22 (6 days ago) To manage
[Touch-packages] [Bug 1752411] Re: bind9-host, avahi-daemon-check-dns.sh hang forever causes network connections to get stuck
also attching a gdb full bt, which shows that epoll_wait is called it a timeout value of "-1" (infinite) in thread #4. ** Attachment added: "gdb.txt" https://bugs.launchpad.net/ubuntu/+source/openconnect/+bug/1752411/+attachment/5182603/+files/gdb.txt -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to avahi in Ubuntu. https://bugs.launchpad.net/bugs/1752411 Title: bind9-host, avahi-daemon-check-dns.sh hang forever causes network connections to get stuck Status in avahi package in Ubuntu: Fix Released Status in bind9 package in Ubuntu: Confirmed Status in openconnect package in Ubuntu: Invalid Status in strongswan package in Ubuntu: Invalid Status in avahi source package in Bionic: Triaged Status in bind9 source package in Bionic: Confirmed Status in avahi source package in Cosmic: Fix Released Status in bind9 source package in Cosmic: Confirmed Status in avahi package in Debian: New Bug description: [Impact] * Network connections for some users fail (in some cases a direct interface, in others when connecting a VPN) because the 'host' command to check for .local in DNS called by /usr/lib/avahi/avahi-daemon- check-dns.sh never times out like it should - leaving the script hanging indefinitely blocking interface up and start-up. This appears to be a bug in host caused in some circumstances however we implement a workaround to call it under 'timeout' as the issue with 'host' has not easily been identified, and in any case acts as a fall-back. [Test Case] * Multiple people have been unable to create a reproducer on a generic machine (e.g. it does not occur in a VM), I have a specific machine I can reproduce it on (a Skull Canyon NUC with Intel I219-LM) by simply "ifdown br0; ifup br0" and there are clearly 10s of other users affected in varying circumstances that all involve the same symptoms but no clear test case exists. Best I can suggest is that I test the patch on my system to ensure it works as expected, and the change is only 1 line which is fairly easily auditible and understandable. [Regression Potential] * The change is a single line change to the shell script to call host with "timeout". When tested on working and non-working system this appears to function as expected. I believe the regression potential for this is subsequently low. * In attempt to anticipate possible issues, I checked that the timeout command is in the same path (/usr/bin) as the host command that is already called without a path, and the coreutils package (which contains timeout) is an Essential package. I also checked that timeout is not a built-in in bash, for those that have changed /bin/sh to bash (just in case). [Other Info] * N/A [Original Bug Description] On 18.04 Openconnect connects successfully to any of multiple VPN concentrators but network traffic does not flow across the VPN tunnel connection. When testing on 16.04 this works flawlessly. This also worked on this system when it was on 17.10. I have tried reducing the mtu of the tun0 network device but this has not resulted in me being able to successfully ping the IP address. Example showing ping attempt to the IP of DNS server: ~$ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 172.29.88.11 nameserver 127.0.0.53 liam@liam-lat:~$ netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG0 0 0 wlp2s0 105.27.198.106 192.168.1.1 255.255.255.255 UGH 0 0 0 wlp2s0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0 172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0 172.29.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun0 172.29.88.110.0.0.0 255.255.255.255 UH0 0 0 tun0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlp2s0 liam@liam-lat:~$ ping 172.29.88.11 PING 172.29.88.11 (172.29.88.11) 56(84) bytes of data. ^C --- 172.29.88.11 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3054ms ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: openconnect 7.08-3 ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3 Uname: Linux 4.15.0-10-generic x86_64 ApportVersion: 2.20.8-0ubuntu10 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Feb 28 22:11:33 2018 InstallationDate: Installed on 2017-06-15 (258 days ago) InstallationMedia: Ubuntu 16.04.1
[Touch-packages] [Bug 1752411] Re: bind9-host, avahi-daemon-check-dns.sh hang forever causes network connections to get stuck
in fact, there are two host commands running, both show wchan=sigsuspend, perf shows nothing and strace shows commands is suspended. new strace is attached. ** Attachment added: "strace.txt" https://bugs.launchpad.net/ubuntu/+source/openconnect/+bug/1752411/+attachment/5182590/+files/strace.txt -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to avahi in Ubuntu. https://bugs.launchpad.net/bugs/1752411 Title: bind9-host, avahi-daemon-check-dns.sh hang forever causes network connections to get stuck Status in avahi package in Ubuntu: Fix Released Status in bind9 package in Ubuntu: Confirmed Status in openconnect package in Ubuntu: Invalid Status in strongswan package in Ubuntu: Invalid Status in avahi source package in Bionic: Triaged Status in bind9 source package in Bionic: Confirmed Status in avahi source package in Cosmic: Fix Released Status in bind9 source package in Cosmic: Confirmed Status in avahi package in Debian: New Bug description: [Impact] * Network connections for some users fail (in some cases a direct interface, in others when connecting a VPN) because the 'host' command to check for .local in DNS called by /usr/lib/avahi/avahi-daemon- check-dns.sh never times out like it should - leaving the script hanging indefinitely blocking interface up and start-up. This appears to be a bug in host caused in some circumstances however we implement a workaround to call it under 'timeout' as the issue with 'host' has not easily been identified, and in any case acts as a fall-back. [Test Case] * Multiple people have been unable to create a reproducer on a generic machine (e.g. it does not occur in a VM), I have a specific machine I can reproduce it on (a Skull Canyon NUC with Intel I219-LM) by simply "ifdown br0; ifup br0" and there are clearly 10s of other users affected in varying circumstances that all involve the same symptoms but no clear test case exists. Best I can suggest is that I test the patch on my system to ensure it works as expected, and the change is only 1 line which is fairly easily auditible and understandable. [Regression Potential] * The change is a single line change to the shell script to call host with "timeout". When tested on working and non-working system this appears to function as expected. I believe the regression potential for this is subsequently low. * In attempt to anticipate possible issues, I checked that the timeout command is in the same path (/usr/bin) as the host command that is already called without a path, and the coreutils package (which contains timeout) is an Essential package. I also checked that timeout is not a built-in in bash, for those that have changed /bin/sh to bash (just in case). [Other Info] * N/A [Original Bug Description] On 18.04 Openconnect connects successfully to any of multiple VPN concentrators but network traffic does not flow across the VPN tunnel connection. When testing on 16.04 this works flawlessly. This also worked on this system when it was on 17.10. I have tried reducing the mtu of the tun0 network device but this has not resulted in me being able to successfully ping the IP address. Example showing ping attempt to the IP of DNS server: ~$ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 172.29.88.11 nameserver 127.0.0.53 liam@liam-lat:~$ netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG0 0 0 wlp2s0 105.27.198.106 192.168.1.1 255.255.255.255 UGH 0 0 0 wlp2s0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0 172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0 172.29.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun0 172.29.88.110.0.0.0 255.255.255.255 UH0 0 0 tun0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlp2s0 liam@liam-lat:~$ ping 172.29.88.11 PING 172.29.88.11 (172.29.88.11) 56(84) bytes of data. ^C --- 172.29.88.11 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3054ms ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: openconnect 7.08-3 ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3 Uname: Linux 4.15.0-10-generic x86_64 ApportVersion: 2.20.8-0ubuntu10 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Feb 28 22:11:33 2018 InstallationDate: Installed on 2017-06-15 (258
[Touch-packages] [Bug 1783994] Re: systemd spams log with "Failed to dissect: Input/output error" on systems with mmc
here is an updated fix: https://github.com/systemd/systemd/commit/cde942f61bf231ea4a0d50780cdb4e744458daeb #diff-5be2770e81c14245e90d2916ded39491 -- 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/1783994 Title: systemd spams log with "Failed to dissect: Input/output error" on systems with mmc Status in systemd package in Ubuntu: New Bug description: If a device has an mmc installed, systemd-gpt-auto-generator will fail because of "special partition" (rpmb, boot) and record a log message: systemd-gpt-auto-generator[207]: Failed to dissect: Input/output error This issue was discussed here: https://github.com/systemd/systemd/issues/5806 and a fix is proposed for new systemd versions. Please include in bionic. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1783994/+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 1783994] [NEW] systemd spams log with "Failed to dissect: Input/output error" on systems with mmc
Public bug reported: If a device has an mmc installed, systemd-gpt-auto-generator will fail because of "special partition" (rpmb, boot) and record a log message: systemd-gpt-auto-generator[207]: Failed to dissect: Input/output error This issue was discussed here: https://github.com/systemd/systemd/issues/5806 and a fix is proposed for new systemd versions. Please include in bionic. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: bionic -- 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/1783994 Title: systemd spams log with "Failed to dissect: Input/output error" on systems with mmc Status in systemd package in Ubuntu: New Bug description: If a device has an mmc installed, systemd-gpt-auto-generator will fail because of "special partition" (rpmb, boot) and record a log message: systemd-gpt-auto-generator[207]: Failed to dissect: Input/output error This issue was discussed here: https://github.com/systemd/systemd/issues/5806 and a fix is proposed for new systemd versions. Please include in bionic. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1783994/+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 1752411] Re: bind9-host, avahi-daemon-check-dns.sh hang forever causes network connections to get stuck
My system was upgraded, so maybe a leftover. So I uninstalled ifupdown and upstart. Problem still persists :-( I will attach a ltrace -Sf host output - maybe it helps... ** Attachment added: "output of "trace -Sf host -d -v -w5 -t soa local."" https://bugs.launchpad.net/ubuntu/+source/openconnect/+bug/1752411/+attachment/5107990/+files/ltrace.txt.gz -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to avahi in Ubuntu. https://bugs.launchpad.net/bugs/1752411 Title: bind9-host, avahi-daemon-check-dns.sh hang forever causes network connections to get stuck Status in avahi package in Ubuntu: Confirmed Status in bind9 package in Ubuntu: Confirmed Status in openconnect package in Ubuntu: Invalid Bug description: On 18.04 Openconnect connects successfully to any of multiple VPN concentrators but network traffic does not flow across the VPN tunnel connection. When testing on 16.04 this works flawlessly. This also worked on this system when it was on 17.10. I have tried reducing the mtu of the tun0 network device but this has not resulted in me being able to successfully ping the IP address. Example showing ping attempt to the IP of DNS server: ~$ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 172.29.88.11 nameserver 127.0.0.53 liam@liam-lat:~$ netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG0 0 0 wlp2s0 105.27.198.106 192.168.1.1 255.255.255.255 UGH 0 0 0 wlp2s0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0 172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0 172.29.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun0 172.29.88.110.0.0.0 255.255.255.255 UH0 0 0 tun0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlp2s0 liam@liam-lat:~$ ping 172.29.88.11 PING 172.29.88.11 (172.29.88.11) 56(84) bytes of data. ^C --- 172.29.88.11 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3054ms ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: openconnect 7.08-3 ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3 Uname: Linux 4.15.0-10-generic x86_64 ApportVersion: 2.20.8-0ubuntu10 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Feb 28 22:11:33 2018 InstallationDate: Installed on 2017-06-15 (258 days ago) InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) SourcePackage: openconnect UpgradeStatus: Upgraded to bionic on 2018-02-22 (6 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1752411/+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
