Description of problem:
I installed updates today via the KDE Spin's Discover software. The offline update mechanism successfully installed many packages, but did not include the following updates:
Upgrade mesa-libEGL-21.1.1-1.fc34.i686 @updates
Upgraded mesa-libEGL-21.0.3-2.fc34.i686 @@System
Upgrade mesa-libEGL-21.1.1-1.fc34.x86_64 @updates
Upgraded mesa-libEGL-21.0.3-2.fc34.x86_64 @@System
Upgrade mesa-libEGL-devel-21.1.1-1.fc34.x86_64 @updates
Upgraded mesa-libEGL-devel-21.0.3-2.fc34.x86_64 @@System
Upgrade mesa-vulkan-drivers-21.1.1-1.fc34.i686 @updates
Upgraded mesa-vulkan-drivers-21.0.3-2.fc34.i686 @@System
Upgrade mesa-vulkan-drivers-21.1.1-1.fc34.x86_64 @updates
Upgraded mesa-vulkan-drivers-21.0.3-2.fc34.x86_64 @@System
This left my system booting to a black screen which had to be resolved by entering a tty and finishing the upgrade manually via dnf cli. This is a recurring problem where the dnf offline updates mechanism via discover is not installing _all_ software that's available to update.
Normally this results in upgrades taking 1-3 boots for offline updates to install everything that's available and for the upgrade to thus be fully completed. This is "fine" for most software -- though not ideal -- having to reboot a few times is not that big a deal. However, when this goes as far as breaking the graphics stack because it only partially updated the graphics stack, that's a much more serious issue.
How reproducible: Random, but simi-regularly
Steps to Reproduce:
1. Install updates via Discover
Discover will report that more software updates are available (and they are).
Discover will report that software is fully up to date (and it is).
Created attachment 1786207 [details]
Updates installed by offline updates prior
I'll add this as additional information. This is the output from dnf history, which suggests dnf exited cleanly and installed everything it was supposed to -- with the libEGL and vulkan-drivers packages clearly not included in the list, leading to the broken graphics stack.
Not sure what is going on but it looks like Discover was using old repository metadata. Re-assigning for further investigation.
Created attachment 1845975 [details]
Updates installed by GUI followed by updates that were skipped I had to installed manually
This happened again the other day, I booted into a broken system (and resorted to previously setup SSH to fix it -- haven't figured out Wayland TTYs yet).
I noticed today discover refreshed and showed an update that dnf didn't show until I used "dnf update --refresh". I'm not sure if this is helpful or not, but maybe it's useful to know. Perhaps there's some condition that's causing Discover to update too soon/get a partial update?
Created attachment 1867936 [details]
3/20 series of updates within minutes
This happened again (without breaking anything this time), I had to install updates 4 times today:
838 | | 2022-03-23 12:57 | Upgrade | 2
839 | | 2022-03-23 13:24 | Upgrade | 16
840 | | 2022-03-23 13:42 | Upgrade | 4
841 | | 2022-03-23 13:46 | Upgrade | 3
See the attached file for details of each update. I wonder if this is related to discover polling too frequently/delays in publishing of rpms? Looking a few mirrors, they all seem to have been updated around the same time this morning.
e.g. https://download-cc-rdu01.fedoraproject.org/pub/fedora/linux/updates/35/Everything/x86_64/Packages/m/ all the packages were updated at the same time (2022-03-20 10:12).
Is there a way to find the mirror that was used for the download? This bug is very frustrating (when it breaks something it breaks something badly, when it doesn't, it's a nuisance of repeated reboots).
Thanks for the details, so you're hitting an issue I confirmed upstream awhile back... that discover does not handle multilib updates (e.g. update transactions that include both x86_64 and i686 versions of the same packages), see also
(In reply to Rex Dieter from comment #6)
> Thanks for the details, so you're hitting an issue I confirmed upstream
> awhile back... that discover does not handle multilib updates (e.g. update
> transactions that include both x86_64 and i686 versions of the same
> packages), see also
> Updating summary
I don't think that's it at all. All of these packages were updated via discover, and notice virtually all of them have x86 and x86_64 versions installed at the same time. However, the x86 and x86_64 versions of a particular package are both "not seen" until the previous updates are installed.
This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '35'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version'
to a later Fedora Linux version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora Linux 35 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13.
Fedora Linux 35 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.
If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.
If you are unable to reopen this bug, please file a new report against an
Thank you for reporting this bug and we are sorry it could not be fixed.