security.ubuntu.com (2001:67c:1562::XXX) not reachable

[Robert Penz]

I know this is not a bug in the software, but in the network connection of some of the security.ubuntu.com servers via IPv6. Which leads to the problem that no software update is possible without changes in the /etc/gai.conf to prefer IPv4. It resolves to following IP addresses:

$ host security.ubuntu.com
security.ubuntu.com has address 91.189.91.13
security.ubuntu.com has address 91.189.91.14
security.ubuntu.com has address 91.189.91.15
security.ubuntu.com has address 91.189.91.23
security.ubuntu.com has address 91.189.91.24
security.ubuntu.com has address 91.189.92.200
security.ubuntu.com has address 91.189.92.201
security.ubuntu.com has address 91.189.88.149
security.ubuntu.com has IPv6 address 2001:67c:1562::15
security.ubuntu.com has IPv6 address 2001:67c:1562::17
security.ubuntu.com has IPv6 address 2001:67c:1360:8c01::19
security.ubuntu.com has IPv6 address 2001:67c:1562::13
security.ubuntu.com has IPv6 address 2001:67c:1562::16
security.ubuntu.com has IPv6 address 2001:67c:1360:8c01::18
security.ubuntu.com has IPv6 address 2001:67c:1562::14

All IPv6 addresses that start with 2001:67c:1562:: are not reachable from some providers. e.g. Hurricane Electric's, but the error seems to be on the server site. The 2001:67c:1360:8c01 ones work.

An MTR from inside HE's network shows it gets into XO's network, then dies where it hands off to Internap who gets the routes from Occaid/TowardEX, or it used to. Now going via Telia, it still dies inside Internap's network. Not an HE issue - please inform your networks guys. Thx.

  1.|-- f0-6.switch14.fmt2.he.net 0.0% 5 12.0 5.5 0.6 13.5 6.7
  2.|-- 10ge8-4.core1.fmt2.he.net 0.0% 5 0.6 0.6 0.5 0.7 0.0
  3.|-- 10ge1-1.core1.sjc2.he.net 0.0% 5 10.3 5.1 1.0 12.0 5.6
  4.|-- sjo-eqx-s1-link.telia.net 0.0% 5 1.0 1.1 1.0 1.1 0.0
  5.|-- bost-b1-v6.telia.net 0.0% 5 77.4 77.4 77.3 77.4 0.0
  6.|-- internap-ic-304640-bost-b 0.0% 5 78.3 78.3 78.2 78.4 0.0
  7.|-- ??? 100.0 5 0.0 0.0 0.0 0.0 0.0

[Robert Penz (robert-penz-name)]

Other people seem to have the same problem .... e.g. this blog post describes how to prefer IPv4 over IPv6 as security.ubuntu.com does not work

http://zach-adams.com/2015/01/apt-get-cant-connect-to-security-ubuntu-fix/

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Colin Dearborn (stolen)]

Just to note that my native IPv6 connection does work, but my HE tunnel does not, so this does appear to be an issue with routing somewhere. Further, I seem to follow the same forward path on both services (from bost-b1-v6.telia.net on), so it appears to be on the return route:

HE.net:
traceroute6 2001:67c:1562::17
traceroute to 2001:67c:1562::17 (2001:67c:1562::17) from 2001:470:1f04:6a9::2, 30 hops max, 24 byte packets
 1 stolen-1.tunnel.tserv3.fmt2.ipv6.he.net (2001:470:1f04:6a9::1) 53.126 ms 50.294 ms 51.336 ms
 2 ge5-19.core1.fmt2.he.net (2001:470:0:45::1) 56.835 ms 46.881 ms 48.089 ms
 3 10ge1-1.core1.sjc2.he.net (2001:470:0:31::2) 55.947 ms 64.231 ms 49.21 ms
 4 sjo-eqx-s1-link.telia.net (2001:2000:3080:1b7::1) 49.022 ms 53.619 ms 47.623 ms
 5 bost-b1-v6.telia.net (2001:2000:3018:84::1) 174.659 ms 122.656 ms 123.968 ms
 6 internap-ic-304640-bost-b1.c.telia.net (2001:2000:3080:93b::2) 123.846 ms 127.975 ms 126.091 ms
 7 * * *
 8 * * *
 9 * * *

