Fedora Account System
Red Hat Associate
Red Hat Customer
We have an openQA test called desktop_update_graphical which is intended to test that updating with the desktop's graphical package manager - Discover, for KDE - works. Before anything specific to this test runs, openQA updates the system from the default repos, so usually, no normal updates would be available if we just ran Discover and looked for them. So, next, the test enables a side repo - https://fedorapeople.org/groups/qa/openqa-repos/openqa-testrepo-1/ - and uses it to downgrade the acpica-tools package to a dummy build from that repo which is versioned 1-1. That ensures there will be an update available when we run the update tool, because the official repository will always have a higher-versioned acpica-tools package. Then the test goes to the desktop, runs Discover, and goes through the update process. The side repo is disabled by default - we use `--enablerepo` to enable it for the specific transactions it is used for. So when Discover is running it should not use the side repo. In Rawhide testing recently, the test is frequently failing. openQA goes to the Updates screen, hits Refresh, then sees the 'apply' button ("Update All") indicating an update is available, and clicks it. The UI at this point shows "System upgrade 1 package will be upgraded" and the size "2.9 MiB". When openQA clicks "Update All", the update process starts. A progress bar appears over the "2.9 MiB" size and very quickly fills to about 90% - but then it gets stuck there, and remains stuck there until openQA gives up waiting for it to go further, and the test fails. See https://openqa.fedoraproject.org/tests/3871762#step/desktop_update_graphical/33 for a recent case. This is happening on around half the Rawhide tests lately: https://openqa.fedoraproject.org/tests/3871762#next_previous . In Rawhide it started happening some time ago - https://openqa.fedoraproject.org/tests/3752444 from 2025-09-19 is the earliest case I can find, but it could have been happening for much longer, we don't have enough history to be sure - but it was much more rare at first. It only happened about 1-5% of the time until 2025-10-07, whereupon it suddenly started happening much more often (about half of attempts, as I said). In Fedora 43 it seems to be happening rarely, like it did on Rawhide between 2025-09-19 and 2025-10-07. I can find it happening all the way back to https://openqa.fedoraproject.org/tests/3625214 , on August 16 (that's about as far as our 'scrollback' goes, so it could have been happening before that). On Fedora 42 it doesn't seem to be happening at all. Steve pointed out that PackageKit-Qt is at 1.1.1 on F42, 1.1.2 on F43, and 1.1.4 on Rawhide. So it's *possible* the bug was introduced with 1.1.2 but happened rarely, and got much worse with 1.1.4. The timing of the problem suddenly getting worse on Rawhide does seem to coincide with the landing of the 1.1.4 update - https://bodhi.fedoraproject.org/updates/FEDORA-2025-25aeb1bfac .
Created attachment 2109872 [details] /var/log tarball from affected test This is a tarball of /var/log from the affected test. You can use `journalctl --file var/log/journal/*/\*.journal` to see the journal. I don't see anything *really* like a smoking gun, though someone may be able to figure from the PackageKit messages that it's stuck somewhere it shouldn't be.
An oddity: this is happening way less often on aarch64, though it *is* happening. No idea why. Maybe indicates some kind of race? https://openqa.fedoraproject.org/tests/3871641#next_previous
Ok so far have not been able to reproduce the issue. This is from a fresh Rawhide KDE install. KDE Plasma 6.5.1 Frameworks 6.19.0 QT Version 6.10.0 Kernel 6.18.0-0.rc3.251028gfd57572253bc3.31.fc44x86_64(64-bit) Graphics Wayland Will keep trying.
It still happens all the time to openQA. It might be somehow specific to the precise situation the openQA update test produces (see bug description), you might have to try and replicate that.
(In reply to Adam Williamson from comment #4) > It still happens all the time to openQA. It might be somehow specific to the > precise situation the openQA update test produces (see bug description), you > might have to try and replicate that. Followed what you said and added the side repo. Maybe I’m missing something but updates are running fine so far.
This is getting really bad lately, the test is failing more than it's passing: https://openqa.fedoraproject.org/tests/3975601#next_previous this is causing delays for updates going stable, as they fail gating if they fail this test. I have to keep retrying them over and over. It's getting kinda unmanageable :/
Aleix, do you have any idea what's going on here?
I tried a couple of things for this today...I tried adding a reboot between all the repo setup bits and the actual 'run Discover and do an update bit', and I tried taking out the bit where we hit the 'refresh' button before we actually do an update. Neither of those seems to make the problem go away, unfortunately.
Aleix has some issues with his bugzilla account, but this is what he replied in Matrix: "No, I don't have a good idea what could be going on. Collecting pkmon output could be useful to see what's happening under the hood"
OK. I'll try and get to that. For now I've bumped the retries on this test to mitigate the flake issue - https://pagure.io/fedora-qa/os-autoinst-distri-fedora/pull-request/467
This bug appears to have been reported against 'rawhide' during the Fedora Linux 45 development cycle. Changing version to 45.