It seems 0.142ubuntu19 would be exposed to the bug. To test whether or
not my use case would be affected by it, I've booted a Jammy instance
with initramfs-tools 0.142ubuntu19, and I can't hit the problem. It is
booting well through iscsi. My cmdline is as below, so it might not be
exposed to the
I've tested launching a Oracle Cloud baremetal instance (which boots
from iSCSI) using such patch, and all worked well:
https://pastebin.ubuntu.com/p/3cdFdYBVFG/
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to
I've tested the patch and it fixes the issue. I can confirm the MTU
settings are now correct and curl works fine. I also confirmed it
allowed cloud-init to run and fully complete the boot process:
https://pastebin.ubuntu.com/p/KfcP7wmjjV/
There are no cloud-init errors:
Sorry for the late feedback, but sharing here:
AWS docs regarding best practices regarding cpu-starvation [1] do not
recommend disabling the irqbalance service. Quoting the doc:
> "Note: we do not recommend disabling irqbalance service. ENA driver
doesn’t provide affinity hints, and if device
Hi Nafees, I discussed this with Mitchell and we are still looking into
the best possible way to move forward with this SRU. We'll keep this bug
update as soon as we have some more details to share.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages,
Hi Steve,
Would you and the SRU team reconsider the "won't fix" decision or
further elaborate on the regression problem, based on the comment above?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python2.7 in Ubuntu.
Another suggestion from one of our Engineers is that you can also set it
inside your python script, something like this:
```
from setuptools import setup, Extension
import sysconfig
extra_flags=sysconfig.get_config_var('CFLAGS').split()
setup(
name="test",
Alright, thanks for the information @Steve.
Hi @Nafees,
With the information above, it seems there's a regression risk if we fix
this bug in python2.7 in Focal, and the risk outstands the benefits of
the fix, as it seems to be an uncommon use-case and there's a workaround
for it, so we wouldn't
It's also worth mentioning that, a patch was backported mentioning "#
DP: Allow setting BASECFLAGS, OPT and EXTRA_LDFLAGS (like, CC, CXX, CPP,
CFLAGS, CPPFLAGS, CCSHARED, LDSHARED) from the environment." [1], but
then OPT is not being added at all by the patch (which had just
mentioned adding it),
Hi Steve,
Thanks for looking into this SRU request.
Their original request was specifically to python2.7 on Ĵammy, which
matches your comment on the eligible releases.
The request is not to rebuild the python extensions, but to fix the
compiler so new modules getting compiled will inherit the
Hi Nafees,
I've discussed this case with our Engineering team and they are working
on the SRU process to get this fix released, however this should take
around 1 month before it gets published to -updates. Although we are
prioritizing it, the fix still needs to go to the -proposed repository
for
@Nafees,
I'm sorry, I hadn't noticed that the file produced by python3 was
different (and I did have the test.so in my directory because I had
built it with python2 before, so I was just grepping the same file). I
see the problem now and I'm checking it with our Engineering team.
Regards,
Fabio
Hi Nafees,
Thank you for the reproducer and instructions.
Per your comments, I would expect this to work well with python3 on
20.04, however, my tests indicated that python2 and python3 are both
behaving the same way. In the example below, I'm using python3 and I
also don't see the -O2
Hello Nafees,
Can you share this setup.py that we can use to reproduce the problem and
investigate?
Regards,
Fabio Martins
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python2.7 in Ubuntu.
Public bug reported:
Feature Request:
When installing a system over the network using live installer
(subiquity), you can use the kernel cmdline option ip= [1] to provide
the network configuration.
In certain situations, it would be ideal to be able to configure a lacp
bond during this process.
I've also updated the [Test Plan] section of the bug description
** Description changed:
[Impact]
In some cases, ipconfig can take a longer time than the user-specified
timeouts, causing unexpected delays.
[Test Plan]
+
+ - Check that the ipconfig utility is able to obtain an IP
Hello Robie,
I've validated that the package from -proposed works well, testing in my
VM based environment. I haven't tested it on Oracle bare metal (where
the original issue happened) as that is a type of instance hard to get
access to. Given that the test packages had proven to fix the original
I've tested the package from -proposed and I can confirm it fixes the
problem:
Installed from -proposed:
root@ubuntu:~# apt-cache policy klibc-utils
klibc-utils:
Installed: 2.0.4-9ubuntu2.2
Candidate: 2.0.4-9ubuntu2.18.04.1
Version table:
2.0.4-9ubuntu2.18.04.1 500
500
Should this bug be changed to Fix Committed at this point?
--
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
I've tested the new patch from ppa:mfo/lp1947099v2 and I can confirm it
resolves the problem:
- Without the patch:
https://pastebin.ubuntu.com/p/RksNcBGSzn/
It took 396,940865−220,447147 = 176,493718 seconds in the IP-Config section.
Total boot time:
ubuntu@gpu48-ubuntu18:~$ sudo
Thank you, Mauricio, for the build process details and for adding the
update here. I'm including some evidence of my tests showing that the
patch you suggested did work well:
Details of the build process:
https://pastebin.ubuntu.com/p/dmVWH2fxpy/
Test package installed:
@Łukasz / @Robie, do you think the above comments are enough to proceed
with this SRU?
--
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
I've tested the klibc-utils patch using Mauricio's ppa:
sudo add-apt-repository ppa:mfo/lp1947099
sudo apt install klibc-utils
sudo update-initramfs -u -k all
And I can confirm that it does improve the boot time in more than 3
minutes, without causing any noticeable issues.
- Without the patch:
I tried using klibc-utils from the ppa (containing the patch):
root@ubuntu:~# sudo apt-cache policy klibc-utils
klibc-utils:
Installed: 2.0.4-9ubuntu2.18.04.1
Candidate: 2.0.4-9ubuntu2.18.04.1
Version table:
*** 2.0.4-9ubuntu2.18.04.1 500
500
I've setup a Lab with dnsmasq acting as DHCP Server, which I can use the
dhcp-reply-delay option to introduce a delay between the DHCPDISCOVER
and DHCPOFFER, as in the example below:
Mar 30 18:26:34 focal-dhcpsrv dnsmasq-dhcp[2470]: DHCPDISCOVER(ens3)
52:54:00:d7:10:13
Mar 30 18:26:34
Hi Robie,
The user story here is about improving the time it takes to boot a
Bionic instance on Oracle Cloud in a specific bare metal shape, called
BM.GPU4.8. This is a pretty large instance, with 18x Ethernet controller
[0200]: Mellanox Technologies MT28800 Family [ConnectX-5 Ex]
[15b3:1019]:
Customer has provided a positive feedback that the package in -proposed
fixed this bug
--
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/1923115
Title:
Networkd vs udev nic
27 matches
Mail list logo