Native:
traceroute6 2001:67c:1562::17
traceroute to 2001:67c:1562::17 (2001:67c:1562::17) from 2001:4e8:8040:200:497f:7458:2db3:83e4, 30 hops max, 24 byte packets
 1 2001:4e8:8040:200:4af8:b3ff:fe8d:b951 (2001:4e8:8040:200:4af8:b3ff:fe8d:b951) 7.615 ms 0.63 ms 0.381 ms
 2 2001:4e8:40:8001:: (2001:4e8:40:8001::) 7.895 ms 2001:4e8:40:8803::10 (2001:4e8:40:8803::10) 9.872 ms 7.742 ms
 3 2001:4e8:0:8196::2 (2001:4e8:0:8196::2) 8.346 ms 9.353 ms 9.783 ms
 4 2001:4e8:0:81c5::2 (2001:4e8:0:81c5::2) 32.332 ms 33.36 ms 32.091 ms
 5 sea-b1-link.telia.net (2001:2000:3080:335::1) 31.34 ms 31.135 ms 29.913 ms
 6 bost-b1-v6.telia.net (2001:2000:3018:84::1) 85.108 ms 85.133 ms 85.936 ms
 7 internap-ic-304640-bost-b1.c.telia.net (2001:2000:3080:93b::2) 89.355 ms 101.394 ms 87.809 ms
 8 mpr1-bbnet2.bsn004.pnap.net (2600:c0d:0:102:0:4:2:1) 95.473 ms 94.968 ms 95.921 ms
 9 2600:c0d:4002:3::2 (2600:c0d:4002:3::2) 95.925 ms 95.245 ms 95.872 ms
10 economy.canonical.com (2001:67c:1562::17) 88.443 ms 87.497 ms 87.958 ms

[Andrew Skalski (askalski)]

This affects all of the IPv6 addresses for us.archive.ubuntu.com as well (the addresses are mostly the same as security.ubuntu.com, excluding the two that actually work.)

It would be less of a concern if apt automatically fell back on the IPv4 stack, but right now the only way for my machines to receive updates is to manually disable IPv6. This is cumbersome--and in the case of security updates, potentially dangerous.

[Robert Penz (robert-penz-name)]

Yeah, a timeout with automatic fall back would be good. The web browsers do that.

[Andrew Skalski (askalski)]

I found a decent workaround: use the main server "archive.ubuntu.com" instead of the mirror. Notice how it includes only the known-good addresses; security.ubuntu.com includes a mix of good and bad hosts, and us.archive.ubuntu.com includes only the bad ones.

$ dig +short archive.ubuntu.com aaaa
2001:67c:1360:8c01::18
2001:67c:1360:8c01::19

$ dig +short security.ubuntu.com aaaa
2001:67c:1562::16
2001:67c:1562::13
2001:67c:1562::14
2001:67c:1562::15
2001:67c:1360:8c01::18
2001:67c:1360:8c01::19
2001:67c:1562::17

$ dig +short us.archive.ubuntu.com aaaa
2001:67c:1562::13
2001:67c:1562::14
2001:67c:1562::15
2001:67c:1562::16
2001:67c:1562::17

[karlsebal (karlsebal)]

Unfortunately 2001:67c:1360:8c01::18 is not working either..

[karlsebal (karlsebal)]

for i in $(dig +short security.ubuntu.com AAAA); do ping6 -w52 $i; done
PING 2001:67c:1562::14(2001:67c:1562::14) 56 data bytes

--- 2001:67c:1562::14 ping statistics ---
53 packets transmitted, 0 received, 100% packet loss, time 51999ms

PING 2001:67c:1562::13(2001:67c:1562::13) 56 data bytes

--- 2001:67c:1562::13 ping statistics ---
52 packets transmitted, 0 received, 100% packet loss, time 51000ms

PING 2001:67c:1360:8c01::19(2001:67c:1360:8c01::19) 56 data bytes

--- 2001:67c:1360:8c01::19 ping statistics ---
53 packets transmitted, 0 received, 100% packet loss, time 51999ms

PING 2001:67c:1360:8c01::18(2001:67c:1360:8c01::18) 56 data bytes

--- 2001:67c:1360:8c01::18 ping statistics ---
53 packets transmitted, 0 received, 100% packet loss, time 51999ms

