Public bug reported:
On a ThinkPad P16s running Noble, resuming from suspend fails about 10%
of the time. This usually leads to a reboot, and more rarely to a hang
that requires forcing a power off.
I don't recall this being the case with kernel 6.5 in Mantic.
How to reproduce:
* suspend the
unfortunately the problem is not actually gone in noble. I have upgraded
to the beta and are having significant but intermittent problems. On
6.8.0-31-generic I get periods of normal traffic mixed with 100% packet
loss for some seconds. This looks as follows:
64 bytes from 192.168.16.77:
It's also worth noting that displaycal-py3 does not support python 3.12
yet. See for example https://github.com/eoyilmaz/displaycal-
py3/issues/335#issuecomment-2016761349
** Bug watch added: github.com/eoyilmaz/displaycal-py3/issues #335
https://github.com/eoyilmaz/displaycal-py3/issues/335
Public bug reported:
I have upgraded to the noble beta today, and displaycal fails to start.
The package dependencies request python 3.12, but the actual software
needs 3.11 (or older).
```
$ apt show displaycal | grep Depends
WARNING: apt does not have a stable CLI interface. Use with caution
Well, that was a pleasant surprise! On 6.8.0-11 the problem seems to be
completely gone. I guess I'll be upgrading to Noble as soon as possible.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2058752
Public bug reported:
On 6.5.0-26-generic, my QCNFA765 cannot really operate in 802.11ax mode.
I have a Thinkpad P16s Gen 2 with a (soldered, sadly) QCNFA765 card, which uses
the ath11k driver.
I also have a Ruckus R650 AP, which supports wifi6.
Connecting the two and pinging the AP yields the
As well as in 20.10 (gnome-online-accounts 3.37.90-1ubuntu1).
By the way, the upstream bug link is now https://gitlab.gnome.org/GNOME
/gnome-online-accounts/-/issues/17
** Bug watch added: gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues #17
Public bug reported:
There are currently three types of migration force strategies that can
be configured in nova: pause (default), post-copy, and auto-converge.
They apply to *all* migrations, as the client cannot select its
preferred one on a case-by-case basis.
I think it would be preferable
** Description changed:
- As of a couple of days ago, I am unable to get network manager to
- connect to any wifi network.
+ If the /etc/NetworkManager/system-connections directory is a cross-
+ filesystem symlink, activating connections will fail with the unrelated
+ messages:
- It looks like
** Summary changed:
- settings plugin does not support adding connections
+ misleading error messages when /etc/NetworkManager/system-connections is a
cross-filesystem symlink
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Public bug reported:
As of a couple of days ago, I am unable to get network manager to
connect to any wifi network.
It looks like the groovy network manager packages have not received any
updates since release, but since I can successfully use wpasupplicant
directly I'm ruling out issues with my
released as cs:~llama-charmers-next/memcached-4
** Changed in: charm-memcached
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1828534
Title:
Marking as field-high as this now affects a live cloud, and the
workaround (lowering the MTU within the qdhcp namespaces) isn't fully
persistent.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1833713
That's right, I'm hitting this bug only because this machine is running Trusty,
and mtab is not a symlink in that release.
I suppose fixing this doesn't fall within the scope of ESM support, but I'll
set this to new so you can review.
** Changed in: monitoring-plugins (Ubuntu)
Status:
Public bug reported:
We have a machine in production that suffered a failure in one of its
drives. We attempted unmounting the failed drive, but that only
partially succeeded: the failed drive is not mounted anymore, but the
umount process is stuck in D state.
$ ps aux | grep umount
root
I have now run some tests and can confirm that upgrading the neutron
server package on the API units is enough. More specifically:
neutron-gateway 14.0.2 + neutron-api 14.0.2 + compute 14.0.4 ⇒ booting
instances fails
neutron-gateway 14.0.2 + neutron-api 14.0.4 + compute 14.0.4 ⇒ booting
Please also consider that this bug will easily hit cloud expansions: new
computes will get >= 2:14.0.3-0ubuntu1.1~cloud0, and if the neutron
gateway is running an older version they will not work until the neutron
packages are downgraded.
--
You received this bug notification because you are a
Public bug reported:
[already filed upstream as
https://storyboard.openstack.org/#!/story/2007213 - re-filing here for
internal tracking]
HAproxy >= 1.8 offers a nbthread option to configure how many threads
the haproxy process will use[0]. Scaling beyond 1 thread is useful as it
is known to
For completeness, this affects even just 2:14.0.2-0ubuntu1.1~cloud0 to
2:14.0.3-0ubuntu1.1~cloud0.
Although we try as hard as we can to ensure that unattended upgrades are
disabled for the clouds we manage, upgrades between minor versions (not
just patch versions) should always be safe. This bug
Actually... on second thought a command-line option may be unavoidable.
If sosreport were to explicitly set a io policy, it might end up
overriding what the operator might specify via ionice.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
*** This bug is a duplicate of bug 1825010 ***
https://bugs.launchpad.net/bugs/1825010
Thanks Andreas, I've found the SRU bug for updating sosreport. I'll mark
this as duplicate.
** This bug has been marked a duplicate of bug 1825010
[sru] Update sosreport to 3.8
--
You received this
Hi Andreas,
I can understand upstream's approach: sosreport should just do its job, and
tuning should be up to the administrator. Having said that, given the type of
tool sosreport is and the circumstances it tends to be used in, I think that we
could offer a better user experience if
Public bug reported:
I am sometimes hitting timeouts while running sosreport, but I see that support
for a configurable timeout has already been added with the following commit:
https://github.com/sosreport/sos/commit/031ff485afd888a5ecf9297bde2c2659cf3e1ec5
This functionality is present from
Public bug reported:
[copy paste of https://github.com/sosreport/sos/issues/1844]
In at least version 3.6-1ubuntu0.16.04.3 and 3.6-1ubuntu0.18.04.3, neither the
sosreport process itself, nor (and more importantly) the compression binary are
run with an explicit I/O nice class.
This results in
Yeah I agree, service masking is a corner case and it's just making things more
confusing.
I also got misled by the haproxy_status function, which doesn't actually seem
to ever be called (although I still think some return codes are wrong).
My bug report stemmed from seeing on a production
This has been fixed in nagios-32 by deploying a custom
check_all_disks_no_squashfs check
** Changed in: nagios-charm
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
It also overrides whatever governor the cpufrequtils sets, and with such
delay not even careful ordering of the services can prevent ondemand
from winning.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Thanks James for following up on this. Will the fix trickle down to
Bionic and Xenial as well? We have deployments that use vault on both
releases.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Ah good catch, the exit 0 was higher up.
Additionally, I had misread the haproxy_status function, the pid is actually
looked up in the process table at line 99 (even if the comment is wrong and 3
should be returned, not 1).
Though here's another reproducer:
root@juju-8d5e58-14:~# systemctl mask
Public bug reported:
`/etc/init.d/haproxy status` will return 0 if the pidfile is present,
regardless of whether haproxy is actually running.
I suggest for the check to be rewritten to actually look for a process with
that PID (e.g. `pgrep -F $PIDFILE`).
How to reproduce:
chmod -x
python-openstackclient 3.14.2-0ubuntu1~cloud0 from queens-proposed
tested, no issues detected.
** Tags removed: verification-queens-needed
** Tags added: verification-queens-done
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Tested 3.14.2-0ubuntu1 in a bionic lxd. MTU manipulation works fine,
it's even too permissive[0]... but that's not an issue with the package
itself.
[0] https://storyboard.openstack.org/#!/story/2004298
** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic
--
You
Hi Corey, I've tried version 3.14.2-0ubuntu1~cloud0 (from
https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/queens-
staging) and things look correct.
** Tags added: verification-done-xenial
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Corey,
Why was the bug marked as invalid for xenial / cloudarchive?
Thanks,
Andrea
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1800490
Title:
[SRU] update to queens/3.14.2
To manage
Hi Corey,
I'd be happy to install the test package in our staging area and test
the --mtu flag (+ some further casual testing). Would you have a more
rigorous set of tests to go through?
Andrea
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Public bug reported:
Today I noticed that the xenial package on ubuntu-cloud is 3.14.0, whereas the
latest stable for the queens branch is 3.14.2.
Would it be possible to package the latest version? 3.14.1 introduced a switch
(--mtu[0]) that isn't available in 3.14.0
[0]
Just as another data point:
Dell R740 with Xeon Gold 6132 on xenial:
4.13.0-36-generic - FAIL
4.13.0-37-generic - FAIL
4.13.0-45-generic - PASS
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1759787
I am successfully using the following modified version of Darren's
suggestion for my RAT9 on an updated and unpatched ArchLinux box:
Section InputClass
Identifier R.A.T.9
MatchUSBID 06a3:0cfa
Driver evdev
Option Buttons 17
Option ButtonMapping 1 2 3 4 5 0 0
38 matches
Mail list logo
