Hi.
We’ve been a few days enjoying Fedora 43 also the atomics’ users, and now with Plasma 6.5 Kinoite looks great. However, those users that had enabled third-party RPM repositories with subkeys, such as the google-chrome one that is enabled from the welcome page, are not able to update the system after upgrading to 43 (released, not beta). Other popular repositories affected are Tailscale’s.
See Fedora 43 Kinoite Beta failed to add subkeys for google-chrome · Issue #5494 · coreos/rpm-ostree · GitHub , of which an excerpt of the error is:
2 metadata, 0 content objects fetched; 788 B transferred in 1 seconds; 0 bytes content written
Inactive requests:
kernel (already provided by kernel-6.17.0-0.rc5.42.fc43.x86_64)
Checking out tree 6a9f1c3... done
Enabled rpm-md repositories: fedora-cisco-openh264 updates-testing updates fedora copr:copr.fedorainfracloud.org:phracek:PyCharm rpmfusion-nonfree-nvidia-driver rpmfusion-nonfree-steam google-chrome updates-archive
Updating metadata for 'fedora-cisco-openh264'... done
Updating metadata for 'updates-testing'... done
Updating metadata for 'updates'... done
Updating metadata for 'fedora'... done
Updating metadata for 'copr:copr.fedorainfracloud.org:phracek:PyCharm'... done
Updating metadata for 'rpmfusion-nonfree-nvidia-driver'... done
Updating metadata for 'rpmfusion-nonfree-steam'... done
Updating metadata for 'google-chrome'... done
Updating metadata for 'updates-archive'... done
Importing rpm-md... done
rpm-md repo 'fedora-cisco-openh264'; generated: 2025-03-05T10:45:56Z solvables: 6
rpm-md repo 'updates-testing'; generated: 2025-09-17T01:38:11Z solvables: 6553
rpm-md repo 'updates'; generated: 2018-02-20T19:18:14Z solvables: 0
rpm-md repo 'fedora'; generated: 2025-09-16T07:50:12Z solvables: 77562
rpm-md repo 'copr:copr.fedorainfracloud.org:phracek:PyCharm'; generated: 2025-09-02T06:34:48Z solvables: 8
rpm-md repo 'rpmfusion-nonfree-nvidia-driver'; generated: 2025-09-14T09:08:04Z solvables: 17
rpm-md repo 'rpmfusion-nonfree-steam'; generated: 2025-08-13T21:39:54Z solvables: 1
rpm-md repo 'google-chrome'; generated: 2025-09-16T21:24:47Z solvables: 4
rpm-md repo 'updates-archive'; generated: 2025-08-14T03:18:18Z solvables: 0
Resolving dependencies... done
Will download: 20 packages (24.6 MB)
Downloading from 'updates-testing'... done
error: failed to add subkeys for /var/cache/rpm-ostree/repomd/google-chrome-43-x86_64/linux_signing_key.pub to rpmdb
As stated above this issue is persisting after the release date, meaning that the affected Kinoite 43 is no longer just the beta: is the released one.
The obvious workaround is to disable / remove those repositories, but this would eventually remove the orphaned packages from the system, leaving the users waiting for the relevant upgrade for libdnf –at least.
Now the point is the following: we’ve been discussing in the linked issue above whether or not this should have blocked the release of the atomics. Probably that was the wrong place and we’ve been told to bring the conversation here (to which I agree), and my point is the following: given that Fedora Kinoite is presented as the following, isn’t this bug serious enough to re-evaluate the release criteria of those atomic editions?
Surf the web, keep in touch with friends, manage files, enjoy music and video, and get productive at work without having to worry about breaking your system.
I understand all editions are released with a single blocking criteria and the whole ecosystem is growing big, and it’s complex, and we all appreciate the work. However, the above motto seems to offer the Kinoite edition to a cohort of users that may not understand the issue behind, know how to disable the repos, or even find the linked issue with the hint to disable the repos.
Should the atomics have their own release-blocking criteria?