PING 2001:67c:1562::17(2001:67c:1562::17) 56 data bytes

--- 2001:67c:1562::17 ping statistics ---
53 packets transmitted, 0 received, 100% packet loss, time 51999ms

PING 2001:67c:1562::16(2001:67c:1562::16) 56 data bytes

--- 2001:67c:1562::16 ping statistics ---
53 packets transmitted, 0 received, 100% packet loss, time 51999ms

PING 2001:67c:1562::15(2001:67c:1562::15) 56 data bytes

--- 2001:67c:1562::15 ping statistics ---
52 packets transmitted, 0 received, 100% packet loss, time 51000ms

[bp-art (bp-art)]

And still an issue as of Nov 17, 2015

Connecting to security.ubuntu.com (2001:67c:1562::17)

[Marc Kolly (makuser)]

This problem has been around since 2012 when they enabled IPv6 for their "core services". This: #241305 shows the development of the problem we face now.

I'm not using HE. I tested it using Telekom + M-Net (Germany) and O2 + UPC (Czech Republic), so we can basically say that it's not reachable in at least large parts of Germany and Czech Republic.

Why won't Canonical do something about their routing and peerings???? It's almost four years that we were facing this problem!

[Robie Basak (racb)]

> Why won't Canonical do something about their routing and peerings????

Because nobody told Canonical, apparently. I have now filed an issue with Canonical IS (reference 87918).

[Haw Loeung (hloeung)]

Is this still a problem?

Using Hurricane Electric's looking glass (http://lg.he.net), it all seems to look fine.

From HE looking glass to 2001:67c:1562::/47 (US):

| core1.fmt1.he.net> traceroute ipv6 2001:67c:1562::15 numeric
| Hop Packet 1 Packet 2 Packet 3 Hostname
| 1 49 ms <1 ms <1 ms 10ge11-1.core1.sjc2.he.net (2001:470:0:2f::2)
| 2 22 ms 42 ms 21 ms sjo-b21-link.telia.net (2001:2000:3080:1b7::1)
| 3 89 ms 91 ms 101 ms bost-b1-v6.telia.net (2001:2000:3018:84::1)
| 4 95 ms 105 ms 95 ms internap-ic-304640-bost-b1.c.telia.net (2001:2000:3080:93b::2)
| 5 99 ms 105 ms 95 ms mpr1-bbnet2.bsn004.pnap.net (2600:c0d:0:102:0:4:2:1)
| 6 142 ms 105 ms 99 ms 2600:c0d:4002:3::2
| 7 102 ms 95 ms 91 ms likho.canonical.com (2001:67c:1562::15)

| core1.sjc1.he.net> traceroute ipv6 2001:67c:1562::15 numeric
| Hop Packet 1 Packet 2 Packet 3 Hostname
| 1 19 ms <1 ms <1 ms 10ge4-4.core1.sjc2.he.net (2001:470:0:55::2)
| 2 21 ms 24 ms 1 ms sjo-b21-link.telia.net (2001:2000:3080:1b7::1)
| 3 98 ms 90 ms 101 ms bost-b1-v6.telia.net (2001:2000:3018:84::1)
| 4 97 ms 99 ms 100 ms internap-ic-304640-bost-b1.c.telia.net (2001:2000:3080:93b::2)
| 5 99 ms 99 ms 100 ms mpr1-bbnet1.bsn004.pnap.net (2600:c0d:0:101:0:4:2:1)
| 6 100 ms 97 ms 151 ms 2600:c0d:4002:3::2
| 7 84 ms 75 ms 74 ms likho.canonical.com (2001:67c:1562::15)

From HE looking glass to 2001:67c:1360::/48 (EU):

| core1.fmt1.he.net> traceroute ipv6 2001:67c:1360:8c01::18 numeric
| Hop Packet 1 Packet 2 Packet 3 Hostname
| 1 20 ms 27 ms 21 ms 10ge11-1.core1.sjc2.he.net (2001:470:0:2f::2)
| 2 12 ms 4 ms 20 ms level3.v310.core1.sjc2.he.net (2001:470:0:203::2)
| 3 14 ms 95 ms 28 ms vl-90.edge1.SanJose1.Level3.net (2001:1900:1a:8::8)
| 4 * * 85 ms 2001:1900:4:1::5e
| 5 135 ms 195 ms 147 ms vl-4086.edge3.London1.Level3.net (2001:1900:6:1::11)
| 6 151 ms 148 ms 147 ms vl-51.edge5.London1.Level3.net (2001:1900:101:1::a)
| 7 136 ms 133 ms 142 ms SOURCE-MANA.edge5.London1.Level3.net (2001:1900:5:2:2::131a)
| 8 148 ms 150 ms 148 ms obake.canonical.com (2001:67c:1360:8c01::18)

