Stage "searching for obsolete software" takes a very long time (30 minutes)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ubuntu-release-upgrader (Ubuntu) |
Fix Released
|
High
|
Julian Andres Klode | ||
Focal |
Won't Fix
|
High
|
Unassigned | ||
Noble |
Fix Released
|
High
|
Julian Andres Klode |
Bug Description
[Impact]
Upgrades hang for a long time searching for obsolete software, frustrating users.
[Test plan]
1. With each, update, and proposed version do:
0. launch a container / VM
1. do-release-upgrade
2. Note down the time it took for the obsolete software stage, and the packages marked for removal.
2. Check that the time is now significantly smaller than before
For example with the default ubuntu:jammy lxd container:
before: ~8s
2024-07-16 15:13:25,575 DEBUG Start checking for obsolete pkgs
2024-07-16 15:13:33,847 DEBUG Finish checking for obsolete pkgs
after: ~0.5s
2024-07-16 15:22:21,977 DEBUG Start checking for obsolete pkgs
2024-07-16 15:22:22,508 DEBUG Finish checking for obsolete pkgs
3. Compare the list of packages marked for removal: It should be the same or more packages.
before:
2024-07-16 15:13:33,907 DEBUG The following packages are marked for removal: libperl5.34 python3.10 libctf-nobfd0 libblockdev-part2 libblockdev-swap2 libpcre3 libunistring2 libaio1 libmpdec3 libbinutils python3-jeepney libpython3.
ls-x86-64-linux-gnu irqbalance libbpf0 libtss2-mu0 libldap-2.5-0 isc-dhcp-common libisc-export1105 libappstream4 libpython3.10 libblockdev-loop2 libblockdev2 libblockdev-
after:
2024-07-16 15:22:22,555 DEBUG The following packages are marked for removal: libperl5.34 python3.10 libctf-nobfd0 libblockdev-part2 libblockdev-swap2 libpcre3 libunistring2 libaio1 libmpdec3 libbinutils python3-jeepney libpython3.
ls-x86-64-linux-gnu irqbalance libbpf0 libtss2-mu0 libldap-2.5-0 isc-dhcp-common libisc-export1105 libappstream4 libpython3.10 libblockdev-loop2 libblockdev2 libblockdev-
This small container is not necessarily the best test case to demonstrate it and ensure correctness but the fastest one; it may also be suitable to run it in a desktop VM instead.
[Where problems could occur]
The upgrade process could crash in case the solver fails to solve the request it is being given. This is the last step of the upgrade though, so it is reasonable safe.
One could have skipped on a solver failure but this way we'd get crash reports
in the unlikely case they happen.
[Original bug report]
Test Case:
1. Fresh Bionic installation from 18.04.4 + all updates applied
2. Run: update-manager -d
3. Proceed with the upgrade.
Actual Result:
Everything goes well but the stage "Searching for obsolete software" takes a very long time.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: ubuntu-
ProcVersionSign
Uname: Linux 5.4.0-26-generic x86_64
ApportVersion: 2.20.11-0ubuntu27
Architecture: amd64
CasperMD5CheckR
CrashDB: ubuntu
CurrentDesktop: ubuntu:GNOME
Date: Wed Apr 22 10:34:19 2020
InstallationDate: Installed on 2020-04-20 (2 days ago)
InstallationMedia: Ubuntu 18.04.4 LTS "Bionic Beaver" - Release amd64 (20200203.1)
PackageArchitec
ProcEnviron:
TERM=xterm-
PATH=(custom, no user)
XDG_RUNTIME_
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: ubuntu-
Symptom: ubuntu-
UpgradeStatus: Upgraded to focal on 2020-04-22 (0 days ago)
VarLogDistupgra
Related branches
- Nick Rosbrook: Approve
-
Diff: 110 lines (+53/-25)2 files modifiedDistUpgrade/DistUpgradeCache.py (+18/-19)
DistUpgrade/DistUpgradeController.py (+35/-6)
tags: | added: rls-ff-incoming |
Changed in ubuntu-release-upgrader (Ubuntu): | |
importance: | Undecided → High |
Changed in ubuntu-release-upgrader (Ubuntu Focal): | |
status: | New → Confirmed |
importance: | Undecided → High |
tags: | removed: rls-ff-incoming |
tags: | added: id-5eb44cb5b465575ffac8f476 |
tags: | added: rls-ff-incoming |
tags: | added: fr-328 |
tags: | removed: rls-ff-incoming |
Changed in ubuntu-release-upgrader (Ubuntu): | |
status: | Expired → Confirmed |
Changed in ubuntu-release-upgrader (Ubuntu Focal): | |
status: | Expired → Confirmed |
tags: | removed: fr-328 |
tags: | added: rls-nn-incoming |
tags: |
added: foundations-todo removed: rls-nn-incoming |
Changed in ubuntu-release-upgrader (Ubuntu Focal): | |
status: | Confirmed → Triaged |
Changed in ubuntu-release-upgrader (Ubuntu Noble): | |
status: | Confirmed → Triaged |
milestone: | none → ubuntu-24.04-beta |
Changed in ubuntu-release-upgrader (Ubuntu Noble): | |
milestone: | ubuntu-24.04-beta → ubuntu-24.04 |
Changed in ubuntu-release-upgrader (Ubuntu Noble): | |
status: | Triaged → In Progress |
assignee: | nobody → Julian Andres Klode (juliank) |
Changed in ubuntu-release-upgrader (Ubuntu Noble): | |
milestone: | ubuntu-24.04 → ubuntu-24.04.1 |
Changed in ubuntu-release-upgrader (Ubuntu Focal): | |
status: | Triaged → Won't Fix |
description: | updated |
I restored this apt-clone file to an Ubuntu 18.04 LTS system and then upgraded to Ubuntu 20.04 LTS. The search for obsolete software only took a minute.
bdmurray@ clean-bionic- amd64:~ $ grep "obsolete pkgs" /var/log/ dist-upgrade/ main.log
2020-04-22 14:04:41,576 DEBUG Start checking for obsolete pkgs
2020-04-22 14:05:27,656 DEBUG Finish checking for obsolete pkgs
It's not immediately clear to me what is going on. This other cache operation of yours also took a long time.
2020-04-22 09:17:49,110 INFO cache.commit()
2020-04-22 09:42:51,188 DEBUG cache.commit() returned None
2020-04-22 09:42:51,332 DEBUG openCache()
2020-04-22 09:42:54,210 DEBUG /openCache(), new cache size 65224