Launchpad
LP #2008721 docker.io — ubuntu_docker_smoke_test fails on trusty
The main task was marked as fix released. I took the opportunity to also mark trusty as won’t fix, as that is EOSS, and left a comment.
LP #2080474 multipath-tools — [SRU] cannot install Ubuntu Server over a multipath disk used as an LVM PV
The last update was the SRU verification, but something more interesting is the discovery that noble autopkgtests are running in a lxd vm that does not have the linux-modules-extra-$(uname r) package installed, which is making the udisks2 test fail. This bug was filed about it: Bug #2156438 “Autopkgtest fails on noble - scsi_debug module not...” : Bugs : udisks2 package : Ubuntu
Unfortunately, for the multipath-tools SRU this means that we lost test coverage with this change in the preinstalled packages in the VM, because the previous multipath-tools package also started to fail, and that makes the infra consider the baseline as “fail”, and thus a new failure due to the SRU won’t be flagged as a regression.
LP #2152270 chrony — nts-bootstrap-ubuntu.crt missing CN=ubuntu CA cert, NTS sync fails on fresh ins…
A user comented that maybe ubuntu should warn the user that chrony failed to sync time using NTS, assuming a desktop system probably. It’s a valid suggestion, but definitely wishlist for now. I added a comment thanking the user for the suggestion, and also explained why I left the bug in the state “incomplete” for now.
LP #2153530 libvirt — libvirt: excessive memory allocation / OOM when physical_package_id is large
The update was about SRU verification. I left the bug alone.
LP #2155090 freeradius — Upgrading 22.04LTS to 24.04LTS completely breaks freeradius
The reporter added some logs, and it looks like apt decided to remove freeradius indeed. The apt logs are a bit cryptic, but it seems to be related to libpcap. I left a comment asking if the reporter remembers having installed packages from a different repository (like a PPA), or a different version of ubuntu. But then I tried a release upgrade myself, and confirmed the issue. Bug triaged as high and marked server-todo.
LP #2156406 netplan.io — netplan apply fails on systems without OVS
I didn’t quite understand how that system ended up without the netplan-ovs-cleanup.service. I ran it myself, showed some logs, and asked the reporter if he could provide logs of when daemon-reload is called, to see if the netplan generator then logged anything about why it might have failed to run or produce the cleanup service unit.
Old items
GitHub
no activity