| core1.sjc1.he.net> traceroute ipv6 2001:67c:1360:8c01::18 numeric
| Hop Packet 1 Packet 2 Packet 3 Hostname
| 1 32 ms 24 ms 24 ms 10ge4-4.core1.sjc2.he.net (2001:470:0:55::2)
| 2 34 ms 33 ms 24 ms level3.v310.core1.sjc2.he.net (2001:470:0:203::2)
| 3 10 ms <1 ms <1 ms vl-90.edge1.SanJose1.Level3.net (2001:1900:1a:8::8)
| 4 * * * ?
| 5 156 ms 159 ms 149 ms vl-4086.edge3.London1.Level3.net (2001:1900:6:1::11)
| 6 159 ms 150 ms 149 ms vl-51.edge5.London1.Level3.net (2001:1900:101:1::a)
| 7 149 ms 186 ms 164 ms SOURCE-MANA.edge5.London1.Level3.net (2001:1900:5:2:2::131a)
| 8 148 ms 149 ms 149 ms obake.canonical.com (2001:67c:1360:8c01::18)

From HE to 2001:67c:1560/47 (EU):

| core1.fmt1.he.net> traceroute ipv6 2001:67c:1560:8001::11 numeric
| Hop Packet 1 Packet 2 Packet 3 Hostname
| 1 23 ms 23 ms 31 ms 10ge11-1.core1.sjc2.he.net (2001:470:0:2f::2)
| 2 8 ms 107 ms 24 ms level3.v310.core1.sjc2.he.net (2001:470:0:203::2)
| 3 18 ms 22 ms 24 ms vl-60.edge1.SanJose1.Level3.net (2001:1900:1a:5::8)
| 4 * * 92 ms 2001:1900:4:1::5e
| 5 144 ms 134 ms 145 ms vl-4086.edge3.London1.Level3.net (2001:1900:6:1::11)
| 6 172 ms 146 ms 134 ms vl-51.edge5.London1.Le...

[Haw Loeung (hloeung)]

> I'm not using HE. I tested it using Telekom + M-Net (Germany) and O2 +
> UPC (Czech Republic), so we can basically say that it's not reachable
> in at least large parts of Germany and Czech Republic.

Marc Kolly (makuser), can you please provide output from mtr/traceroutes from both Telekom + M-Net and O2 + UPC?

[Haw Loeung (hloeung)]

From HE Berlin, Frankfurt, and Prague:

| core1.ber1.he.net> traceroute 2001:67c:1562::15
| Hop Packet 1 Packet 2 Packet 3 Hostname
| 1 10.403 ms 0.176 ms 0.25 ms ge2-20.core1.ber1.he.net (2001:470:0:220::1)
| 2 14.487 ms 54.885 ms 16.052 ms 10ge11-5.core1.ams1.he.net (2001:470:0:211::1)
| 3 14.958 ms 14.545 ms 14.491 ms adm-sara-s1-link.telia.net (2001:2000:3080:1b9::1)
| 4 100.264 ms 98.142 ms 96.88 ms bost-b1-v6.telia.net (2001:2000:3018:84::1)
| 5 100.025 ms 99.481 ms 99.407 ms internap-ic-304640-bost-b1.c.telia.net (2001:2000:3080:93b::2)
| 6 99.018 ms 96.084 ms 96.45 ms mpr1-bbnet2.bsn004.pnap.net (2600:c0d:0:102:0:4:2:1)
| 7 97.877 ms 98.276 ms 97.876 ms 2600:c0d:4002:3::2
| 8 97.982 ms 100.547 ms 98.163 ms likho.canonical.com (2001:67c:1562::15)

