[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
A [ Regression potential ] section was added to the description.
@Łukasz Zemczak let me know if there are other details you would like.
Thank you!
** Description changed:
-
[Impact]
In some cases, ipconfig can take a longer time than the user-specified
timeouts, causing unexpected delays.
[Test Plan]
Any situation where ipconfig encounters an error sending the DHCP packet, it
will automatically set a delay of 10 seconds, which could be longer than the
user-specified timeout. It can be reproduced by creating a dummy interface and
attempting to run ipconfig on it with a timeout value of less than 10:
# ip link add eth1 type dummy
# date; /usr/lib/klibc/bin/ipconfig -t 2 eth1; date
Thu Nov 18 04:46:13 EST 2021
IP-Config: eth1 hardware address ae:e0:f5:9d:7e:00 mtu 1500 DHCP RARP
IP-Config: no response after 2 secs - giving up
Thu Nov 18 04:46:23 EST 2021
^ Notice above, ipconfig thinks that it waited 2 seconds, but the
timestamps show an actual delay of 10 seconds.
[Where problems could occur]
Please see reproduction steps above. We are seeing this in production too
(see comment #2).
[Other Info]
A patch to fix the issue is being proposed here. It is a safe fix - it only
checks before going into sleep that the timeout never exceeds the
user-requested value.
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again later"
at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end up
extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually used
never exceeds the user-specified timeout.
+
+
+ [ Regression potential ]
+
+ This change ensures that user-specified timeouts are never exceeded, which is
a problem that appears to happen only in case of interface errors.
+ It may be that someone is relying on current behaviour where they receive
DHCP offers after their specified timeout (but within the 10-second error
timeout). However, 1) that is buggy behaviour and should be exposed. Such a
user would need to update their specified timeout to make it long enough to
receive the DHCP offer (setting the timeout to 10 would keep the existing
behaviour). 2) I think it is unlikely that such a scenario exists at all. The
10-second timeout problem happens when there are problems with the interface
that prevent it from even sending out the DHCP request. I think it is very
unlikely (or even, impossible) that DHCP offers would be received on a dead
interface.
+
+ Based on the above points, I consider the regression potential to be
+ very low for this change. I do not expect anyone who is currently using
+ ipconfig successfully to notice this change.
+
+ I believe the only difference introduced by this is the reduction of
+ delays caused by dead or problematic network interfaces. Those error
+ delays are shortened such that they never exceeed user-specified
+ timeouts.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
Hello @Łukasz Zemczak
I understand your concern about breaking existing behaviour.
I would like to clarify 2 things:
1) The change introduced here only ensures that user-requested timeouts are
never exceeded. That means that if something is currently accepting DHCP offers
after the specified timeout has expired, then that is buggy behaviour. It would
make sense that such behaviour would change after this change. If such a user
exists, they would need to change their timeout values so as to be long enough
to receive the DHCP offer that they want. I think it makes sense that such
buggy behaviour would get exposed with this fix.
2) That said, I consider it very unlikely for that scenario to even exist. The
main reason is that the bug (going over the specified timeout) happens in the
case where there is a problem bringing up the interface, so the ipconfig logic
simply says "try again in 10 seconds" in that case, even if that 10 seconds is
longer than the entire specified timeout. Since this happens when there are
interface problems, it can be safely assumed that no DHCP offers will be
received anyway on that problematic interface (in fact, no DHCP request was
even sent out). These 10 seconds are just dead time, basically.
So I would consider it unlikely that anyone who is successfully using
ipconfig today would even notice a change. This patch should only affect
those 10-seconds delays caused by problematic interfaces not normal
functioning interfaces, (and even then, it would only affect them if the
user-specified timeout is less than 10 seconds).
I am not sure what you mean by how it differs from focal+. The last time
I checked, the timeout-bug was affecting ipconfig in both focal and
bionic (and upstream HEAD). However, we are only interested in Bionic
since Focal does not even use ipconfig it uses dhclient instead.
I will add a regression-potential section to the description with more
info. Thanks.
I will try to expand the regression-potential section with additional
info about this.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
Incomplete
Bug description:
[Impact]
In some cases, ipconfig can take a longer time than the user-specified
timeouts, causing unexpected delays.
[Test Plan]
Any situation where ipconfig encounters an error sending the DHCP packet, it
will automatically set a delay of 10 seconds, which could be longer than the
user-specified timeout. It can be reproduced by creating a dummy interface and
attempting to run ipconfig on it with a timeout value of less than 10:
# ip link add eth1 type dummy
# date; /usr/lib/klibc/bin/ipconfig -t 2 eth1; date
Thu Nov 18 04:46:13 EST 2021
IP-Config: eth1 hardware address ae:e0:f5:9d:7e:00 mtu 1500 DHCP RARP
IP-Config: no response after 2 secs - giving up
Thu Nov 18 04:46:23 EST 2021
^ Notice above, ipconfig thinks that it waited 2 seconds, but the
timestamps show an actual delay of 10 seconds.
[Where problems could occur]
Please see reproduction steps above. We are seeing this in production too
(see comment #2).
[Other Info]
A patch to fix the issue is being proposed here. It is a safe fix - it only
checks before going into sleep that the timeout never exceeds the
user-requested value.
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
[Touch-packages] [Bug 1964527] [NEW] Enable CONFIG_UNICODE for linux-gcp
Public bug reported: See https://lists.ubuntu.com/archives/kernel-team/2022-March/128565.html NOTE: This config is enabled in other gcp kernels and in non-gcp kernels. ** Affects: linux-gcp (Ubuntu) Importance: Undecided Assignee: Khaled El Mously (kmously) Status: New ** Affects: linux-gcp (Ubuntu Focal) Importance: Undecided Assignee: Khaled El Mously (kmously) Status: New ** Also affects: linux-gcp (Ubuntu) Importance: Undecided Status: New ** No longer affects: klibc (Ubuntu) ** Also affects: linux-gcp (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: linux-gcp (Ubuntu Focal) Assignee: (unassigned) => Khaled El Mously (kmously) ** Changed in: linux-gcp (Ubuntu) Assignee: (unassigned) => Khaled El Mously (kmously) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu. https://bugs.launchpad.net/bugs/1964527 Title: Enable CONFIG_UNICODE for linux-gcp Status in linux-gcp package in Ubuntu: New Status in linux-gcp source package in Focal: New Bug description: See https://lists.ubuntu.com/archives/kernel- team/2022-March/128565.html NOTE: This config is enabled in other gcp kernels and in non-gcp kernels. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-gcp/+bug/1964527/+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 1959173] [NEW] Vulnerability in af_packet handling
Public bug reported: CVE-2021-22600 A vulnerability, which was classified as critical, was found in Linux Kernel. Affected is the function packet_set_ring of the file net/packet/af_packet.c. The manipulation with an unknown input leads to a memory corruption vulnerability. This is going to have an impact on confidentiality, integrity, and availability. The weakness was released 01/26/2022. The advisory is shared for download at git.kernel.org. This vulnerability is traded as CVE-2021-22600 since 01/05/2021. The exploitability is told to be easy. It is possible to launch the attack remotely. A authentication is required for exploitation. There are known technical details, but no exploit is available. The current price for an exploit might be approx. USD $5k-$25k (estimation calculated on 01/26/2022). Applying a patch is able to eliminate this problem. The fix is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=ec6af094ea28f0f2dda1a6a33b14cd57e36a9755 More information at: https://partnerissuetracker.corp.google.com/issues/215427453 ** Affects: linux-gke (Ubuntu) Importance: Undecided Status: New ** Affects: linux-gke (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: linux-gke (Ubuntu) Importance: Undecided Status: New ** No longer affects: klibc (Ubuntu) ** Also affects: linux-gke (Ubuntu Focal) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu. https://bugs.launchpad.net/bugs/1959173 Title: Vulnerability in af_packet handling Status in linux-gke package in Ubuntu: New Status in linux-gke source package in Focal: New Bug description: CVE-2021-22600 A vulnerability, which was classified as critical, was found in Linux Kernel. Affected is the function packet_set_ring of the file net/packet/af_packet.c. The manipulation with an unknown input leads to a memory corruption vulnerability. This is going to have an impact on confidentiality, integrity, and availability. The weakness was released 01/26/2022. The advisory is shared for download at git.kernel.org. This vulnerability is traded as CVE-2021-22600 since 01/05/2021. The exploitability is told to be easy. It is possible to launch the attack remotely. A authentication is required for exploitation. There are known technical details, but no exploit is available. The current price for an exploit might be approx. USD $5k-$25k (estimation calculated on 01/26/2022). Applying a patch is able to eliminate this problem. The fix is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=ec6af094ea28f0f2dda1a6a33b14cd57e36a9755 More information at: https://partnerissuetracker.corp.google.com/issues/215427453 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-gke/+bug/1959173/+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 1957744] [NEW] Unable to set correct resolutions on virtual displays
Public bug reported: See https://canonical.lightning.force.com/lightning/r/Case/5004K09qFamQAE/view for more info ** Affects: linux-oracle (Ubuntu) Importance: Undecided Status: New ** Affects: linux-oracle (Ubuntu Hirsute) Importance: Undecided Status: New ** Affects: linux-oracle (Ubuntu Impish) Importance: Undecided Status: New ** Also affects: linux-oracle (Ubuntu) Importance: Undecided Status: New ** No longer affects: klibc (Ubuntu) ** Also affects: linux-oracle (Ubuntu Impish) Importance: Undecided Status: New ** Also affects: linux-oracle (Ubuntu Hirsute) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu. https://bugs.launchpad.net/bugs/1957744 Title: Unable to set correct resolutions on virtual displays Status in linux-oracle package in Ubuntu: New Status in linux-oracle source package in Hirsute: New Status in linux-oracle source package in Impish: New Bug description: See https://canonical.lightning.force.com/lightning/r/Case/5004K09qFamQAE/view for more info To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-oracle/+bug/1957744/+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 1953575] [NEW] Update gvnic driver code
Public bug reported: The GCE internal team responsible for gVNIC would like to have driver updates backported for both Ubuntu 18.04 LTS and Ubuntu 20.04 LTS. [Impact] Missing functionality from the Google gvnic driver [Test Plan] Confirm that gvnic module still loads and operates the gvnic driver. More extensive testing done by the gvnic developers at GCE [Regression potential] Possible regression in gvnic behaviour or functionality. Changes are confined to the gvnic driver code so regression potential is limited to gvnic only. List of changes: 3712db620c613 gve: DQO: Configure interrupts on device up a9fd7559a367a gve: Check TX QPL was actually assigned c69a8892d5836 gve: fix the wrong AdminQ buffer overflow check f48adc2842b17 gve: DQO: Remove incorrect prefetch 98fd04939ae7e gve: Simplify code and axe the use of a deprecated API 56c0904d8491d gve: Propagate error codes to caller 86cd2b58d1e63 gve: DQO: Fix off by one in gve_rx_dqo() ea364622fb118 gve: Fix warnings reported for DQO patchset 8890e8783c6e6 gve: DQO: Add RX path abfc55f80d423 gve: DQO: Add TX path ef63867982913 gve: DQO: Add ring allocation and initialization dc3e0aef11bf0 gve: DQO: Add core netdev features 873fd9825efd7 gve: Update adminq commands to support DQO queues 543dc0e670472 gve: Add DQO fields for core data structures b580730931348 gve: Add dqo descriptors 74e123d3c62b2 gve: Add support for DQO RX PTYPE map a9a3bfdd5f679 gve: adminq: DQO specific device descriptor logic 3e6d068c103f8 gve: Introduce per netdev `enum gve_queue_format` a6b09c93c1735 gve: Introduce a new model for device options 34d6b75678979 gve: Add support for raw addressing in the tx path 30b6221596699 Revert "gve: Check TX QPL was actually assigned" 98478993bb3f9 gve: Make gve_rx_slot_page_info.page_offset an absolute offset ff4b20bb7e5f4 gve: gve_rx_copy: Move padding to an argument 5fc5c482008b5 gve: Move some static functions to a common file ed1e0daeee1ac gve: Rx Buffer Recycling da57760d6370d gve: Add support for raw addressing to the rx path b512608f33d8e gve: Add support for raw addressing device option e85394c77cdce gve: Enable Link Speed Reporting in the driver. 8961791d8ba16 gve: Batch AQ commands for creating and destroying queues. 50bafd6d5a041 gve: NIC stats for report-stats and for ethtool feccb84085904 gve: Add Gvnic stats AQ command and ethtool show/set-priv-flags. 08578185ab296 gve: Use dev_info/err instead of netif_info/err. 613ed2d16246f gve: Add stats for gve. 250d220740d21 gve: Get and set Rx copybreak via ethtool ** Affects: linux-gcp (Ubuntu) Importance: Undecided Assignee: Khaled El Mously (kmously) Status: In Progress ** Affects: linux-gcp (Ubuntu Focal) Importance: Undecided Assignee: Khaled El Mously (kmously) Status: In Progress ** Also affects: linux-gcp (Ubuntu) Importance: Undecided Status: New ** No longer affects: klibc (Ubuntu) ** Description changed: The GCE internal team responsible for gVNIC would like to have driver updates backported for both Ubuntu 18.04 LTS and Ubuntu 20.04 LTS. + + + [Impact] + Missing functionality from the Google gvnic driver + + + [Test Plan] + Confirm that gvnic module still loads and operates the gvnic driver. More extensive testing done by the gvnic developers at GCE + + + [Regression potential] + Possible regression in gvnic behaviour or functionality. Changes are confined to the gvnic driver code so regression potential is limited to gvnic only. + + + + List of changes: + + 3712db620c613 gve: DQO: Configure interrupts on device up + a9fd7559a367a gve: Check TX QPL was actually assigned + c69a8892d5836 gve: fix the wrong AdminQ buffer overflow check + f48adc2842b17 gve: DQO: Remove incorrect prefetch + 98fd04939ae7e gve: Simplify code and axe the use of a deprecated API + 56c0904d8491d gve: Propagate error codes to caller + 86cd2b58d1e63 gve: DQO: Fix off by one in gve_rx_dqo() + ea364622fb118 gve: Fix warnings reported for DQO patchset + 8890e8783c6e6 gve: DQO: Add RX path + abfc55f80d423 gve: DQO: Add TX path + ef63867982913 gve: DQO: Add ring allocation and initialization + dc3e0aef11bf0 gve: DQO: Add core netdev features + 873fd9825efd7 gve: Update adminq commands to support DQO queues + 543dc0e670472 gve: Add DQO fields for core data structures + b580730931348 gve: Add dqo descriptors + 74e123d3c62b2 gve: Add support for DQO RX PTYPE map + a9a3bfdd5f679 gve: adminq: DQO specific device descriptor logic + 3e6d068c103f8 gve: Introduce per netdev `enum gve_queue_format` + a6b09c93c1735 gve: Introduce a new model for device options + 34d6b75678979 gve: Add support for raw addressing in the tx path + 30b6221596699 Revert "gve: Check TX QPL was actually assigned" + 98478993bb3f9 gve: Make gve_rx_slot_page_info.page_offset an absolute offset + ff4b20bb7e5f4 gve: gve_rx_copy: Move padding to an argument + 5fc5c482008b5 gve: Move some static functions to a common file + ed1e0daeee1ac gve:
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
Patch proposed upstream:
https://lists.zytor.com/archives/klibc/2021-December/004629.html
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
In Progress
Bug description:
[Impact]
In some cases, ipconfig can take a longer time than the user-specified
timeouts, causing unexpected delays.
[Test Plan]
Any situation where ipconfig encounters an error sending the DHCP packet, it
will automatically set a delay of 10 seconds, which could be longer than the
user-specified timeout. It can be reproduced by creating a dummy interface and
attempting to run ipconfig on it with a timeout value of less than 10:
# ip link add eth1 type dummy
# date; /usr/lib/klibc/bin/ipconfig -t 2 eth1; date
Thu Nov 18 04:46:13 EST 2021
IP-Config: eth1 hardware address ae:e0:f5:9d:7e:00 mtu 1500 DHCP RARP
IP-Config: no response after 2 secs - giving up
Thu Nov 18 04:46:23 EST 2021
^ Notice above, ipconfig thinks that it waited 2 seconds, but the
timestamps show an actual delay of 10 seconds.
[Where problems could occur]
Please see reproduction steps above. We are seeing this in production too
(see comment #2).
[Other Info]
A patch to fix the issue is being proposed here. It is a safe fix - it only
checks before going into sleep that the timeout never exceeds the
user-requested value.
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+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 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
(updated the bug description with further details according to the SRU
template, including reproduction steps)
** Description changed:
** SRU TEMPLATE DRAFT **
[Impact]
+ In some cases, ipconfig can take a longer time than the user-specified
timeouts, causing unexpected delays.
+
+ [Test Plan]
+ Any situation where ipconfig encounters an error sending the DHCP packet, it
will automatically set a delay of 10 seconds, which could be longer than the
user-specified timeout. It can be reproduced by creating a dummy interface and
attempting to run ipconfig on it with a timeout value of less than 10:
+
+ # ip link add eth1 type dummy
+ # date; /usr/lib/klibc/bin/ipconfig -t 2 eth1; date
+ Thu Nov 18 04:46:13 EST 2021
+ IP-Config: eth1 hardware address ae:e0:f5:9d:7e:00 mtu 1500 DHCP RARP
+ IP-Config: no response after 2 secs - giving up
+ Thu Nov 18 04:46:23 EST 2021
- [Test Plan]
+ ^ Notice above, ipconfig thinks that it waited 2 seconds, but the
+ timestamps show an actual delay of 10 seconds.
[Where problems could occur]
+ Please see reproduction steps above. We are seeing this in production too
(see comment #2).
[Other Info]
+ A patch to fix the issue is being proposed here. It is a safe fix - it only
checks before going into sleep that the timeout never exceeds the
user-requested value.
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again later"
at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end up
extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually used
never exceeds the user-specified timeout.
** Description changed:
- ** SRU TEMPLATE DRAFT **
[Impact]
In some cases, ipconfig can take a longer time than the user-specified
timeouts, causing unexpected delays.
[Test Plan]
Any situation where ipconfig encounters an error sending the DHCP packet, it
will automatically set a delay of 10 seconds, which could be longer than the
user-specified timeout. It can be reproduced by creating a dummy interface and
attempting to run ipconfig on it with a timeout value of less than 10:
# ip link add eth1 type dummy
# date; /usr/lib/klibc/bin/ipconfig -t 2 eth1; date
Thu Nov 18 04:46:13 EST 2021
IP-Config: eth1 hardware address ae:e0:f5:9d:7e:00 mtu 1500 DHCP RARP
IP-Config: no response after 2 secs - giving up
Thu Nov 18 04:46:23 EST 2021
-
^ Notice above, ipconfig thinks that it waited 2 seconds, but the
timestamps show an actual delay of 10 seconds.
-
[Where problems could occur]
Please see reproduction steps above. We are seeing this in production too
(see comment #2).
-
[Other Info]
A patch to fix the issue is being proposed here. It is a safe fix - it only
checks before going into sleep that the timeout never exceeds the
user-requested value.
-
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
Hello @Eric.
> What make Bionic more susceptible to this particular problem ? Bionic
kernel version in use ? else ?
I believe klibc/ipconfig itself is susceptible to the problem in Bionic
and Focal and elsewhere. However, Focal (which uses klibc 2.0.7) uses
dhclient for networking initialization instead of ipconfig, therefore I
am not really concerned about fixing the ipconfig issue in Focal since
it is not causing any noticeable problems.
I have checked the HEAD of the klibc project and it appears that
ipconfig is still susceptible to the timeout problem. Sure I can propose
the patch upstream if you like - however, even if they accept it I
believe we will still need to apply it separately for Bionic because I
do not expect that Bionic will receive any major updates for klibc, so
it will not get any upstream fixes. It will remain on 2.0.4 as far as I
know. It is currently version 2.0.4-9ubuntu2 in Bionic which means we
are carrying (2?) Ubuntu-specific patches on top of 2.0.4. I believe
this fix can be added as well to produce 2.0.4-9ubuntu3.
I will attempt to upstream this fix to klibc, but I believe the change
to Bionic should happen in parallel/independently since the upstream
patch will not make its way back to Bionic (which is stuck at 2.0.4, as
mentioned above).
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
** SRU TEMPLATE DRAFT **
[Impact]
[Test Plan]
[Where problems could occur]
[Other Info]
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+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 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
Hi @Eric - thanks for the follow-up and sorry for the delayed reply.
> I don't see this piece of code in the klibc upstream project[0]
Are you referring to the piece of code that I am suggesting as a fix? If
so, it makes sense that it doesn't exist elsewhere, which is why I am
suggesting it be incorporated into klibc. I have checked upstream klibc
2.0.4 which is the version that Bionic uses and it applies cleanly
there.
I am not sure that it would help us to get the fix upstreamed in a new
version of klibc since the problem is only affecting Bionic, and Bionic
uses klibc 2.0.4 + some Ubuntu changes. I assumed we can just add the
additional fix as another Ubuntu-specific change on top ?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
** SRU TEMPLATE DRAFT **
[Impact]
[Test Plan]
[Where problems could occur]
[Other Info]
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+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 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
For some background info, this issue is affecting one of the instance
types of a cloud partner. The instance has 18 physical ethernet
interfaces (bonded), but only one of which has a media connection. On
boot-up, ipconfig is called to do DHCP for all 18 devices. 17 of them
fail to send a DHCP request (because no media is connected), and so each
one ends up taking 10 seconds, even though the user-specified timeout
for each interface was only 2. This delays the entire boot-up sequence
by about 3 minutes.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in case of
error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had actually
waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+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 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
Adding a debdiff of the patch as well. I am not sure if I generated it
correctly though..
** Patch added: "Suggested patch that fixes the problem"
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+attachment/5532730/+files/honour-user-requested-timeouts-in-all-cases.patch
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in case of
error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had actually
waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+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 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
** Description changed:
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again later"
at time equal now + 10 seconds by setting
s->expire = now + 10;
-
- This can happen at any time during the main event loop, which can end up
extending the user-specified timeout if "now + 10" is greater than "start_time
+ user-specified-timeout".
+ This can happen at any time during the main event loop, which can end up
+ extending the user-specified timeout if "now + 10" is greater than
+ "start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
- if (timeout > s->expire - now.tv_sec)
- timeout = s->expire - now.tv_sec;
+ if (timeout > s->expire - now.tv_sec)
+ timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
- }
+ }
+
+
+ I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
+
+
+ if (loop_timeout >= 0 &&
+ now.tv_sec - start >= loop_timeout) {
+ printf("IP-Config: no response after %d "
+"secs - giving up\n", loop_timeout);
+ rc = -1;
+ goto bail;
+ }
+
+
+ 'loop_timeout' is the user-specified time-out. With a value of 2, in case of
error, this line prints:
+
+ IP-Config: no response after 2 secs - giving up
+
+
+ So it thinks that it waited 2 seconds - however, in reality it had actually
waited for 10 seconds.
+
+ The suggested code-change ensures that the timeout that is actually used
+ never exceeds the user-specified timeout.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in case of
error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had actually
waited f
[Touch-packages] [Bug 1947099] [NEW] ipconfig does not honour user-requested timeouts in some cases
Public bug reported:
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again later"
at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end up
extending the user-specified timeout if "now + 10" is greater than "start_time
+ user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request =
(%d s) \n", timeout);
+ }
}
** Affects: klibc (Ubuntu)
Importance: Undecided
Status: New
** Affects: klibc (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: klibc (Ubuntu Bionic)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end up
extending the user-specified timeout if "now + 10" is greater than "start_time
+ user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+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 1875665] Re: rtkit-daemon[*]: Failed to make ourselves RT: Operation not permitted after upgrade to 20.04
** Changed in: linux-azure (Ubuntu Focal) Status: New => Fix Committed ** Changed in: linux-gcp (Ubuntu Focal) Status: New => Fix Committed ** Changed in: linux-kvm (Ubuntu Focal) Status: New => Fix Committed ** Changed in: linux-oracle (Ubuntu Focal) Status: New => Fix Committed ** Changed in: linux-riscv (Ubuntu Focal) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rtkit in Ubuntu. https://bugs.launchpad.net/bugs/1875665 Title: rtkit-daemon[*]: Failed to make ourselves RT: Operation not permitted after upgrade to 20.04 Status in linux package in Ubuntu: Fix Committed Status in linux-azure package in Ubuntu: Invalid Status in linux-gcp package in Ubuntu: Invalid Status in linux-kvm package in Ubuntu: Invalid Status in linux-oracle package in Ubuntu: Invalid Status in linux-riscv package in Ubuntu: Invalid Status in rtkit package in Ubuntu: Confirmed Status in linux source package in Focal: Fix Committed Status in linux-azure source package in Focal: Fix Committed Status in linux-gcp source package in Focal: Fix Committed Status in linux-kvm source package in Focal: Fix Committed Status in linux-oracle source package in Focal: Fix Committed Status in linux-riscv source package in Focal: Fix Committed Status in rtkit source package in Focal: Confirmed Bug description: SRU Justification Impact: CONFIG_RT_GROUP_SCHED was enabled in focal, except for the lowlatency kernel since we expected most RT users to use that kernel. However we are getting RT regressions with the generic kernel. Digging deeper into this option, it seems to be pretty specialized and to require quite a bit of workload-specific configuration/tuning to be useful, so it doesn't really seem to make sense for a general-purpose kernel. Fix: Turn this option back off. Test Case: See comment #4. Regression Potential: This was turned on to support some docker functionality, so this functionality will no longer be available. We've had this option off for all releases prior to focal, so this seems acceptable. --- These errors started right after upgrading to 20.04. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: rtkit 0.12-4 ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30 Uname: Linux 5.4.0-26-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Tue Apr 28 10:31:43 2020 InstallationDate: Installed on 2019-06-18 (315 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) ProcEnviron: TERM=tmux-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: rtkit UpgradeStatus: Upgraded to focal on 2020-04-21 (6 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1875665/+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 1875665] Re: rtkit-daemon[*]: Failed to make ourselves RT: Operation not permitted after upgrade to 20.04
** Changed in: linux (Ubuntu Focal) Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rtkit in Ubuntu. https://bugs.launchpad.net/bugs/1875665 Title: rtkit-daemon[*]: Failed to make ourselves RT: Operation not permitted after upgrade to 20.04 Status in linux package in Ubuntu: Fix Committed Status in linux-azure package in Ubuntu: Invalid Status in linux-gcp package in Ubuntu: Invalid Status in linux-kvm package in Ubuntu: Invalid Status in linux-oracle package in Ubuntu: Invalid Status in linux-riscv package in Ubuntu: Invalid Status in rtkit package in Ubuntu: Confirmed Status in linux source package in Focal: Fix Committed Status in linux-azure source package in Focal: New Status in linux-gcp source package in Focal: New Status in linux-kvm source package in Focal: New Status in linux-oracle source package in Focal: New Status in linux-riscv source package in Focal: New Status in rtkit source package in Focal: Confirmed Bug description: SRU Justification Impact: CONFIG_RT_GROUP_SCHED was enabled in focal, except for the lowlatency kernel since we expected most RT users to use that kernel. However we are getting RT regressions with the generic kernel. Digging deeper into this option, it seems to be pretty specialized and to require quite a bit of workload-specific configuration/tuning to be useful, so it doesn't really seem to make sense for a general-purpose kernel. Fix: Turn this option back off. Test Case: See comment #4. Regression Potential: This was turned on to support some docker functionality, so this functionality will no longer be available. We've had this option off for all releases prior to focal, so this seems acceptable. --- These errors started right after upgrading to 20.04. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: rtkit 0.12-4 ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30 Uname: Linux 5.4.0-26-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Tue Apr 28 10:31:43 2020 InstallationDate: Installed on 2019-06-18 (315 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) ProcEnviron: TERM=tmux-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: rtkit UpgradeStatus: Upgraded to focal on 2020-04-21 (6 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1875665/+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 1860956] Re: network-manager 1.16.0-0ubuntu2 ADT test failure with linux 5.0.0-40.44
Thanks Sebastien. This is from Disco actually. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1860956 Title: network-manager 1.16.0-0ubuntu2 ADT test failure with linux 5.0.0-40.44 Status in network-manager package in Ubuntu: Incomplete Bug description: Testing failed on: ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/ppc64el/n/network-manager/20200124_174131_d1990@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1860956/+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 1860956] [NEW] network-manager 1.16.0-0ubuntu2 ADT test failure with linux 5.0.0-40.44
Public bug reported: Testing failed on: ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/ppc64el/n/network-manager/20200124_174131_d1990@/log.gz ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Tags: kernel-adt-failure ** Tags added: kernel-adt-failure -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1860956 Title: network-manager 1.16.0-0ubuntu2 ADT test failure with linux 5.0.0-40.44 Status in network-manager package in Ubuntu: New Bug description: Testing failed on: ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/ppc64el/n/network-manager/20200124_174131_d1990@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1860956/+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 1847536] [NEW] systemd 240-6ubuntu5.7 ADT test failure with linux-oracle 5.0.0-1004.8
Public bug reported: Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/s/systemd/20191009_032712_a8451@/log.gz ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: kernel-adt-failure ** Tags added: kernel-adt-failure -- 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/1847536 Title: systemd 240-6ubuntu5.7 ADT test failure with linux-oracle 5.0.0-1004.8 Status in systemd package in Ubuntu: New Bug description: Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/s/systemd/20191009_032712_a8451@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1847536/+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 1815172] Re: [bionic] drm/i915: softpin broken, needs to be fixed for 32bit mesa
** Changed in: mesa (Ubuntu Bionic) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1815172 Title: [bionic] drm/i915: softpin broken, needs to be fixed for 32bit mesa Status in Mesa: Fix Released Status in linux package in Ubuntu: Fix Released Status in mesa package in Ubuntu: Fix Released Status in linux source package in Bionic: In Progress Status in mesa source package in Bionic: Fix Committed Status in linux source package in Cosmic: Won't Fix Status in mesa source package in Cosmic: Fix Released Bug description: [Impact] Several schools reported black screens after normally updating their Ubuntu boxes from 18.0.5-0ubuntu0~18.04.1 to 18.2.2-0ubuntu1~18.04.1. Downgrading mesa fixes the problem. lspci: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:1912] (rev 06) Subsystem: ASUSTeK Computer Inc. HD Graphics 530 [1043:8694]Kernel modules: i915 Unfortunately I can't find a lot of useful information, here are some bits: * systemctl --failed says "gpu-manager" and "lightdm" have failed * Xorg.log is clean: https://termbin.com/6l2b * dmesg too: https://termbin.com/ip4e * It happens on lightdm/MATE, I don't know about Ubuntu GNOME. * If one runs `xinit` from ssh, it fails with: i965: Failed to submit batchbuffer: Invalid argument This is caused by mesa assuming that soft-pinning on GEN8+ is working since kernel 4.5, but in fact this issue wasn't fixed until 4.19.3. So a proper fix would be to backport commits from 4.19.3/4.20 to fix GTT sizes/pin flags, but that's left for future. [Test case] install fixed mesa or kernel, check that the regression is fixed [Regression potential] mesa: shouldn't be any, it just reverts the change to always soft-pin (TODO kernel: adds commits from upstream stable, which have been well tested upstream by now) To manage notifications about this bug go to: https://bugs.launchpad.net/mesa/+bug/1815172/+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 1818204] Re: Qualcomm Atheros QCA9377 wireless does not work
** Also affects: network-manager (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: network-manager (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Bionic) Status: New => Fix Committed ** Changed in: linux (Ubuntu Cosmic) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1818204 Title: Qualcomm Atheros QCA9377 wireless does not work Status in linux package in Ubuntu: Fix Committed Status in network-manager package in Ubuntu: Invalid Status in linux source package in Bionic: Fix Committed Status in network-manager source package in Bionic: New Status in linux source package in Cosmic: Fix Committed Status in network-manager source package in Cosmic: New Bug description: === SRU Justification === [Impact] Lenovo ideapad 530S-14ARR Wifi rfkill hard blocked [Fix] The platform in question doesn't have hardware RF switch, so quirk it off. [Test] User confirm it fixes the issue. [Regression Potential] Minimal. This fix is limited to one specific platform. === Original Bug Report === I have Lenovo 530s laptop with Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter (rev 31). The menu shows that wireless is off. Turning on the wireless from the menu does not do anything. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: network-manager 1.10.6-2ubuntu1.1 ProcVersionSignature: Ubuntu 4.18.0-15.16~18.04.1-generic 4.18.20 Uname: Linux 4.18.0-15-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Mar 1 11:42:34 2019 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2019-02-20 (8 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) IpRoute: default via 130.232.69.254 dev enx00e04c704f68 proto dhcp metric 100 130.232.69.0/24 dev enx00e04c704f68 proto kernel scope link src 130.232.69.176 metric 100 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-con: NAMEUUID TYPE TIMESTAMP TIMESTAMP-REALAUTOCONNECT AUTOCONNECT-PRIORITY READONLY DBUS-PATH ACTIVE DEVICE STATE ACTIVE-PATH SLAVE Wired connection 1 ada277fe-966d-33ff-aba2-8ba32d6ce5a9 ethernet 155143 pe 1. maaliskuuta 2019 11.42.13 yes 4294966297 no/org/freedesktop/NetworkManager/Settings/1 yes enx00e04c704f68 activated /org/freedesktop/NetworkManager/ActiveConnection/11 -- virbr0 dc46fe89-5b22-438a-85d5-37be48a077ea bridge 155143 pe 1. maaliskuuta 2019 11.42.13 no 0 no/org/freedesktop/NetworkManager/Settings/2 yes virbr0 activated /org/freedesktop/NetworkManager/ActiveConnection/1 -- nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.10.6 connected started full enabled enabled disabled enabled enabled --- ProblemType: Bug ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: sami 1315 F pulseaudio /dev/snd/controlC0: sami 1315 F pulseaudio CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 18.04 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2019-02-20 (11 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) IpRoute: default via 130.232.69.254 dev enx00e04c704f68 proto dhcp metric 100 130.232.69.0/24 dev enx00e04c704f68 proto kernel scope link src 130.232.69.176 metric 100 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown MachineType: LENOVO 81H1 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true Package: network-manager 1.10.6-2ubuntu1.1 PackageArchitecture: amd64 ProcFB: 0 amdgpudrmfb
[Touch-packages] [Bug 1802135] Re: broken touchpad after i2c-i801 blacklist change
Marking this as invalid for Xenial based on Aaron Ma's comment in https://lists.ubuntu.com/archives/kernel-team/2018-December/097439.html ** Changed in: linux (Ubuntu Xenial) Status: Confirmed => Won't Fix ** Changed in: linux (Ubuntu Xenial) Status: Won't Fix => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to kmod in Ubuntu. https://bugs.launchpad.net/bugs/1802135 Title: broken touchpad after i2c-i801 blacklist change Status in kmod package in Ubuntu: Fix Released Status in linux package in Ubuntu: Confirmed Status in kmod source package in Xenial: Fix Committed Status in linux source package in Xenial: Invalid Status in kmod source package in Bionic: Fix Committed Status in linux source package in Bionic: Fix Committed Status in kmod source package in Cosmic: Fix Committed Status in linux source package in Cosmic: Fix Committed Bug description: SRU: [Impact] ThinkPad 11e 2nd/3rd touchpad not working when load i2c-i801. PNP LEN0049 will use smbus by default in kernel, but i2c bus is in runtime suspend mode in old touchpad fw. Then touchpad will not work. LEN2040 on 11e 3rd can reproduce this issue by passing psmouse.synaptics_intertouch=1 These 2 pnp device should be the same one Synaptics s3203_ver5. [Fix] i2c-i801 should auto suspend when not used, no need runtime pm. [Test Case] Tested on Thinkpad 11e 3rd. Touchpad works fine. [Regression Potential] Low, upstream fix cherry-picked. 4.18 kernel patch, no need for cosmic. Original bug report: = After upgrading to kmod (24-1ubuntu3.1) the trackpads stop working on Lenovo 11e 2nd gen machines. We have a fleet of approximetly 1000 of them in production running ubuntu 18.04. Prior to this update the trackpads worked out of box in 18.04. We are currently working around the issue by deploying our own blacklist files. Here is a link to the SRU justification: https://bugs.launchpad.net /hwe-next/+bug/1786574 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1802135/+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 1802135] Re: broken touchpad after i2c-i801 blacklist change
** Changed in: linux (Ubuntu Bionic) Status: Confirmed => Fix Committed ** Changed in: linux (Ubuntu Cosmic) Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to kmod in Ubuntu. https://bugs.launchpad.net/bugs/1802135 Title: broken touchpad after i2c-i801 blacklist change Status in kmod package in Ubuntu: Fix Released Status in linux package in Ubuntu: Confirmed Status in kmod source package in Xenial: Fix Committed Status in linux source package in Xenial: Confirmed Status in kmod source package in Bionic: Fix Committed Status in linux source package in Bionic: Fix Committed Status in kmod source package in Cosmic: Fix Committed Status in linux source package in Cosmic: Fix Committed Bug description: SRU: [Impact] ThinkPad 11e 2nd/3rd touchpad not working when load i2c-i801. PNP LEN0049 will use smbus by default in kernel, but i2c bus is in runtime suspend mode in old touchpad fw. Then touchpad will not work. LEN2040 on 11e 3rd can reproduce this issue by passing psmouse.synaptics_intertouch=1 These 2 pnp device should be the same one Synaptics s3203_ver5. [Fix] i2c-i801 should auto suspend when not used, no need runtime pm. [Test Case] Tested on Thinkpad 11e 3rd. Touchpad works fine. [Regression Potential] Low, upstream fix cherry-picked. 4.18 kernel patch, no need for cosmic. Original bug report: = After upgrading to kmod (24-1ubuntu3.1) the trackpads stop working on Lenovo 11e 2nd gen machines. We have a fleet of approximetly 1000 of them in production running ubuntu 18.04. Prior to this update the trackpads worked out of box in 18.04. We are currently working around the issue by deploying our own blacklist files. Here is a link to the SRU justification: https://bugs.launchpad.net /hwe-next/+bug/1786574 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1802135/+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 1805955] Re: systemd 237-3ubuntu10.9 ADT test failure with linux-gcp 4.15.0-1025.26
There's a new test in this version of adt, "TEST-22-TMPFILES". It looks like this test fails because there's a permission problem on the test script itself "test.sh" -- 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/1805955 Title: systemd 237-3ubuntu10.9 ADT test failure with linux-gcp 4.15.0-1025.26 Status in systemd package in Ubuntu: New Bug description: Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/s/systemd/20181123_064313_f146e@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1805955/+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 1805955] [NEW] systemd 237-3ubuntu10.9 ADT test failure with linux-gcp 4.15.0-1025.26
Public bug reported: Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/s/systemd/20181123_064313_f146e@/log.gz ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: kernel-adt-failure ** Tags added: kernel-adt-failure -- 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/1805955 Title: systemd 237-3ubuntu10.9 ADT test failure with linux-gcp 4.15.0-1025.26 Status in systemd package in Ubuntu: New Bug description: Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/s/systemd/20181123_064313_f146e@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1805955/+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 1771783] Re: iproute2: frr route protocols are not converted to string on xenial
Proposed fix for lp #1771764 and lp #1771783
Please ignore the first proposal.
** Patch added: "proposed-fix-1771764-1771783.debdiff"
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1771783/+attachment/5159000/+files/proposed-fix-1771764-1771783.debdiff
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1771783
Title:
iproute2: frr route protocols are not converted to string on xenial
Status in iproute2 package in Ubuntu:
New
Bug description:
FRR puts its own proto numbers when inserting a route, example:
$ ip route
[snip]
2.2.2.0/24 via 3.3.3.2 dev eth2 proto 188 metric 20
iproute2 defines some protocols, but not all:
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/etc/iproute2/rt_protos
A patch has been pushed upstream so that external applications can define
their protocols numbers:
719e331ff619 ("Add support for rt_protos.d")
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=719e331ff619
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1771783/+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 1771764] Re: iproute2: unable to add ip lwt mpls route on xenial
Proposed fix for lp #1771764 and lp #1771783
** Patch added: "proposed-fix-1771764-1771783.debdiff"
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1771764/+attachment/5158998/+files/proposed-fix-1771764-1771783.debdiff
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1771764
Title:
iproute2: unable to add ip lwt mpls route on xenial
Status in iproute2 package in Ubuntu:
Incomplete
Bug description:
The following command does not work:
$ ip route add 10.201.0.0/24 nexthop encap mpls 300 via 10.200.0.1 dev ntfp2
Error: "nexthop" or end of line is expected instead of "encap"
In fact, iproute2 version points to v4.3.0, but the xenial kernel is a 4.4.
$ ip -V
ip utility, iproute2-ss151103
=>
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=6720eceff7b4
With an iproute2 v4.4.0 (iproute2-ss160111), that command works:
$ modprobe mpls_iptunnel
$ ./ip/ip route add 10.201.0.0/24 nexthop encap mpls 300 via 10.200.0.1 dev
ntfp2
$ ./ip/ip r
[snip]
10.201.0.0/24 encap mpls 300 via 10.200.0.1 dev ntfp2
At least, this patch is missing:
1e5293056a02 ("lwtunnel: Add encapsulation support to ip route")
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=1e5293056a02
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1771764/+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 1771783] Re: iproute2: frr route protocols are not converted to string on xenial
** Patch added: "proposed-patch-1.debdiff"
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1771783/+attachment/5156893/+files/proposed-patch-1.debdiff
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1771783
Title:
iproute2: frr route protocols are not converted to string on xenial
Status in iproute2 package in Ubuntu:
New
Bug description:
FRR puts its own proto numbers when inserting a route, example:
$ ip route
[snip]
2.2.2.0/24 via 3.3.3.2 dev eth2 proto 188 metric 20
iproute2 defines some protocols, but not all:
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/etc/iproute2/rt_protos
A patch has been pushed upstream so that external applications can define
their protocols numbers:
719e331ff619 ("Add support for rt_protos.d")
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=719e331ff619
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1771783/+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 1746463] Re: apparmor profile load in stacked policy container fails
** Changed in: apparmor (Ubuntu Artful)
Status: Confirmed => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1746463
Title:
apparmor profile load in stacked policy container fails
Status in apparmor package in Ubuntu:
Confirmed
Status in apparmor source package in Artful:
Fix Committed
Status in apparmor source package in Bionic:
Confirmed
Bug description:
LXD containers on an artful or bionic host with aa namespaces, should
be able to load the lxc policies. However /lib/apparmor/profile-load
skips that part when running in a container.
aa-status shows 0 policies
/lib/apparmor/profile-load is failing due to
is_container_with_internal_policy() failing
due to
/sys/kernel/security/apparmor/.ns_name being empty which causes
if [ "${ns_name#lxd-*}" = "$ns_name" ] && \
[ "${ns_name#lxc-*}" = "$ns_name" ]; then
return 1
fi
to fail
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1746463/+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 1729145] Re: /dev/bcache/by-uuid links not created after reboot
** Changed in: linux (Ubuntu Xenial) Status: In Progress => Fix Committed ** Changed in: linux (Ubuntu Artful) Status: In Progress => Fix Committed -- 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/1729145 Title: /dev/bcache/by-uuid links not created after reboot Status in linux package in Ubuntu: In Progress Status in systemd package in Ubuntu: Incomplete Status in linux source package in Xenial: Fix Committed Status in systemd source package in Xenial: Won't Fix Status in linux source package in Zesty: Won't Fix Status in systemd source package in Zesty: Won't Fix Status in linux source package in Artful: Fix Committed Status in systemd source package in Artful: Won't Fix Status in linux source package in Bionic: In Progress Status in systemd source package in Bionic: Won't Fix Bug description: 1. $ lsb_release -rd Description: Ubuntu 17.10 Release: 17.10 2. $ apt-cache policy linux-image-`uname -r` linux-image-4.13.0-16-generic: Installed: 4.13.0-16.19 Candidate: 4.13.0-16.19 Version table: *** 4.13.0-16.19 500 500 http://nova.clouds.archive.ubuntu.com/ubuntu artful/main amd64 Packages 100 /var/lib/dpkg/status 3. After creating some bcache devices and rebooting /dev/bcache/by-uuid/ -> ../../bcacheN symlinks point to the current bcache device which is caching the dev.uuid found after creating a backing device. 4. /dev/bcache/by-uuid does not exist and there are not symlinks underneath It appears that since the initramfs loads the bcache module which probes and finds all of the cache devices and backing devices then once the rootfs is mounted and udev gets to run, the bcache kernel module does not emit the CACHED_UUID value into the environment if the underlying devices are already registered. In dmesg, one can see that prior to mounting the rootfs, we see bcache register events: [5.333973] bcache: register_bdev() registered backing device vdb2 [5.354138] bcache: register_bdev() registered backing device vdb4 [5.365665] bcache: register_bdev() registered backing device vdb3 [5.397720] bcache: bch_journal_replay() journal replay done, 0 keys in 1 entries, seq 1 [5.428683] bcache: register_cache() registered cache device vdb1 then rootfs ismounted and systemd starts systemd-udev [9.350889] systemd[1]: Listening on udev Kernel Socket. And then the coldplug replay of kernel events triggers /lib/udev/rules.d/69-bcache.rules which invokes /lib/udev/bcache-register which writes the device name (/dev/vdb1 or /dev/bcache0) into /sys/fs/bcache/register and results is the bcache kernel driver attempting to register the block device. However, there is already a bcache device associated already and registration fails [ 11.173141] bcache: register_bcache() error opening /dev/vdb2: device already registered [ 11.184617] bcache: register_bcache() error opening /dev/vdb3: device already registered [ 11.199130] bcache: register_bcache() error opening /dev/vdb1: device already registered [ 11.271694] bcache: register_bcache() error opening /dev/vdb4: device already registered The problem then is that only a kernel call to bch_cached_dev_run() which happens like this: bcache_register() register_bdev() bch_cached_dev_run() kobject_uevent_env(&disk_to_dev(d->disk)->kobj, KOBJ_CHANGE, env); where env includes: "DRIVER=bcache", kasprintf(GFP_KERNEL, "CACHED_UUID=%pU", dc->sb.uuid), NULL, NULL, }; Since that event is not emitted for any previously registered device, then the symlink will not be created. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: linux-image-4.13.0-16-generic 4.13.0-16.19 ProcVersionSignature: User Name 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Oct 31 22:09 seq crw-rw 1 root audio 116, 33 Oct 31 22:09 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay' ApportVersion: 2.20.7-0ubuntu3.1 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A Date: Wed Nov 1 01:39:01 2017 Ec2AMI: ami-030b Ec2AMIManifest: FIXME Ec2AvailabilityZone: nova Ec2InstanceType: m1.small Ec2Kernel: unavailable Ec2Ramdisk: unavailable IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig' Lsusb: Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub MachineType: OpenStack Foundation OpenStack Nova PciMultimedia:
[Touch-packages] [Bug 1731467] Re: Cannot pair BLE remote devices when using combo BT SoC
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- artful' to 'verification-done-artful'. If the problem still exists, change the tag 'verification-needed-artful' to 'verification-failed- artful'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-artful -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1731467 Title: Cannot pair BLE remote devices when using combo BT SoC Status in bluez package in Ubuntu: In Progress Status in linux package in Ubuntu: Incomplete Status in bluez source package in Xenial: New Status in linux source package in Xenial: Fix Committed Status in bluez source package in Zesty: New Status in linux source package in Zesty: Fix Committed Status in bluez source package in Artful: New Status in linux source package in Artful: Fix Committed Bug description: It has been observed that sometimes it is not possible to pair with BLE remote devices when the host system is using combo (WiFi + BT) chip. The root cause of the disconnection has been identified as coming from the internal to bluez timeout. If bluez does not hear any reply from for two seconds the link is automagically disconnected. The reason fro the silence is not however a failure of the remote device but quite often a delay in the WiFi/BT combo driver that causes the packages not to reach the bluez stack. [Impact] Not possible to pair BLE remote devices such as sensors and such with Ubuntu when the host system uses BT+WiFi combo SoC. The connection attempt is disturbed with a timeout. [Fix] It has been fixed by increasing the timeout value from 2 seconds to 4 seconds. It is enough for the events to reach the stack (measured that it takes between 3 and 3.5 seconds). [Testcase] Tested with the device that failed to connect to Ubuntu Core gateway. It fails w/o the patch, it connects just fine with the patch applied. [Regression Potential] Very small. The increased timeout is taken into consideration only for new and scan report triggered connections. It will not make any already working device to fail to pair. [Other Info] The bug has been discussed and fixed here: https://marc.info/?l=linux-bluetooth&m=150824844606937&w=2 [Patch] https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth- next.git/commit/?id=1f01d8be0e6a04bd682a55f6d50c14c1679e7571 The patch has been accepted by the upstream and will be a part of the next kernel release. Currently in the bluetooth-next tree. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1731467/+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 1731467] Re: Cannot pair BLE remote devices when using combo BT SoC
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- xenial' to 'verification-done-xenial'. If the problem still exists, change the tag 'verification-needed-xenial' to 'verification-failed- xenial'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-xenial ** Tags added: verification-needed-zesty -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1731467 Title: Cannot pair BLE remote devices when using combo BT SoC Status in bluez package in Ubuntu: In Progress Status in linux package in Ubuntu: Incomplete Status in bluez source package in Xenial: New Status in linux source package in Xenial: Fix Committed Status in bluez source package in Zesty: New Status in linux source package in Zesty: Fix Committed Status in bluez source package in Artful: New Status in linux source package in Artful: Fix Committed Bug description: It has been observed that sometimes it is not possible to pair with BLE remote devices when the host system is using combo (WiFi + BT) chip. The root cause of the disconnection has been identified as coming from the internal to bluez timeout. If bluez does not hear any reply from for two seconds the link is automagically disconnected. The reason fro the silence is not however a failure of the remote device but quite often a delay in the WiFi/BT combo driver that causes the packages not to reach the bluez stack. [Impact] Not possible to pair BLE remote devices such as sensors and such with Ubuntu when the host system uses BT+WiFi combo SoC. The connection attempt is disturbed with a timeout. [Fix] It has been fixed by increasing the timeout value from 2 seconds to 4 seconds. It is enough for the events to reach the stack (measured that it takes between 3 and 3.5 seconds). [Testcase] Tested with the device that failed to connect to Ubuntu Core gateway. It fails w/o the patch, it connects just fine with the patch applied. [Regression Potential] Very small. The increased timeout is taken into consideration only for new and scan report triggered connections. It will not make any already working device to fail to pair. [Other Info] The bug has been discussed and fixed here: https://marc.info/?l=linux-bluetooth&m=150824844606937&w=2 [Patch] https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth- next.git/commit/?id=1f01d8be0e6a04bd682a55f6d50c14c1679e7571 The patch has been accepted by the upstream and will be a part of the next kernel release. Currently in the bluetooth-next tree. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1731467/+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 1731467] Re: Cannot pair BLE remote devices when using combo BT SoC
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- zesty' to 'verification-done-zesty'. If the problem still exists, change the tag 'verification-needed-zesty' to 'verification-failed-zesty'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1731467 Title: Cannot pair BLE remote devices when using combo BT SoC Status in bluez package in Ubuntu: In Progress Status in linux package in Ubuntu: Incomplete Status in bluez source package in Xenial: New Status in linux source package in Xenial: Fix Committed Status in bluez source package in Zesty: New Status in linux source package in Zesty: Fix Committed Status in bluez source package in Artful: New Status in linux source package in Artful: Fix Committed Bug description: It has been observed that sometimes it is not possible to pair with BLE remote devices when the host system is using combo (WiFi + BT) chip. The root cause of the disconnection has been identified as coming from the internal to bluez timeout. If bluez does not hear any reply from for two seconds the link is automagically disconnected. The reason fro the silence is not however a failure of the remote device but quite often a delay in the WiFi/BT combo driver that causes the packages not to reach the bluez stack. [Impact] Not possible to pair BLE remote devices such as sensors and such with Ubuntu when the host system uses BT+WiFi combo SoC. The connection attempt is disturbed with a timeout. [Fix] It has been fixed by increasing the timeout value from 2 seconds to 4 seconds. It is enough for the events to reach the stack (measured that it takes between 3 and 3.5 seconds). [Testcase] Tested with the device that failed to connect to Ubuntu Core gateway. It fails w/o the patch, it connects just fine with the patch applied. [Regression Potential] Very small. The increased timeout is taken into consideration only for new and scan report triggered connections. It will not make any already working device to fail to pair. [Other Info] The bug has been discussed and fixed here: https://marc.info/?l=linux-bluetooth&m=150824844606937&w=2 [Patch] https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth- next.git/commit/?id=1f01d8be0e6a04bd682a55f6d50c14c1679e7571 The patch has been accepted by the upstream and will be a part of the next kernel release. Currently in the bluetooth-next tree. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1731467/+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
