For the second time (the first was F40>F41) since I’ve been using Fedora, I’ve had system upgrade by GNOME Software fail on the first attempt (download progress stops) and then succeed on the second. No error is reported to me, at least not via GUI. In the end the upgrade succeeds, but I would like to understand why this behavior always happens.
Thanks to those who can give me some more information on the subject.
You can check the journalctl logs during the time of update to see for clues.
Thank you for your answer.
The only sensible thing I found is this:
packagekitd[1768]: Failed to get cache filename for libva-intel-media-driver
But I don’t know…
Not sure if that message is useful / relevant here.
@mcrha knows better about PackageKit dnf backend messages.
1 Like
Hi,
that libva-intel-media-driver package is somewhat special in Fedora,
if I recall correctly, it clashes in some way with a similarly named
RPMFusion package. I do not recall precisely what it was, I’m sorry,
just that there was something about it.
Not that it should cause the problem in the gnome-software which is
“reported” only once, not consistently for both runs.
I suppose you are upgrading from Fedora Linux 41 (Workstation) to
Fedora 42. Which of the libva-intel-media-driver package you’ve
installed, the one from the Fedora or from the RPMFusion, please? I
would try to reproduce it here.
Bye,
Milan
1 Like
Thank you for taking the issue into consideration. I use the RPM Fusion package (intel-media-driver). The counterparty in Fedora, if I’m not mistaken, is intel-media-driver-free.
Hi,
you are right. They used to have the same app ID in their AppStream
metainfo files, which confused the gnome-software. I do not know the
current state (in Fedora 41), but it probably does not matter.
Meanwhile, I set my Fedora 41 into an up-to-date state, enabled
RPMFusion there, installed the intel-media-driver, then also the
libva-intel-media-driver package, which comes from Fedora repo, not
from the RPMFusion, then I cleaned up the PackageKit’s cache data, and
after restart I let gnome-software (47.5) upgrade the machine to the
Fedora 42. It took some time, but it worked at the end, no error shown.
I do not know whether the local cache cleanup helped here in any way,
or whether I’ve been “just lucky”, or whether more packages are needed
to be installed to reproduce the upgrade problem you faced.
Bye,
Milan
Thank you for addressing this issue and taking the time to do so. What I can tell you is that mine is basically a vanilla installation of Fedora, with some packages installed and/or uninstalled compared to the original version (e.g. gnome-console instead of gnome-terminal, full ffmpeg and GStreamer packages/plugins from RPM Fusion, lm-sensors, intel-media-driver instead of intel-media-driver-free, mesa-va-drivers-freeworld instead of mesa-va-drivers, removed gnome-abrt, added the official Mullvad VPN repository and little else…
In any case, it is not a big bug: in fact, just repeat the update process and everything works correctly (it is as if the error encountered the first time then was ignored the second).
Thank you for addressing this issue and taking the time to do so.
In fact, I did not address anything, I only tried to replicate the
setup and then reproduce the problem with it, but it/I failed, the
update worked fine without me doing anything. I surely missed some
detail(s) in the machine setup which avoided the trigger.
In any case, it is not a big bug: in fact, just repeat the update
process and everything works correctly (it is as if the error
encountered the first time then was ignored the second).
It should work on the first shot though. Maybe a problem with a new
package signature, like rpm not knowing the gpg key yet, or it’s not
trusted yet. The keys are not auto-trusted under the hood, I believe,
but there are multiple tools which can ask the user to trust the new
keys. I understood you did not use any of that, you simply clicked on
the “Upgrade” button again and it passed that time, without asking you
anything, thus it’s possible it has nothing to do with the key trust
anyway.
I’m sorry, no idea what (else) could break here.
1 Like
I thank you in any case