| core1.fra1.he.net> traceroute ipv6 2001:67c:1562::15 numeric
| Hop Packet 1 Packet 2 Packet 3 Hostname
| 1 25 ms <1 ms <1 ms as1299.gige-g2-9.core1.fra1.he.net (2001:470:0:168::2)
| 2 98 ms 99 ms 120 ms bost-b1-v6.telia.net (2001:2000:3018:84::1)
| 3 111 ms 99 ms 99 ms internap-ic-304640-bost-b1.c.telia.net (2001:2000:3080:93b::2)
| 4 98 ms 98 ms 98 ms mpr1-bbnet1.bsn004.pnap.net (2600:c0d:0:101:0:4:2:1)
| 5 99 ms 98 ms 99 ms 2600:c0d:4002:3::2
| 6 107 ms 151 ms 120 ms likho.canonical.com (2001:67c:1562::15)

| core1.prg1.he.net> traceroute ipv6 2001:67c:1562::15 numeric
| Hop Packet 1 Packet 2 Packet 3 Hostname
| 1 8 ms 17 ms 17 ms 100ge8-1.core1.fra1.he.net (2001:470:0:213::1)
| 2 8 ms 17 ms 7 ms as1299.gige-g2-9.core1.fra1.he.net (2001:470:0:168::2)
| 3 100 ms 100 ms 100 ms bost-b1-v6.telia.net (2001:2000:3018:84::1)
| 4 103 ms 111 ms 103 ms internap-ic-304640-bost-b1.c.telia.net (2001:2000:3080:93b::2)
| 5 102 ms 102 ms 102 ms mpr1-bbnet1.bsn004.pnap.net (2600:c0d:0:101:0:4:2:1)
| 6 103 ms 113 ms 102 ms 2600:c0d:4002:3::2
| 7 103 ms 103 ms 103 ms likho.canonical.com (2001:67c:1562::15)

[hgre (hendrik-grewe)]

Ffrom Germany (Telekom)

for i in $(dig +short security.ubuntu.com AAAA); do ping6 -w5 $i; done
PING 2001:67c:1562::13(2001:67c:1562::13) 56 data bytes
64 bytes from 2001:67c:1562::13: icmp_seq=1 ttl=56 time=113 ms
64 bytes from 2001:67c:1562::13: icmp_seq=2 ttl=56 time=114 ms
64 bytes from 2001:67c:1562::13: icmp_seq=3 ttl=56 time=117 ms
64 bytes from 2001:67c:1562::13: icmp_seq=4 ttl=56 time=114 ms
64 bytes from 2001:67c:1562::13: icmp_seq=5 ttl=56 time=115 ms

--- 2001:67c:1562::13 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 113.034/114.825/117.442/1.524 ms
PING 2001:67c:1562::14(2001:67c:1562::14) 56 data bytes
64 bytes from 2001:67c:1562::14: icmp_seq=1 ttl=56 time=119 ms
64 bytes from 2001:67c:1562::14: icmp_seq=2 ttl=56 time=117 ms
64 bytes from 2001:67c:1562::14: icmp_seq=3 ttl=56 time=117 ms
64 bytes from 2001:67c:1562::14: icmp_seq=4 ttl=56 time=116 ms
64 bytes from 2001:67c:1562::14: icmp_seq=5 ttl=56 time=116 ms

--- 2001:67c:1562::14 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 116.077/117.469/119.784/1.385 ms
PING 2001:67c:1562::16(2001:67c:1562::16) 56 data bytes
64 bytes from 2001:67c:1562::16: icmp_seq=1 ttl=52 time=118 ms
64 bytes from 2001:67c:1562::16: icmp_seq=2 ttl=52 time=117 ms
64 bytes from 2001:67c:1562::16: icmp_seq=3 ttl=52 time=117 ms
64 bytes from 2001:67c:1562::16: icmp_seq=4 ttl=52 time=118 ms
64 bytes from 2001:67c:1562::16: icmp_seq=5 ttl=52 time=119 ms

--- 2001:67c:1562::16 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4001ms
rtt min/avg/max/mdev = 117.036/118.172/119.028/0.813 ms
PING 2001:67c:1560:8001::11(2001:67c:1560:8001::11) 56 data bytes
From 2003:0:1306:8000::1 icmp_seq=2 Destination unreachable: Address unreachable

--- 2001:67c:1560:8001::11 ping statistics ---
2 packets transmitted, 0 received, +1 errors, 100% packet loss, time 1007ms

