Re: [Touch-packages] [Bug 1080591] Re: shotwell fails to authenticate with non-primary address
> Do you still see a problem related to the one that you reported in a > currently supported version of Ubuntu? Thanks for following up! I don't use Shotwell any more, if nobody else corroborates the report, I suggest you just can close it. -k -- If I haven't seen further, it is by standing in the footprints of giants -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-control-center- signon in Ubuntu. https://bugs.launchpad.net/bugs/1080591 Title: shotwell fails to authenticate with non-primary address Status in One Hundred Papercuts: Incomplete Status in Shotwell: Incomplete Status in gnome-control-center-signon package in Ubuntu: Incomplete Status in shotwell package in Ubuntu: Incomplete Bug description: I am trying to export some pictures from Shotwell to my Picasa account. I select Picasa from the "publish" list, and push the button to authenticate. I am asked for password, which I enter. I am then told that "Authentication failed". Subsequent attempts go directly to "Authentication failed", and there is no apparent way to enter the password again. (I thought this was due to me logging in with a non-gmail address, and it seemed to work when I changed to the gmail one, but now it fails again) Further suggestions: 1) Shotwell should be more informative about the Authentication Failure, and report what exactly is wrong. I thought I had mistyped the password, and then it's frustrating not to be offered the opportunity to retype it. 2) The login dialog should offer a direct link or pointer to the accounts settings, now I need to select "Add an account" from the drop down. 3) Incidentally, removing accounts doesn't work, in the end I had to disable two (non-working) instances of Google account configurations. Shotwell version 0.13.0-0ubuntu3, on Ubuntu 12.10, 64bit. To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1080591/+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 1670959] Re: systemd-resolved using 100% CPU
Just to chime in: Noticed slow machine and systemd-resolved taking 100%
cpu. Edited /etc/systemd/resolved.conf to DNSSEC=no (not off, as "no"
was commented out in the file). Tried systemctl restart systemd-
resolved, but nothing changed. Tried killall systemd-resolved, nothing.
Tried killall -9, and it respawned a well-behaved process. I recently
installed dnsmasq when my computer failed to resolve anything. This is
a fairly up-to-date Ubuntu 17.10.
--
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/1670959
Title:
systemd-resolved using 100% CPU
Status in dnsmasq package in Ubuntu:
Confirmed
Status in systemd package in Ubuntu:
Confirmed
Bug description:
Sometimes systemd-resolved process is using 100% CPU.
After a while it changes back to normal.
It happens usually after connecting to the (wifi) network, like
starting the OS.
strace output:
sendmsg(12, {msg_name(16)={sa_family=AF_INET, sin_port=htons(33589),
sin_addr=inet_addr("127.0.0.1")},
msg_iov(1)=[{"6\215\201\200\0\1\0\1\0\0\0\1\4cs41\3wac\vedgecastcdn\3net\0\0\34\0\1\300\f\0\34\0\1\0\0\10\235\0\20&\6(\0\0024\0Y%L\4\6#f&\214\0\0)\377\326\0\0\0\0\0\0",
81}], msg_controllen=28, [{cmsg_len=28, cmsg_level=SOL_IP,
cmsg_type=IP_PKTINFO, {ipi_ifindex=if_nametoindex("lo"),
ipi_spec_dst=inet_addr("127.0.0.53"), ipi_addr=inet_addr("127.0.0.53")}}],
msg_flags=0}, 0) = 81
sendmsg(3, {msg_name(0)=NULL,
msg_iov(4)=[{"PRIORITY=6\nSYSLOG_FACILITY=3\nCODE_FILE=../src/resolve/resolved-dns-stub.c\nCODE_LINE=363\nCODE_FUNCTION=dns_stub_process_query\nSYSLOG_IDENTIFIER=systemd-resolved\n",
160}, {"MESSAGE=", 8}, {"Processing query...", 19}, {"\n", 1}],
msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 188
epoll_wait(4, [{EPOLLIN, {u32=3176459184, u64=94565471415216}}], 16, -1) = 1
clock_gettime(CLOCK_BOOTTIME, {44665, 938069872}) = 0
recvfrom(12, NULL, 0, MSG_PEEK|MSG_TRUNC, NULL, NULL) = 53
recvmsg(12, {msg_name(16)={sa_family=AF_INET, sin_port=htons(33589),
sin_addr=inet_addr("127.0.0.1")},
msg_iov(1)=[{"Z\262\1\20\0\1\0\0\0\0\0\1\4cs41\3wac\vedgecastcdn\3net\0\0\34\0\1\0\0)\2\0\0\0\0\0\0\0",
3936}], msg_controllen=56, [{cmsg_len=28, cmsg_level=SOL_IP,
cmsg_type=IP_PKTINFO, {ipi_ifindex=if_nametoindex("lo"),
ipi_spec_dst=inet_addr("127.0.0.53"), ipi_addr=inet_addr("127.0.0.53")}},
{cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, {ttl=64}}], msg_flags=0}, 0)
= 53
stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=303, ...}) = 0
getrandom("\365I", 2, GRND_NONBLOCK)= 2
stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=303, ...}) = 0
getrandom("\203;", 2, GRND_NONBLOCK)= 2
clock_gettime(CLOCK_BOOTTIME, {44665, 938446937}) = 0
open("/run/systemd/netif/links/3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=303, ...}) = 0
stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=303, ...}) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 18
connect(18, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
epoll_ctl(4, EPOLL_CTL_ADD, 18, {EPOLLIN, {u32=3176610576,
u64=94565471566608}}) = 0
write(18,
"\203;\1\20\0\1\0\0\0\0\0\1\4cs41\3wac\vedgecastcdn\3net\0\0\34\0\1\0\0)\2\0\0\0\0\0\0\0",
53) = 53
clock_gettime(CLOCK_BOOTTIME, {44665, 938833717}) = 0
clock_gettime(CLOCK_BOOTTIME, {44665, 938875138}) = 0
epoll_ctl(4, EPOLL_CTL_DEL, 18, NULL) = 0
close(18) = 0
journalctl output:
Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query...
Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query...
Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query...
Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query...
Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query...
Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query...
Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query...
Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query...
Mar 08 08:25:41 parsec dnsmasq[1545]: Maximum number of concurrent DNS
queries reached (max: 150)
As you can see, I would use it together with dnsmasq.
ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: systemd 232-18ubuntu1
ProcVersionSignature: Ubuntu 4.10.0-9.11-generic 4.10.0
Uname: Linux 4.10.0-9-generic x86_64
NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
ApportVersion: 2.20.4-0ubuntu2
Architecture: amd64
Date: Wed Mar 8 08:20:18 2017
MachineType: Hewlett-Packard HP EliteBook Folio 1020 G1
ProcEnviron:
LANGUAGE=en_US:en
TERM=xterm
PATH=(custom, no user)
LANG=en_US.UTF-8
SHELL=/bin/zsh
ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.10.0-9-generic
root=UUID=a54fe703-35d4-47ac-9c6e-4034421531fb ro
[Touch-packages] [Bug 1173915] Re: initctl continuously takes 100% of CPU
@Arul, I found something similar in my comment above, at https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1173915/comments/5. But it's been almost 4 years since this issue was reported, and over 2 years since I added my comment, and it's clearly not fixed yet, or even prioritised. In fact, my general experience reporting Ubuntu issues here on launchpad is that this is a black hole, issues are left hanging until they are closed as irrelevant several years later. Critical issues undoubtedly get more attention, but issues such as this are still a problem. Annoying, so I don't really see the point in reporting issues here any more. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upstart in Ubuntu. https://bugs.launchpad.net/bugs/1173915 Title: initctl continuously takes 100% of CPU Status in upstart : Confirmed Status in upstart package in Ubuntu: Confirmed Bug description: Many programs are fairly slow to start on my computer, despite it being relatively new (core i5). Suspecting a heavy CPU usage, I started gnome-system-monitor: all processes were displayed at 0% CPU, but the overall load was 1.33; 1.33; 1.34. Using the "top" command, however, revealed the real CPU use, with the "initctl" process taking 100%CPU, even 1 hour after startup. I upgraded to roaring ringtail before checking this but the symptoms were the same with quantal quetzal, so there is a fair chance the causes were identical. Regards ProblemType: Bug DistroRelease: Ubuntu 13.04 Package: upstart 1.8-0ubuntu1 ProcVersionSignature: Ubuntu 3.8.0-19.29-generic 3.8.8 Uname: Linux 3.8.0-19-generic x86_64 ApportVersion: 2.9.2-0ubuntu8 Architecture: amd64 CheckboxSubmission: 2deefc5fd2f1f0ae2fdd4bd781248a2a CheckboxSystem: daed2f3d6643b4a84b4520a2427f8c2b Date: Sun Apr 28 13:04:05 2013 ExecutablePath: /sbin/initctl InstallationDate: Installed on 2012-12-15 (133 days ago) InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5) MarkForUpload: True ProcEnviron: ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-3.8.0-19-generic root=UUID=fa624f8f-d9d0-4b09-af8b-88b106aaaf5b ro quiet splash vt.handoff=7 SourcePackage: upstart UpgradeStatus: Upgraded to raring on 2013-04-28 (0 days ago) UpstartBugCategory: System To manage notifications about this bug go to: https://bugs.launchpad.net/upstart/+bug/1173915/+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 1405232] Re: ping reports wrong IP responding under certain conditions
Couldn't the upstream fix be to time out the DNS resolution? If you don't have an answer in X seconds/milliseconds, never mind and carry on. It's just ping, after all, and it's a good idea to make low level diagnosis independent of higher level functionality, as noted in the Debian bug report. Caching hostnames in ping is a possible strategy, but that's what the local resolver is for. IMHO, that's not something ping should bother doing. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iputils in Ubuntu. https://bugs.launchpad.net/bugs/1405232 Title: ping reports wrong IP responding under certain conditions Status in iputils package in Ubuntu: Confirmed Bug description: Description: Ubuntu 14.04.1 LTS Release: 14.04 iputils-ping: Installed: 3:20121221-4ubuntu1.1 Candidate: 3:20121221-4ubuntu1.1 ping will report the incorrect reply IP address under certain, specific conditions, and is repeatable. This is how to re-create the issue: 1. Start pinging an IP where you get an ICMP error message from some other device (RFC792 lists errors). For instance: Destination IP is offline and the last-hop router reports message type "Destination Unreachable". I assume this would work for any ICMP error, though. 2. When the device comes back online, ping reports replies from the "other" device, when it should report replies from the device that is sending the "Echo Reply" messages. 3. If the ping is stopped and restarted after the device is up, it reports the correct IP address again. Other ping utilities do not exhibit this behavior. Example output (Destination that was pinged was 172.21.56.50, last hop router was 172.21.25.103): circle@circle:~$ /bin/ping 172.21.56.50 PING 172.21.56.50 (172.21.56.50) 56(84) bytes of data. From 172.21.25.103 icmp_seq=1 Destination Host Unreachable From 172.21.25.103 icmp_seq=2 Destination Host Unreachable From 172.21.25.103 icmp_seq=3 Destination Host Unreachable From 172.21.25.103 icmp_seq=4 Destination Host Unreachable From 172.21.25.103 icmp_seq=5 Destination Host Unreachable From 172.21.25.103 icmp_seq=6 Destination Host Unreachable 64 bytes from 172.21.25.103: icmp_seq=7 ttl=63 time=0.689 ms 64 bytes from 172.21.25.103: icmp_seq=8 ttl=63 time=0.635 ms 64 bytes from 172.21.25.103: icmp_seq=9 ttl=63 time=0.656 ms 64 bytes from 172.21.25.103: icmp_seq=10 ttl=63 time=0.822 ms 64 bytes from 172.21.25.103: icmp_seq=11 ttl=63 time=0.785 ms ^C --- 172.21.56.50 ping statistics --- 11 packets transmitted, 5 received, +6 errors, 54% packet loss, time 10023ms rtt min/avg/max/mdev = 0.635/0.717/0.822/0.077 ms, pipe 3 circle@circle:~$ /bin/ping 172.21.56.50 PING 172.21.56.50 (172.21.56.50) 56(84) bytes of data. 64 bytes from 172.21.56.50: icmp_seq=1 ttl=63 time=0.737 ms 64 bytes from 172.21.56.50: icmp_seq=2 ttl=63 time=0.646 ms 64 bytes from 172.21.56.50: icmp_seq=3 ttl=63 time=0.626 ms ^C --- 172.21.56.50 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.626/0.669/0.737/0.056 ms ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: iputils-ping 3:20121221-4ubuntu1.1 ProcVersionSignature: Ubuntu 3.13.0-43.72-generic 3.13.11.11 Uname: Linux 3.13.0-43-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.6 Architecture: amd64 CurrentDesktop: XFCE Date: Tue Dec 23 10:50:35 2014 InstallationDate: Installed on 2014-10-08 (76 days ago) InstallationMedia: Xubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140723) SourcePackage: iputils UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iputils/+bug/1405232/+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 1471230] Re: ping got confused about IP-adress after host unreachable
I see I've made a typo regarding icmp_seq in the output of the second run of ping (icmp_seq 1, then 2, and then 1 again, but the last one should be 3). I typed this manually, so there may be other typos as well. But I can't see any typos regarding the main point, I got the ping replies from my own IP address, with times on the order of 0.400ms. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iputils in Ubuntu. https://bugs.launchpad.net/bugs/1471230 Title: ping got confused about IP-adress after host unreachable Status in iputils package in Ubuntu: New Bug description: I tried pinging an IP address on an internal network. My IP is 10.0.0.95, and I'm trying to ping 10.0.0.96. Here's what it looked like: $ ping 10.0.0.96 PING 10.0.0.96 (10.0.0.96) 56(84) bytes of data. From 10.0.0.95 icmp_seq=1 Destination Host Unreachable From 10.0.0.95 icmp_seq=2 Destination Host Unreachable From 10.0.0.95 icmp_seq=3 Destination Host Unreachable From 10.0.0.95 icmp_seq=4 Destination Host Unreachable From 10.0.0.95 icmp_seq=5 Destination Host Unreachable From 10.0.0.95 icmp_seq=6 Destination Host Unreachable From 10.0.0.95 icmp_seq=7 Destination Host Unreachable From 10.0.0.95 icmp_seq=8 Destination Host Unreachable From 10.0.0.95 icmp_seq=9 Destination Host Unreachable From 10.0.0.95 icmp_seq=10 Destination Host Unreachable From 10.0.0.95 icmp_seq=11 Destination Host Unreachable From 10.0.0.95 icmp_seq=12 Destination Host Unreachable 64 bytes from 10.0.0.95: icmp_seq=13 ttl=64 time=5.01ms 64 bytes from 10.0.0.95: icmp_seq=14 ttl=64 time=0.658ms 64 bytes from 10.0.0.95: icmp_seq=15 ttl=64 time=0.459ms 64 bytes from 10.0.0.95: icmp_seq=16 ttl=64 time=0.432ms 64 bytes from 10.0.0.95: icmp_seq=17 ttl=64 time=0.437ms 64 bytes from 10.0.0.95: icmp_seq=18 ttl=64 time=0.348ms 64 bytes from 10.0.0.95: icmp_seq=19 ttl=64 time=0.485ms 64 bytes from 10.0.0.95: icmp_seq=20 ttl=64 time=0.529ms 64 bytes from 10.0.0.95: icmp_seq=21 ttl=64 time=0.459ms [snip] ^C --- 10.0.0.96 ping statistics --- 47 packets transmitted, 35 received, +12 errors, 25% packet loss, time 46069ms rtt min/avg/max/mdev = 0.348/2.693/70.753/11.712 ms, pipe 3 $ ping 10.0.0.96 PING 10.0.0.96 (10.0.0.96) 56(84) bytes of data. 64 bytes from 10.0.0.96: icmp_seq=1 ttl=64 time=0.324ms 64 bytes from 10.0.0.96: icmp_seq=2 ttl=64 time=0.405ms 64 bytes from 10.0.0.96: icmp_seq=1 ttl=64 time=0.357ms etc... So on the initial run, ping claims it got a ping reply from 10.0.0.95, which isn't the address I'm pinging. It's my host, and it's normal to get the initial ICMP Destination Host Unreachable messages from the local IP when ARP fails. I almost immediately reran ping, and now the host was up from the start, and see responses coming from the actual host that I'm pinging. Looking at the times, the ping replies appear to actually come from 10.0.0.96, or at least some other remote host, based on the time values. If I ping 10.0.0.95 (my own IP), I'm seeing time values of 0.040ms or thereabouts, so an order of magnitude faster. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: iputils-ping 3:20121221-4ubuntu1.1 Uname: Linux 3.17.1-031701-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.11 Architecture: amd64 CurrentDesktop: Unity Date: Fri Jul 3 15:16:40 2015 InstallationDate: Installed on 2014-10-09 (266 days ago) InstallationMedia: Ubuntu 14.04.1 LTS Trusty Tahr - Release amd64 (20140722.2) SourcePackage: iputils UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iputils/+bug/1471230/+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 1471230] [NEW] ping got confused about IP-adress after host unreachable
Public bug reported: I tried pinging an IP address on an internal network. My IP is 10.0.0.95, and I'm trying to ping 10.0.0.96. Here's what it looked like: $ ping 10.0.0.96 PING 10.0.0.96 (10.0.0.96) 56(84) bytes of data. From 10.0.0.95 icmp_seq=1 Destination Host Unreachable From 10.0.0.95 icmp_seq=2 Destination Host Unreachable From 10.0.0.95 icmp_seq=3 Destination Host Unreachable From 10.0.0.95 icmp_seq=4 Destination Host Unreachable From 10.0.0.95 icmp_seq=5 Destination Host Unreachable From 10.0.0.95 icmp_seq=6 Destination Host Unreachable From 10.0.0.95 icmp_seq=7 Destination Host Unreachable From 10.0.0.95 icmp_seq=8 Destination Host Unreachable From 10.0.0.95 icmp_seq=9 Destination Host Unreachable From 10.0.0.95 icmp_seq=10 Destination Host Unreachable From 10.0.0.95 icmp_seq=11 Destination Host Unreachable From 10.0.0.95 icmp_seq=12 Destination Host Unreachable 64 bytes from 10.0.0.95: icmp_seq=13 ttl=64 time=5.01ms 64 bytes from 10.0.0.95: icmp_seq=14 ttl=64 time=0.658ms 64 bytes from 10.0.0.95: icmp_seq=15 ttl=64 time=0.459ms 64 bytes from 10.0.0.95: icmp_seq=16 ttl=64 time=0.432ms 64 bytes from 10.0.0.95: icmp_seq=17 ttl=64 time=0.437ms 64 bytes from 10.0.0.95: icmp_seq=18 ttl=64 time=0.348ms 64 bytes from 10.0.0.95: icmp_seq=19 ttl=64 time=0.485ms 64 bytes from 10.0.0.95: icmp_seq=20 ttl=64 time=0.529ms 64 bytes from 10.0.0.95: icmp_seq=21 ttl=64 time=0.459ms [snip] ^C --- 10.0.0.96 ping statistics --- 47 packets transmitted, 35 received, +12 errors, 25% packet loss, time 46069ms rtt min/avg/max/mdev = 0.348/2.693/70.753/11.712 ms, pipe 3 $ ping 10.0.0.96 PING 10.0.0.96 (10.0.0.96) 56(84) bytes of data. 64 bytes from 10.0.0.96: icmp_seq=1 ttl=64 time=0.324ms 64 bytes from 10.0.0.96: icmp_seq=2 ttl=64 time=0.405ms 64 bytes from 10.0.0.96: icmp_seq=1 ttl=64 time=0.357ms etc... So on the initial run, ping claims it got a ping reply from 10.0.0.95, which isn't the address I'm pinging. It's my host, and it's normal to get the initial ICMP Destination Host Unreachable messages from the local IP when ARP fails. I almost immediately reran ping, and now the host was up from the start, and see responses coming from the actual host that I'm pinging. Looking at the times, the ping replies appear to actually come from 10.0.0.96, or at least some other remote host, based on the time values. If I ping 10.0.0.95 (my own IP), I'm seeing time values of 0.040ms or thereabouts, so an order of magnitude faster. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: iputils-ping 3:20121221-4ubuntu1.1 Uname: Linux 3.17.1-031701-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.11 Architecture: amd64 CurrentDesktop: Unity Date: Fri Jul 3 15:16:40 2015 InstallationDate: Installed on 2014-10-09 (266 days ago) InstallationMedia: Ubuntu 14.04.1 LTS Trusty Tahr - Release amd64 (20140722.2) SourcePackage: iputils UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: iputils (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug trusty -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iputils in Ubuntu. https://bugs.launchpad.net/bugs/1471230 Title: ping got confused about IP-adress after host unreachable Status in iputils package in Ubuntu: New Bug description: I tried pinging an IP address on an internal network. My IP is 10.0.0.95, and I'm trying to ping 10.0.0.96. Here's what it looked like: $ ping 10.0.0.96 PING 10.0.0.96 (10.0.0.96) 56(84) bytes of data. From 10.0.0.95 icmp_seq=1 Destination Host Unreachable From 10.0.0.95 icmp_seq=2 Destination Host Unreachable From 10.0.0.95 icmp_seq=3 Destination Host Unreachable From 10.0.0.95 icmp_seq=4 Destination Host Unreachable From 10.0.0.95 icmp_seq=5 Destination Host Unreachable From 10.0.0.95 icmp_seq=6 Destination Host Unreachable From 10.0.0.95 icmp_seq=7 Destination Host Unreachable From 10.0.0.95 icmp_seq=8 Destination Host Unreachable From 10.0.0.95 icmp_seq=9 Destination Host Unreachable From 10.0.0.95 icmp_seq=10 Destination Host Unreachable From 10.0.0.95 icmp_seq=11 Destination Host Unreachable From 10.0.0.95 icmp_seq=12 Destination Host Unreachable 64 bytes from 10.0.0.95: icmp_seq=13 ttl=64 time=5.01ms 64 bytes from 10.0.0.95: icmp_seq=14 ttl=64 time=0.658ms 64 bytes from 10.0.0.95: icmp_seq=15 ttl=64 time=0.459ms 64 bytes from 10.0.0.95: icmp_seq=16 ttl=64 time=0.432ms 64 bytes from 10.0.0.95: icmp_seq=17 ttl=64 time=0.437ms 64 bytes from 10.0.0.95: icmp_seq=18 ttl=64 time=0.348ms 64 bytes from 10.0.0.95: icmp_seq=19 ttl=64 time=0.485ms 64 bytes from 10.0.0.95: icmp_seq=20 ttl=64 time=0.529ms 64 bytes from 10.0.0.95: icmp_seq=21 ttl=64 time=0.459ms [snip] ^C --- 10.0.0.96 ping statistics --- 47 packets transmitted, 35 received, +12 errors, 25% packet loss, time 46069ms rtt min/avg/max/mdev = 0.348/2.693/70.753/11.712 ms, pipe 3 $ ping 10.0.0.96 PING
[Touch-packages] [Bug 1466608] [NEW] Unable to resolve domains with large EDNS0 replies
Public bug reported: Not sure resolvconf is the correct place to report this bug, but I'm unable to resolve domains with large EDNS0 replies. A couple of examples are www.sciencedaily.com and www.ncbi.nlm.nih.gov. Interestingly, they resolve when I use dig domain, but if I enter a URL with either of those domains in my browser (tried Chromium and Firefox), then name resolution fails. Ping also fails with a name resolution error message. Here's an example: $ dig www.ncbi.nlm.nih.gov ; DiG 9.9.5-3ubuntu0.2-Ubuntu www.ncbi.nlm.nih.gov ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 8409 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1280 ;; QUESTION SECTION: ;www.ncbi.nlm.nih.gov. IN A ;; ANSWER SECTION: www.ncbi.nlm.nih.gov. 2358IN CNAME www.wip.ncbi.nlm.nih.gov. www.ncbi.nlm.nih.gov. 2358IN RRSIG CNAME 7 5 86400 20151213102025 20150616102025 52670 ncbi.nlm.nih.gov. dZt9uuyLImbB23vdqcsSK+nWK77BREttiAP80Ovq2/xV48JsII3Uxzxc W8OkLmc5dSdPNkfwc6QFC/+wqe+4ORb1TC4Qxw5HQxo4nCindPFGZAgJ SEFcWRJ2HrU5BKz/MeVMALJ3YN6LSHIwkTIwJbKweTGLQTZPZTryp1M7 UQrqd0hs7tjjwVl/6zRIA5UGgFbdrLwX9jmh4ykBTqK8u0Rt/wrTeHbp UpVMxAUdUW1CJ7xAnn/k4td6zdx7Tm5+CkS99Qva0cPfSSo6Qh4Uplun LKwT9GR4zqBTQRjBWSTf2YdhrAU8oyh9WbQ66WHLYkC8Kp55iskL8E8p E5wOYA== www.wip.ncbi.nlm.nih.gov. 30IN A 130.14.29.110 www.wip.ncbi.nlm.nih.gov. 30IN RRSIG A 7 6 30 20150708223631 20150617223631 34334 wip.ncbi.nlm.nih.gov. aF9abjtGNMz+8NkcTGIY8GwjfZBCcL532B2sdJM891OAP2V9GwPCDGNY VzMPzZjMGN9qHsBgXuFY5jZQNWFvWfIQctTJEZTxClyJyFhe5JbyIspg NIO6ZXxjD3h7Ax/Sr5peyf8mfCU/8FZHPGJOhsNEFOwL3RjIddTK6Ibc PQ55CWOuVrvw26kKj9gxBG8r6iBcKe89xHQYPm1w+Osp8c2twGhqBmfd 7zcRxFLyF0BpY63kcQiF5lJ2fI31x+zCAROL9H3L1jm/K7aMAiO5kuWl DK57upsmtQNzjWX8coYpm7/3Gebfmpjx4BtC75L5IP/WfwVBfzHeRjAG KY/7aQ== ;; Query time: 132 msec ;; SERVER: 127.0.1.1#53(127.0.1.1) ;; WHEN: Thu Jun 18 20:26:50 CEST 2015 ;; MSG SIZE rcvd: 699 $ ping www.ncbi.nlm.nih.gov ping: unknown host www.ncbi.nlm.nih.gov I also watched with tcpdump when trying to look up the domain www.sciencedaily.com, and when I use dig I immediately get the reply, but when trying with ping I don't get any reply, and it gives up after 4 queries are sent. Must have something to do with the DNS flags that are set on the query in the different cases. Here's a lookup with dig: 20:01:47.857269 IP 127.0.0.1.56927 127.0.1.1.53: 9907+ [1au] A? www.sciencedaily.com. (49) 20:01:47.869516 IP 127.0.1.1.53 127.0.0.1.56927: 9907 2/6/43 CNAME ed5n3.x.incapdns.net., A 149.126.72.70 (879) and here's a name resolution triggered by running ping: 20:02:47.969527 IP 127.0.0.1.35905 127.0.1.1.53: 59118+ A? www.sciencedaily.com. (38) 20:02:52.974752 IP 127.0.0.1.35905 127.0.1.1.53: 59118+ A? www.sciencedaily.com. (38) 20:02:57.980296 IP 127.0.0.1.48738 127.0.1.1.53: 3668+ A? www.sciencedaily.com. (38) 20:03:02.985493 IP 127.0.0.1.48738 127.0.1.1.53: 3668+ A? www.sciencedaily.com. (38) I've not experienced this before, though these aren't domains I commonly visit. Is this a new issue? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: resolvconf 1.69ubuntu1.1 ProcVersionSignature: Ubuntu 3.13.0-52.86-generic 3.13.11-ckt18 Uname: Linux 3.13.0-52-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.11 Architecture: amd64 CurrentDesktop: Unity Date: Thu Jun 18 20:23:19 2015 InstallationDate: Installed on 2014-10-19 (241 days ago) InstallationMedia: Ubuntu 14.04.1 LTS Trusty Tahr - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: resolvconf (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug trusty -- 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/1466608 Title: Unable to resolve domains with large EDNS0 replies Status in resolvconf package in Ubuntu: New Bug description: Not sure resolvconf is the correct place to report this bug, but I'm unable to resolve domains with large EDNS0 replies. A couple of examples are www.sciencedaily.com and www.ncbi.nlm.nih.gov. Interestingly, they resolve when I use dig domain, but if I enter a URL with either of those domains in my browser (tried Chromium and Firefox), then name resolution fails. Ping also fails with a name resolution error message. Here's an example: $ dig www.ncbi.nlm.nih.gov ; DiG 9.9.5-3ubuntu0.2-Ubuntu www.ncbi.nlm.nih.gov ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 8409 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1280 ;; QUESTION SECTION: ;www.ncbi.nlm.nih.gov.
[Touch-packages] [Bug 1466608] Re: Unable to resolve domains with large EDNS0 replies
Thanks, I was hoping for some help to find the right place to report this. I poked around some more, and I found out what the problem was. First of all, my wireless router was confused. I rebooted it, and then everything started working again. I did some debugging before I rebooted it, though, and the reason for the partial failure situation was that EDNS0 wasn't specified in the queries sent by Ubuntu, but dig specifies it by default (as well as the AD flag, but I don't think that's relevant). A partial result should have been given by the DNS server (on the wireless router), or it should have truncated the reply to force a TCP retry by the client. (Now that everything works, it trims down the Additional section to fit the response.) To confirm, I ran dig like this, and these queries failed on my confused router: dig +noedns +noadflag @127.0.1.1 www.sciencedaily.com So if Ubuntu had in fact set EDNS0 in the query, it would have worked. Falling back to TCP presumably wasn't an option since no malformed/truncated result was received first. Feel free to close this issue if my router's behaviour was completely unacceptable and should cause failure on the client side. If it ought to have been handled better by Ubuntu, however, this may have been an interesting corner case for debugging. Let me know if you need anything else. -- 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/1466608 Title: Unable to resolve domains with large EDNS0 replies Status in dnsmasq package in Ubuntu: New Bug description: Not sure resolvconf is the correct place to report this bug, but I'm unable to resolve domains with large EDNS0 replies. A couple of examples are www.sciencedaily.com and www.ncbi.nlm.nih.gov. Interestingly, they resolve when I use dig domain, but if I enter a URL with either of those domains in my browser (tried Chromium and Firefox), then name resolution fails. Ping also fails with a name resolution error message. Here's an example: $ dig www.ncbi.nlm.nih.gov ; DiG 9.9.5-3ubuntu0.2-Ubuntu www.ncbi.nlm.nih.gov ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 8409 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1280 ;; QUESTION SECTION: ;www.ncbi.nlm.nih.gov.IN A ;; ANSWER SECTION: www.ncbi.nlm.nih.gov. 2358IN CNAME www.wip.ncbi.nlm.nih.gov. www.ncbi.nlm.nih.gov. 2358IN RRSIG CNAME 7 5 86400 20151213102025 20150616102025 52670 ncbi.nlm.nih.gov. dZt9uuyLImbB23vdqcsSK+nWK77BREttiAP80Ovq2/xV48JsII3Uxzxc W8OkLmc5dSdPNkfwc6QFC/+wqe+4ORb1TC4Qxw5HQxo4nCindPFGZAgJ SEFcWRJ2HrU5BKz/MeVMALJ3YN6LSHIwkTIwJbKweTGLQTZPZTryp1M7 UQrqd0hs7tjjwVl/6zRIA5UGgFbdrLwX9jmh4ykBTqK8u0Rt/wrTeHbp UpVMxAUdUW1CJ7xAnn/k4td6zdx7Tm5+CkS99Qva0cPfSSo6Qh4Uplun LKwT9GR4zqBTQRjBWSTf2YdhrAU8oyh9WbQ66WHLYkC8Kp55iskL8E8p E5wOYA== www.wip.ncbi.nlm.nih.gov. 30 IN A 130.14.29.110 www.wip.ncbi.nlm.nih.gov. 30 IN RRSIG A 7 6 30 20150708223631 20150617223631 34334 wip.ncbi.nlm.nih.gov. aF9abjtGNMz+8NkcTGIY8GwjfZBCcL532B2sdJM891OAP2V9GwPCDGNY VzMPzZjMGN9qHsBgXuFY5jZQNWFvWfIQctTJEZTxClyJyFhe5JbyIspg NIO6ZXxjD3h7Ax/Sr5peyf8mfCU/8FZHPGJOhsNEFOwL3RjIddTK6Ibc PQ55CWOuVrvw26kKj9gxBG8r6iBcKe89xHQYPm1w+Osp8c2twGhqBmfd 7zcRxFLyF0BpY63kcQiF5lJ2fI31x+zCAROL9H3L1jm/K7aMAiO5kuWl DK57upsmtQNzjWX8coYpm7/3Gebfmpjx4BtC75L5IP/WfwVBfzHeRjAG KY/7aQ== ;; Query time: 132 msec ;; SERVER: 127.0.1.1#53(127.0.1.1) ;; WHEN: Thu Jun 18 20:26:50 CEST 2015 ;; MSG SIZE rcvd: 699 $ ping www.ncbi.nlm.nih.gov ping: unknown host www.ncbi.nlm.nih.gov I also watched with tcpdump when trying to look up the domain www.sciencedaily.com, and when I use dig I immediately get the reply, but when trying with ping I don't get any reply, and it gives up after 4 queries are sent. Must have something to do with the DNS flags that are set on the query in the different cases. Here's a lookup with dig: 20:01:47.857269 IP 127.0.0.1.56927 127.0.1.1.53: 9907+ [1au] A? www.sciencedaily.com. (49) 20:01:47.869516 IP 127.0.1.1.53 127.0.0.1.56927: 9907 2/6/43 CNAME ed5n3.x.incapdns.net., A 149.126.72.70 (879) and here's a name resolution triggered by running ping: 20:02:47.969527 IP 127.0.0.1.35905 127.0.1.1.53: 59118+ A? www.sciencedaily.com. (38) 20:02:52.974752 IP 127.0.0.1.35905 127.0.1.1.53: 59118+ A? www.sciencedaily.com. (38) 20:02:57.980296 IP 127.0.0.1.48738 127.0.1.1.53: 3668+ A? www.sciencedaily.com. (38) 20:03:02.985493 IP 127.0.0.1.48738 127.0.1.1.53: 3668+ A? www.sciencedaily.com. (38) I've not experienced this before, though these aren't domains I commonly visit. Is this a new issue? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: resolvconf 1.69ubuntu1.1
[Touch-packages] [Bug 1466608] Re: Unable to resolve domains with large EDNS0 replies
To get Ubuntu to send EDNS0 queries, I can set this in resolv.conf: options edns0 That might work around this bug in my router in the future. And in case anyone is interested, the wireless router is a Netgear WNR2000v5. I think this case can be closed. -- 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/1466608 Title: Unable to resolve domains with large EDNS0 replies Status in dnsmasq package in Ubuntu: New Bug description: Not sure resolvconf is the correct place to report this bug, but I'm unable to resolve domains with large EDNS0 replies. A couple of examples are www.sciencedaily.com and www.ncbi.nlm.nih.gov. Interestingly, they resolve when I use dig domain, but if I enter a URL with either of those domains in my browser (tried Chromium and Firefox), then name resolution fails. Ping also fails with a name resolution error message. Here's an example: $ dig www.ncbi.nlm.nih.gov ; DiG 9.9.5-3ubuntu0.2-Ubuntu www.ncbi.nlm.nih.gov ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 8409 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1280 ;; QUESTION SECTION: ;www.ncbi.nlm.nih.gov.IN A ;; ANSWER SECTION: www.ncbi.nlm.nih.gov. 2358IN CNAME www.wip.ncbi.nlm.nih.gov. www.ncbi.nlm.nih.gov. 2358IN RRSIG CNAME 7 5 86400 20151213102025 20150616102025 52670 ncbi.nlm.nih.gov. dZt9uuyLImbB23vdqcsSK+nWK77BREttiAP80Ovq2/xV48JsII3Uxzxc W8OkLmc5dSdPNkfwc6QFC/+wqe+4ORb1TC4Qxw5HQxo4nCindPFGZAgJ SEFcWRJ2HrU5BKz/MeVMALJ3YN6LSHIwkTIwJbKweTGLQTZPZTryp1M7 UQrqd0hs7tjjwVl/6zRIA5UGgFbdrLwX9jmh4ykBTqK8u0Rt/wrTeHbp UpVMxAUdUW1CJ7xAnn/k4td6zdx7Tm5+CkS99Qva0cPfSSo6Qh4Uplun LKwT9GR4zqBTQRjBWSTf2YdhrAU8oyh9WbQ66WHLYkC8Kp55iskL8E8p E5wOYA== www.wip.ncbi.nlm.nih.gov. 30 IN A 130.14.29.110 www.wip.ncbi.nlm.nih.gov. 30 IN RRSIG A 7 6 30 20150708223631 20150617223631 34334 wip.ncbi.nlm.nih.gov. aF9abjtGNMz+8NkcTGIY8GwjfZBCcL532B2sdJM891OAP2V9GwPCDGNY VzMPzZjMGN9qHsBgXuFY5jZQNWFvWfIQctTJEZTxClyJyFhe5JbyIspg NIO6ZXxjD3h7Ax/Sr5peyf8mfCU/8FZHPGJOhsNEFOwL3RjIddTK6Ibc PQ55CWOuVrvw26kKj9gxBG8r6iBcKe89xHQYPm1w+Osp8c2twGhqBmfd 7zcRxFLyF0BpY63kcQiF5lJ2fI31x+zCAROL9H3L1jm/K7aMAiO5kuWl DK57upsmtQNzjWX8coYpm7/3Gebfmpjx4BtC75L5IP/WfwVBfzHeRjAG KY/7aQ== ;; Query time: 132 msec ;; SERVER: 127.0.1.1#53(127.0.1.1) ;; WHEN: Thu Jun 18 20:26:50 CEST 2015 ;; MSG SIZE rcvd: 699 $ ping www.ncbi.nlm.nih.gov ping: unknown host www.ncbi.nlm.nih.gov I also watched with tcpdump when trying to look up the domain www.sciencedaily.com, and when I use dig I immediately get the reply, but when trying with ping I don't get any reply, and it gives up after 4 queries are sent. Must have something to do with the DNS flags that are set on the query in the different cases. Here's a lookup with dig: 20:01:47.857269 IP 127.0.0.1.56927 127.0.1.1.53: 9907+ [1au] A? www.sciencedaily.com. (49) 20:01:47.869516 IP 127.0.1.1.53 127.0.0.1.56927: 9907 2/6/43 CNAME ed5n3.x.incapdns.net., A 149.126.72.70 (879) and here's a name resolution triggered by running ping: 20:02:47.969527 IP 127.0.0.1.35905 127.0.1.1.53: 59118+ A? www.sciencedaily.com. (38) 20:02:52.974752 IP 127.0.0.1.35905 127.0.1.1.53: 59118+ A? www.sciencedaily.com. (38) 20:02:57.980296 IP 127.0.0.1.48738 127.0.1.1.53: 3668+ A? www.sciencedaily.com. (38) 20:03:02.985493 IP 127.0.0.1.48738 127.0.1.1.53: 3668+ A? www.sciencedaily.com. (38) I've not experienced this before, though these aren't domains I commonly visit. Is this a new issue? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: resolvconf 1.69ubuntu1.1 ProcVersionSignature: Ubuntu 3.13.0-52.86-generic 3.13.11-ckt18 Uname: Linux 3.13.0-52-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.11 Architecture: amd64 CurrentDesktop: Unity Date: Thu Jun 18 20:23:19 2015 InstallationDate: Installed on 2014-10-19 (241 days ago) InstallationMedia: Ubuntu 14.04.1 LTS Trusty Tahr - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: resolvconf UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1466608/+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 1174098] Re: blockdev doesn't work as reported with loop devices
Proposed package works for me, and I confirmed again that the version I had before upgrading had the same issue. From apt-get output: Unpacking util-linux (2.20.1-5.1ubuntu20.2) over (2.20.1-5.1ubuntu20.1) ... I don't see where I can change verification-needed to verification-done, however. Hopefully someone else can take care of that. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1174098 Title: blockdev doesn't work as reported with loop devices Status in “util-linux” package in Ubuntu: Fix Released Status in “util-linux” source package in Trusty: Fix Committed Status in “util-linux” source package in Utopic: Fix Released Bug description: SRU Justification: [Impact] blockdev won't work correctly with loopback devices. [Test Case] 1) Create and mount a loop back device on /dev/loop0 2) Run: $ sudo blockdev --report /dev/loop0 This should work without an ioctl error. [Regression Potential] This patch is backported from an upstream release commit 569d1dac. Its already in utopic, and the patch modifies the program to no longer use an invalid ioctl call. -- According to blockdev's manual: --report Print a report for the specified device. It is possible to give multiple devices. If none is given, all devices which appear in /proc/partitions are shown. Note that the partition StartSec is in 512-byte sectors. However, I'm running Ubuntu installed with wubi, so my root dev is on a loopback device. Here's my /proc/partitions: major minor #blocks name 70 30457856 loop0 71 31457280 loop1 80 732574584 sda 81 26214400 sda1 82 307263488 sda2 83 1 sda3 85 399092736 sda5 So according to the manual, all these devices should be printed with blockdev --report. But they are not, the loop devices are excluded: $ sudo blockdev --report [sudo] password for user: RORA SSZ BSZ StartSecSize Device rw 256 512 4096 0750156374016 /dev/sda rw 256 512 4096 2048 26843545600 /dev/sda1 rw 256 512 4096 52430848314637811712 /dev/sda2 rw 256 512 1024 6669578241024 /dev/sda3 rw 256 512 4096 666959872408670961664 /dev/sda5 $ ProblemType: Bug DistroRelease: Ubuntu 12.10 Package: util-linux 2.20.1-5.1ubuntu2 ProcVersionSignature: Ubuntu 3.5.0-27.46-generic 3.5.7.7 Uname: Linux 3.5.0-27-generic x86_64 ApportVersion: 2.6.1-0ubuntu10 Architecture: amd64 Date: Sun Apr 28 23:48:07 2013 InstallationDate: Installed on 2012-04-12 (381 days ago) InstallationMedia: Ubuntu 11.10 Oneiric Ocelot - Release amd64 (20111012) MarkForUpload: True SourcePackage: util-linux UpgradeStatus: Upgraded to quantal on 2012-11-15 (164 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1174098/+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
