| 2016-12-23 17:09:58 |
Paul Graydon |
bug |
|
|
added bug |
| 2016-12-23 17:30:10 |
Brad Figg |
affects |
linux-meta (Ubuntu) |
linux (Ubuntu) |
|
| 2016-12-23 17:43:25 |
Paul Graydon |
attachment added |
|
4.4.0-57 "broken" initrd https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1652348/+attachment/4795793/+files/initrd.img-4.4.0-57-generic |
|
| 2016-12-23 17:52:26 |
Paul Graydon |
attachment added |
|
Working 4.4.0-53 initrd https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1652348/+attachment/4795794/+files/initrd.img-4.4.0-53-generic |
|
| 2016-12-23 18:01:05 |
Brad Figg |
linux (Ubuntu): status |
New |
Incomplete |
|
| 2016-12-23 18:10:07 |
Paul Graydon |
attachment added |
|
pcap from dhcp server side of 'ipconfig -t "dhcp" -d "ens2f0" ' https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1652348/+attachment/4795819/+files/worked.pcap |
|
| 2016-12-23 18:10:42 |
Paul Graydon |
attachment added |
|
pcap from dhcp server side of inird startup doing dhcp https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1652348/+attachment/4795820/+files/failed.pcap |
|
| 2016-12-23 20:39:29 |
Paul Graydon |
linux (Ubuntu): status |
Incomplete |
Confirmed |
|
| 2016-12-25 00:16:04 |
penalvch |
linux (Ubuntu): importance |
Undecided |
Low |
|
| 2016-12-25 00:16:04 |
penalvch |
linux (Ubuntu): status |
Confirmed |
Incomplete |
|
| 2016-12-26 21:53:44 |
Paul Graydon |
tags |
|
kernel-fixed-upstream |
|
| 2016-12-26 21:54:26 |
Paul Graydon |
tags |
kernel-fixed-upstream |
kernel-fixed-upstream kernel-fixed-upstream-4.10-rc1 |
|
| 2016-12-26 21:55:14 |
Paul Graydon |
linux (Ubuntu): status |
Incomplete |
Confirmed |
|
| 2016-12-27 03:03:53 |
penalvch |
tags |
kernel-fixed-upstream kernel-fixed-upstream-4.10-rc1 |
kernel-fixed-upstream kernel-fixed-upstream-4.10-rc1 needs-reverse-bisect |
|
| 2016-12-27 03:04:01 |
penalvch |
tags |
kernel-fixed-upstream kernel-fixed-upstream-4.10-rc1 needs-reverse-bisect |
kernel-fixed-upstream kernel-fixed-upstream-4.10-rc1 needs-reverse-bisect regression-update |
|
| 2016-12-27 03:05:42 |
penalvch |
linux (Ubuntu): status |
Confirmed |
Incomplete |
|
| 2016-12-30 18:51:05 |
penalvch |
tags |
kernel-fixed-upstream kernel-fixed-upstream-4.10-rc1 needs-reverse-bisect regression-update |
kernel-fixed-upstream kernel-fixed-upstream-4.10-rc1 regression-update reverse-bisect-done |
|
| 2016-12-30 18:51:11 |
penalvch |
tags |
kernel-fixed-upstream kernel-fixed-upstream-4.10-rc1 regression-update reverse-bisect-done |
cherry-pick kernel-fixed-upstream kernel-fixed-upstream-4.10-rc1 regression-update reverse-bisect-done |
|
| 2016-12-30 18:54:53 |
penalvch |
tags |
cherry-pick kernel-fixed-upstream kernel-fixed-upstream-4.10-rc1 regression-update reverse-bisect-done |
bisect-done kernel-bug-exists-upstream kernel-bug-exists-upstream-4.10-rc1 regression-update |
|
| 2016-12-30 19:18:51 |
penalvch |
linux (Ubuntu): importance |
Low |
High |
|
| 2016-12-30 19:18:51 |
penalvch |
linux (Ubuntu): status |
Incomplete |
Triaged |
|
| 2016-12-30 19:20:49 |
penalvch |
description |
Between kernel versions 4.4.0-53 and 4.4.0-57 a bug has been (re?)introduced that is breaking dhcp booting in the initrd environment. This is stopping instances that use iscsi storage from being able to connect.
Over serial console it outputs:
IP-Config: no response after 2 secs - giving up
IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
IP-Config: ens2f1 hardware address 90:e2:ba:d1:36:39 mtu 1500 DHCP RARP
IP-Config: no response after 3 secs - giving up
with increasing delays until it fails. At which point a simple ipconfig -t dhcp -d "ens2f0" works. The console output is slightly garbled but should give you an idea:
(initramfs) ipconfig -t dhcp -[ 728.379793] ixgbe 0000:13:00.0 ens2f0: changing MTU from 1500 to 9000
d "ens2f0"
IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
IP-Config: ens2f0 guessed broadcast address 10.0.1.255
IP-Config: ens2f0 complete (dhcp from 169.254.169.254):
addres[ 728.980448] ixgbe 0000:13:00.0 ens2f0: detected SFP+: 3
s: 10.0.1.56 broadcast: 10.0.1.255 netmask: 255.255.255.0
gateway: 10.0.1.1 [ 729.148410] ixgbe 0000:13:00.0 ens2f0: NIC Link is Up 10 Gbps, Flow Control: RX/TX
dns0 : 169.254.169.254 dns1 : 0.0.0.0
rootserver: 169.254.169.254 rootpath:
filename : /ipxe.efi
tcpdumps show that dhcp requests are being received from the host, and responses sent, but not accepted by the host. When the ipconfig command is issued manually, an identical dhcp request and response happens, only this time it is accepted. It doesn't appear to be that the messages are being sent and received incorrectly, just silently ignored by ipconfig.
I was seeing this behaviour earlier this year, which I was able to fix by specifying "ip=dhcp" as a kernel parameter. About a month ago that was identified as causing us other problems (long story) and we dropped it, at which point we discovered the original bug was no longer an issue.
Putting "ip=dhcp" back on with this kernel no longer fixes the problem.
I've compared the two initrds and effectively the only thing that has changed between the two is the kernel components.
I'm going to try and track back through kernel versions to see if I can find which version the fix happened in to maybe provide some additional context. I'll also attach copies of the initrds, packet captures etc. |
Between kernel versions 4.4.0-53 and 4.4.0-57 a bug has been (re?)introduced that is breaking dhcp booting in the initrd environment. This is stopping instances that use iscsi storage from being able to connect.
Over serial console it outputs:
IP-Config: no response after 2 secs - giving up
IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
IP-Config: ens2f1 hardware address 90:e2:ba:d1:36:39 mtu 1500 DHCP RARP
IP-Config: no response after 3 secs - giving up
with increasing delays until it fails. At which point a simple ipconfig -t dhcp -d "ens2f0" works. The console output is slightly garbled but should give you an idea:
(initramfs) ipconfig -t dhcp -[ 728.379793] ixgbe 0000:13:00.0 ens2f0: changing MTU from 1500 to 9000
d "ens2f0"
IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
IP-Config: ens2f0 guessed broadcast address 10.0.1.255
IP-Config: ens2f0 complete (dhcp from 169.254.169.254):
addres[ 728.980448] ixgbe 0000:13:00.0 ens2f0: detected SFP+: 3
s: 10.0.1.56 broadcast: 10.0.1.255 netmask: 255.255.255.0
gateway: 10.0.1.1 [ 729.148410] ixgbe 0000:13:00.0 ens2f0: NIC Link is Up 10 Gbps, Flow Control: RX/TX
dns0 : 169.254.169.254 dns1 : 0.0.0.0
rootserver: 169.254.169.254 rootpath:
filename : /ipxe.efi
tcpdumps show that dhcp requests are being received from the host, and responses sent, but not accepted by the host. When the ipconfig command is issued manually, an identical dhcp request and response happens, only this time it is accepted. It doesn't appear to be that the messages are being sent and received incorrectly, just silently ignored by ipconfig.
I was seeing this behaviour earlier this year, which I was able to fix by specifying "ip=dhcp" as a kernel parameter. About a month ago that was identified as causing us other problems (long story) and we dropped it, at which point we discovered the original bug was no longer an issue.
Putting "ip=dhcp" back on with this kernel no longer fixes the problem.
I've compared the two initrds and effectively the only thing that has changed between the two is the kernel components.
Offending commit:
# first bad commit: [fd4b5fa6e3487d15ede746f92601af008b2abbc0] mnt: Add a per mount namespace limit on the number of mounts
The offending commit submission:
https://lkml.org/lkml/2016/10/5/308 |
|
| 2016-12-30 19:22:58 |
penalvch |
tags |
bisect-done kernel-bug-exists-upstream kernel-bug-exists-upstream-4.10-rc1 regression-update |
bisect-done kernel-bug-exists-upstream kernel-bug-exists-upstream-4.10-rc1 regression-update xenial |
|
| 2016-12-31 12:21:29 |
penalvch |
linux (Ubuntu): status |
Triaged |
Incomplete |
|
| 2016-12-31 17:22:53 |
penalvch |
tags |
bisect-done kernel-bug-exists-upstream kernel-bug-exists-upstream-4.10-rc1 regression-update xenial |
downstream-bisect-done kernel-bug-exists-upstream kernel-bug-exists-upstream-4.10-rc1 needs-upstream-bisect regression-update xenial |
|
| 2016-12-31 17:23:27 |
penalvch |
description |
Between kernel versions 4.4.0-53 and 4.4.0-57 a bug has been (re?)introduced that is breaking dhcp booting in the initrd environment. This is stopping instances that use iscsi storage from being able to connect.
Over serial console it outputs:
IP-Config: no response after 2 secs - giving up
IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
IP-Config: ens2f1 hardware address 90:e2:ba:d1:36:39 mtu 1500 DHCP RARP
IP-Config: no response after 3 secs - giving up
with increasing delays until it fails. At which point a simple ipconfig -t dhcp -d "ens2f0" works. The console output is slightly garbled but should give you an idea:
(initramfs) ipconfig -t dhcp -[ 728.379793] ixgbe 0000:13:00.0 ens2f0: changing MTU from 1500 to 9000
d "ens2f0"
IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
IP-Config: ens2f0 guessed broadcast address 10.0.1.255
IP-Config: ens2f0 complete (dhcp from 169.254.169.254):
addres[ 728.980448] ixgbe 0000:13:00.0 ens2f0: detected SFP+: 3
s: 10.0.1.56 broadcast: 10.0.1.255 netmask: 255.255.255.0
gateway: 10.0.1.1 [ 729.148410] ixgbe 0000:13:00.0 ens2f0: NIC Link is Up 10 Gbps, Flow Control: RX/TX
dns0 : 169.254.169.254 dns1 : 0.0.0.0
rootserver: 169.254.169.254 rootpath:
filename : /ipxe.efi
tcpdumps show that dhcp requests are being received from the host, and responses sent, but not accepted by the host. When the ipconfig command is issued manually, an identical dhcp request and response happens, only this time it is accepted. It doesn't appear to be that the messages are being sent and received incorrectly, just silently ignored by ipconfig.
I was seeing this behaviour earlier this year, which I was able to fix by specifying "ip=dhcp" as a kernel parameter. About a month ago that was identified as causing us other problems (long story) and we dropped it, at which point we discovered the original bug was no longer an issue.
Putting "ip=dhcp" back on with this kernel no longer fixes the problem.
I've compared the two initrds and effectively the only thing that has changed between the two is the kernel components.
Offending commit:
# first bad commit: [fd4b5fa6e3487d15ede746f92601af008b2abbc0] mnt: Add a per mount namespace limit on the number of mounts
The offending commit submission:
https://lkml.org/lkml/2016/10/5/308 |
Between kernel versions 4.4.0-53 and 4.4.0-57 a bug has been (re?)introduced that is breaking dhcp booting in the initrd environment. This is stopping instances that use iscsi storage from being able to connect.
Over serial console it outputs:
IP-Config: no response after 2 secs - giving up
IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
IP-Config: ens2f1 hardware address 90:e2:ba:d1:36:39 mtu 1500 DHCP RARP
IP-Config: no response after 3 secs - giving up
with increasing delays until it fails. At which point a simple ipconfig -t dhcp -d "ens2f0" works. The console output is slightly garbled but should give you an idea:
(initramfs) ipconfig -t dhcp -[ 728.379793] ixgbe 0000:13:00.0 ens2f0: changing MTU from 1500 to 9000
d "ens2f0"
IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
IP-Config: ens2f0 guessed broadcast address 10.0.1.255
IP-Config: ens2f0 complete (dhcp from 169.254.169.254):
addres[ 728.980448] ixgbe 0000:13:00.0 ens2f0: detected SFP+: 3
s: 10.0.1.56 broadcast: 10.0.1.255 netmask: 255.255.255.0
gateway: 10.0.1.1 [ 729.148410] ixgbe 0000:13:00.0 ens2f0: NIC Link is Up 10 Gbps, Flow Control: RX/TX
dns0 : 169.254.169.254 dns1 : 0.0.0.0
rootserver: 169.254.169.254 rootpath:
filename : /ipxe.efi
tcpdumps show that dhcp requests are being received from the host, and responses sent, but not accepted by the host. When the ipconfig command is issued manually, an identical dhcp request and response happens, only this time it is accepted. It doesn't appear to be that the messages are being sent and received incorrectly, just silently ignored by ipconfig.
I was seeing this behaviour earlier this year, which I was able to fix by specifying "ip=dhcp" as a kernel parameter. About a month ago that was identified as causing us other problems (long story) and we dropped it, at which point we discovered the original bug was no longer an issue.
Putting "ip=dhcp" back on with this kernel no longer fixes the problem.
I've compared the two initrds and effectively the only thing that has changed between the two is the kernel components.
Ubuntu kernel bisect offending commit:
# first bad commit: [fd4b5fa6e3487d15ede746f92601af008b2abbc0] mnt: Add a per mount namespace limit on the number of mounts
Ubuntu kernel bisect offending commit submission:
https://lkml.org/lkml/2016/10/5/308 |
|
| 2017-01-05 19:11:42 |
Joseph Salisbury |
tags |
downstream-bisect-done kernel-bug-exists-upstream kernel-bug-exists-upstream-4.10-rc1 needs-upstream-bisect regression-update xenial |
downstream-bisect-done kernel-bug-exists-upstream kernel-bug-exists-upstream-4.10-rc1 kernel-da-key needs-upstream-bisect regression-update xenial |
|
| 2017-01-09 19:48:38 |
Jay Vosburgh |
bug |
|
|
added subscriber Jay Vosburgh |
| 2017-01-09 20:02:51 |
Eric Desrochers |
bug |
|
|
added subscriber Eric Desrochers |
| 2017-01-09 20:29:56 |
Joseph Salisbury |
tags |
downstream-bisect-done kernel-bug-exists-upstream kernel-bug-exists-upstream-4.10-rc1 kernel-da-key needs-upstream-bisect regression-update xenial |
downstream-bisect-done kernel-bug-exists-upstream kernel-bug-exists-upstream-4.10-rc1 kernel-key needs-upstream-bisect regression-update xenial |
|
| 2017-01-09 20:59:27 |
Joseph Salisbury |
linux (Ubuntu): status |
Incomplete |
Triaged |
|
| 2017-01-09 20:59:36 |
Joseph Salisbury |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-01-09 20:59:36 |
Joseph Salisbury |
bug task added |
|
linux (Ubuntu Xenial) |
|
| 2017-01-09 20:59:42 |
Joseph Salisbury |
linux (Ubuntu Xenial): importance |
Undecided |
High |
|
| 2017-01-09 20:59:46 |
Joseph Salisbury |
linux (Ubuntu Xenial): status |
New |
Triaged |
|
| 2017-01-11 02:46:44 |
Jay Vosburgh |
tags |
downstream-bisect-done kernel-bug-exists-upstream kernel-bug-exists-upstream-4.10-rc1 kernel-key needs-upstream-bisect regression-update xenial |
downstream-bisect-done kernel-bug-exists-upstream kernel-bug-exists-upstream-4.10-rc1 needs-upstream-bisect regression-update xenial |
|
| 2017-01-11 02:50:50 |
Jay Vosburgh |
affects |
linux (Ubuntu) |
klibc (Ubuntu) |
|
| 2017-01-11 02:50:50 |
Jay Vosburgh |
klibc (Ubuntu): status |
Triaged |
Confirmed |
|
| 2017-01-11 02:50:50 |
Jay Vosburgh |
klibc (Ubuntu): assignee |
|
Jay Vosburgh (jvosburgh) |
|
| 2017-01-12 02:34:14 |
Jay Vosburgh |
klibc (Ubuntu): status |
Confirmed |
In Progress |
|
| 2017-01-12 02:35:55 |
Jay Vosburgh |
tags |
downstream-bisect-done kernel-bug-exists-upstream kernel-bug-exists-upstream-4.10-rc1 needs-upstream-bisect regression-update xenial |
downstream-bisect-done needs-upstream-bisect regression-update xenial |
|
| 2017-01-20 20:14:58 |
Jay Vosburgh |
attachment added |
|
klibc-fix-1.patch https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1652348/+attachment/4806861/+files/klibc-fix-1.patch |
|
| 2017-01-20 20:32:47 |
Ubuntu Foundations Team Bug Bot |
tags |
downstream-bisect-done needs-upstream-bisect regression-update xenial |
downstream-bisect-done needs-upstream-bisect patch regression-update xenial |
|
| 2017-01-20 20:33:02 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Review Team |
| 2017-01-24 20:20:54 |
Steve Langasek |
description |
Between kernel versions 4.4.0-53 and 4.4.0-57 a bug has been (re?)introduced that is breaking dhcp booting in the initrd environment. This is stopping instances that use iscsi storage from being able to connect.
Over serial console it outputs:
IP-Config: no response after 2 secs - giving up
IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
IP-Config: ens2f1 hardware address 90:e2:ba:d1:36:39 mtu 1500 DHCP RARP
IP-Config: no response after 3 secs - giving up
with increasing delays until it fails. At which point a simple ipconfig -t dhcp -d "ens2f0" works. The console output is slightly garbled but should give you an idea:
(initramfs) ipconfig -t dhcp -[ 728.379793] ixgbe 0000:13:00.0 ens2f0: changing MTU from 1500 to 9000
d "ens2f0"
IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
IP-Config: ens2f0 guessed broadcast address 10.0.1.255
IP-Config: ens2f0 complete (dhcp from 169.254.169.254):
addres[ 728.980448] ixgbe 0000:13:00.0 ens2f0: detected SFP+: 3
s: 10.0.1.56 broadcast: 10.0.1.255 netmask: 255.255.255.0
gateway: 10.0.1.1 [ 729.148410] ixgbe 0000:13:00.0 ens2f0: NIC Link is Up 10 Gbps, Flow Control: RX/TX
dns0 : 169.254.169.254 dns1 : 0.0.0.0
rootserver: 169.254.169.254 rootpath:
filename : /ipxe.efi
tcpdumps show that dhcp requests are being received from the host, and responses sent, but not accepted by the host. When the ipconfig command is issued manually, an identical dhcp request and response happens, only this time it is accepted. It doesn't appear to be that the messages are being sent and received incorrectly, just silently ignored by ipconfig.
I was seeing this behaviour earlier this year, which I was able to fix by specifying "ip=dhcp" as a kernel parameter. About a month ago that was identified as causing us other problems (long story) and we dropped it, at which point we discovered the original bug was no longer an issue.
Putting "ip=dhcp" back on with this kernel no longer fixes the problem.
I've compared the two initrds and effectively the only thing that has changed between the two is the kernel components.
Ubuntu kernel bisect offending commit:
# first bad commit: [fd4b5fa6e3487d15ede746f92601af008b2abbc0] mnt: Add a per mount namespace limit on the number of mounts
Ubuntu kernel bisect offending commit submission:
https://lkml.org/lkml/2016/10/5/308 |
[SRU justification]
Changes to ordering of kernel enumeration of network interfaces, which may happen in any release, can regress network configuration from an initramfs. Support for netbooting should not depend on interface order, it should work reliably on all systems.
[Test case]
Detailed reproducer described in
<https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1652348/comments/35>.
[Regression potential]
Moderate regression potential, because of a relatively large patch touching a not-widely-used but still critical piece of code. Regression testing should include verifying that MAAS-booted cloud images still work as expected in a variety of environments.
Between kernel versions 4.4.0-53 and 4.4.0-57 a bug has been (re?)introduced that is breaking dhcp booting in the initrd environment. This is stopping instances that use iscsi storage from being able to connect.
Over serial console it outputs:
IP-Config: no response after 2 secs - giving up
IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
IP-Config: ens2f1 hardware address 90:e2:ba:d1:36:39 mtu 1500 DHCP RARP
IP-Config: no response after 3 secs - giving up
with increasing delays until it fails. At which point a simple ipconfig -t dhcp -d "ens2f0" works. The console output is slightly garbled but should give you an idea:
(initramfs) ipconfig -t dhcp -[ 728.379793] ixgbe 0000:13:00.0 ens2f0: changing MTU from 1500 to 9000
d "ens2f0"
IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
IP-Config: ens2f0 guessed broadcast address 10.0.1.255
IP-Config: ens2f0 complete (dhcp from 169.254.169.254):
addres[ 728.980448] ixgbe 0000:13:00.0 ens2f0: detected SFP+: 3
s: 10.0.1.56 broadcast: 10.0.1.255 netmask: 255.255.255.0
gateway: 10.0.1.1 [ 729.148410] ixgbe 0000:13:00.0 ens2f0: NIC Link is Up 10 Gbps, Flow Control: RX/TX
dns0 : 169.254.169.254 dns1 : 0.0.0.0
rootserver: 169.254.169.254 rootpath:
filename : /ipxe.efi
tcpdumps show that dhcp requests are being received from the host, and responses sent, but not accepted by the host. When the ipconfig command is issued manually, an identical dhcp request and response happens, only this time it is accepted. It doesn't appear to be that the messages are being sent and received incorrectly, just silently ignored by ipconfig.
I was seeing this behaviour earlier this year, which I was able to fix by specifying "ip=dhcp" as a kernel parameter. About a month ago that was identified as causing us other problems (long story) and we dropped it, at which point we discovered the original bug was no longer an issue.
Putting "ip=dhcp" back on with this kernel no longer fixes the problem.
I've compared the two initrds and effectively the only thing that has changed between the two is the kernel components.
Ubuntu kernel bisect offending commit:
# first bad commit: [fd4b5fa6e3487d15ede746f92601af008b2abbc0] mnt: Add a per mount namespace limit on the number of mounts
Ubuntu kernel bisect offending commit submission:
https://lkml.org/lkml/2016/10/5/308 |
|
| 2017-01-24 20:55:09 |
Launchpad Janitor |
klibc (Ubuntu): status |
In Progress |
Fix Released |
|
| 2017-01-26 18:14:00 |
Brian Murray |
klibc (Ubuntu Yakkety): status |
New |
Fix Committed |
|
| 2017-01-26 18:14:03 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-01-26 18:14:10 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2017-01-26 18:14:17 |
Brian Murray |
tags |
downstream-bisect-done needs-upstream-bisect patch regression-update xenial |
downstream-bisect-done needs-upstream-bisect patch regression-update verification-needed xenial |
|
| 2017-01-26 18:15:58 |
Brian Murray |
klibc (Ubuntu Xenial): status |
Triaged |
Fix Committed |
|
| 2017-01-26 23:30:13 |
paz |
bug |
|
|
added subscriber paz |
| 2017-01-27 20:54:18 |
Brian Murray |
tags |
downstream-bisect-done needs-upstream-bisect patch regression-update verification-needed xenial |
downstream-bisect-done needs-upstream-bisect patch regression-update verification-done-xenial verification-needed xenial |
|
| 2017-02-09 04:01:03 |
Launchpad Janitor |
klibc (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2017-06-07 20:44:01 |
Eric Desrochers |
nominated for series |
|
Ubuntu Zesty |
|
| 2017-06-07 20:44:01 |
Eric Desrochers |
bug task added |
|
klibc (Ubuntu Zesty) |
|
| 2017-06-07 20:44:09 |
Eric Desrochers |
klibc (Ubuntu Zesty): status |
New |
Fix Released |
|
| 2017-06-13 15:05:16 |
Mathieu Trudel-Lapierre |
nominated for series |
|
Ubuntu Trusty |
|
| 2017-06-13 15:05:16 |
Mathieu Trudel-Lapierre |
bug task added |
|
klibc (Ubuntu Trusty) |
|
| 2017-06-13 15:05:30 |
Mathieu Trudel-Lapierre |
klibc (Ubuntu Trusty): assignee |
|
Mathieu Trudel-Lapierre (cyphermox) |
|
| 2017-06-13 15:05:33 |
Mathieu Trudel-Lapierre |
klibc (Ubuntu Trusty): status |
New |
In Progress |
|
| 2017-06-13 15:05:35 |
Mathieu Trudel-Lapierre |
klibc (Ubuntu Trusty): importance |
Undecided |
High |
|
| 2017-06-13 15:44:24 |
Steve Langasek |
klibc (Ubuntu Trusty): status |
In Progress |
Fix Committed |
|
| 2017-06-13 22:59:27 |
Mathieu Trudel-Lapierre |
tags |
downstream-bisect-done needs-upstream-bisect patch regression-update verification-done-xenial verification-needed xenial |
downstream-bisect-done needs-upstream-bisect patch regression-update verification-done-xenial verification-done-yakkety verification-needed xenial |
|
| 2017-06-14 00:08:19 |
Launchpad Janitor |
klibc (Ubuntu Yakkety): status |
Fix Committed |
Fix Released |
|
| 2017-06-23 20:45:28 |
Francis Ginther |
tags |
downstream-bisect-done needs-upstream-bisect patch regression-update verification-done-xenial verification-done-yakkety verification-needed xenial |
downstream-bisect-done needs-upstream-bisect patch regression-update verification-done-trusty verification-done-xenial verification-done-yakkety verification-needed xenial |
|
| 2017-06-23 22:39:11 |
penalvch |
removed subscriber Christopher M. Penalver |
|
|
|
| 2017-06-27 15:55:33 |
Launchpad Janitor |
klibc (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