PING 2001:67c:1360:8c01::18(2001:67c:1360:8c01::18) 56 data bytes

--- 2001:67c:1360:8c01::18 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 4999ms

PING 2001:67c:1562::17(2001:67c:1562::17) 56 data bytes
64 bytes from 2001:67c:1562::17: icmp_seq=1 ttl=52 time=114 ms
64 bytes from 2001:67c:1562::17: icmp_seq=2 ttl=52 time=113 ms
64 bytes from 2001:67c:1562::17: icmp_seq=3 ttl=52 time=114 ms
64 bytes from 2001:67c:1562::17: icmp_seq=4 ttl=52 time=114 ms
64 bytes from 2001:67c:1562::17: icmp_seq=5 ttl=52 time=113 ms

--- 2001:67c:1562::17 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4002ms
rtt min/avg/max/mdev = 113.474/114.096/114.685/0.605 ms
PING 2001:67c:1562::15(2001:67c:1562::15) 56 data bytes
64 bytes from 2001:67c:1562::15: icmp_seq=1 ttl=56 time=341 ms
64 bytes from 2001:67c:1562::15: icmp_seq=2 ttl=56 time=345 ms
64 bytes from 2001:67c:1562::15: icmp_seq=3 ttl=56 time=308 ms
64 bytes from 2001:67c:1562::15: icmp_seq=4 ttl=56 time=323 ms
64 bytes from 2001:67c:1562::15: icmp_seq=5 ttl=56 time=415 ms

--- 2001:67c:1562::15 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4001ms
rtt min/avg/max/mdev = 308.320/346.775/415....

[Jared Fernandez (jared-fernandez)]

I'm using native dual-stack and not Hurricane Electric and I'm also not able to download from any of the IPv6 repos. I can ping them, but apt is not able to use them.

[Paul Gear (paulgear)]

To any future readers of this bug: please do not add further comments here; instead, paste the output of the following commands into http://pastebin.ubuntu.com/:

- ip -6 address
- ip -6 route
- host security.ubuntu.com # [or nslookup/dig if you don't have bind9-host installed]
- mtr -r -c 10 [a working address]
- mtr -r -c 10 [a non-working address]

Then email <email address hidden> using the subject "security.ubuntu.com unreachable via IPv6", and provide a link to your pastebin results.

(If your problem relates to another site, please substitute its name for security.ubuntu.com in the email subject and mtr command above.)

[Ivan Denkov (idenkov)]

I will add comment.

I just spin up a server on Linode, and stuck on security server - 0% [Connecting to security.ubuntu.com (2001:67c:1562::19)]

This is a joke, and then you want me to send you mails while you are having working bugtracker where problems never get resolved.

I should just use centos like sane person.

I am salty because this is not the first problem I am trying to help to be resolved, and this one looks like every other - no activity at all. For like, at least half a year.

[Robie Basak (racb)]

> and then you want me to send you mails while you are having working bugtracker where problems never get resolved.

This is an infrastructure operational issue, not a bug in the update-manager package in Ubuntu. This bug tracker is used to track bugs in Ubuntu itself, not infrastructure issues. Canonical IS (the operational infrastructure department at Canonical) do not use Launchpad bugs to track their issues. They use RT, a ticketing system designed to help track this kind of problem. And Paul has made it clear how to raise a ticket in this system in his comment above.

My Linode server can reach 2001:67c:1562::19 just fine, so it isn't clear if this is an issue at Linode, at Canonical, or somewhere in between. Our operational guys are willing to help resolve this, but if you can't even be bothered to raise a ticket with them, it isn't reasonable for you to expect your problem to be solved.

I should have marked this bug as Invalid, but I have not because I thought it would be helpful to users to leave it open. Apparently this is not the case, so I'm marking it Invalid now to make it clear that:

1) Commenting on this bug isn't going to help; contact Canonical IS as instructed in comment 17 above instead.

2) This is not a bug in the update-manager package in Ubuntu, so there is nothing to fix there.

You may still comment on this bug if you'd like to communicate with other people affected by this; but do not expect anyone at Canonical to read it. For that, contact Canonical IS as explained in comment 17 above.

> I am salty because this is not the first problem I am trying to help to be resolved, and this one looks like every other - no activity at all.

Because, as explained, you aren't raising your issue in the right place.