Fedora Account System
Red Hat Associate
Red Hat Customer
After updating my Fedora system from 43 to 44, GNOME Software can stay on the startup loading page with the "Refreshing Data" message (`gs-loading-page.c`) and not continue. This seems related to an enabled dnf repository which needs OpenPGP key confirmation while repository metadata is being refreshed. In my case the repository is a third-party repo, and I have not installed packages from it yet, so its signing key had not been imported before. Running dnf directly shows the key prompt: ``` $ LANG=en_US.UTF-8 dnf repo info cursor --refresh ... Redacted 100% | 2.5 KiB/s | 4.3 KiB | 00m02s >>> repomd.xml GPG signature verification error: Signing key not found https://downloads.reacted.com/keys/redacted.asc 100% | 6.6 KiB/s | 1.6 KiB | 00m00s Importing OpenPGP key redacted: User ID :"redacted" Fingerprint: redacted From : https://downloads.redacted.com/keys/redacted.asc Is this ok [y/N]: ``` Looking at the dnf5 plugin code, GNOME Software appears to have handling for dnf5daemon `repo_key_import_request` during transaction handling. However, I suspect the startup metadata refresh path is different: it calls `read_all_repos`, and if dnf5daemon asks for key confirmation there, GNOME Software may not answer that request. In this startup case, the refresh is non-interactive, so I do not think GNOME Software should unexpectedly import the key or show a prompt before the shell is loaded. But it also should not stay on the loading page indefinitely. A reasonable behavior might be to reject the key request for the non-interactive refresh and let dnf5daemon skip the unavailable repository, or otherwise fail the refresh quickly with a visible/logged error. Reproducible: Always Steps to Reproduce: 1. Have an enabled dnf repository whose repository metadata requires OpenPGP key confirmation, and whose key has not been imported yet. 2. Start GNOME Software. Actual Results: GNOME Software stays on the startup loading page with the "Refreshing Data" message and does not continue. I had to kill it manually. The dnf5daemon journal around the same time shows the repository key/signature problem and the repository being skipped: ```text 4월 29 01:57:05 redacted-hostname dnf5daemon-server[25524]: 2026-04-28T16:57:05+0000 [25524] DEBUG Metadata removal from repository cache in path "/var/cache/dnf5daemon-server/redacted-redacted" complete. Removed 4 files, 1 directories (total of 106839 bytes). 0 errors 4월 29 01:57:05 redacted-hostname dnf5daemon-server[25524]: 2026-04-28T16:57:05+0000 [25524] DEBUG Solv files removal from repository cache in path "/var/cache/dnf5daemon-server/redacted-redacted" complete. Removed 2 files, 1 directories (total of 177522 bytes). 0 errors 4월 29 01:57:06 redacted-hostname dnf5daemon-server[25524]: 2026-04-28T16:57:06+0000 [25524] WARNING Error loading repo "redacted" (skipping due to "skip_if_unavailable=true"): 4월 29 01:57:06 redacted-hostname dnf5daemon-server[25524]: 2026-04-28T16:57:06+0000 [25524] WARNING std::exception ``` Expected Results: GNOME Software should not stay on the loading page indefinitely. Additional Information: ``` $ rpm -qa | grep -E "^(dnf5-5|gnome-software-50)" dnf5-5.4.2.0-1.fc44.x86_64 gnome-software-50.1-2.fc44.x86_64 ```
Filed a PR with a fix: https://src.fedoraproject.org/rpms/gnome-software/pull-request/14
Probably a duplicate of bug 2458182 .
Thanks for a bug report and the patch, I commented on the patch. Kamil, the article [1], it's a bit misleading. The problem is not `repo_gpgcheck=1`, but that some repos do not have imported their keys. A valid fix (or workaround, if you wish) is to import that key, which can be done by `sudo dnf update`, because dnf asks for the key import on the command line. The repository and its apps uninstallation is inconvenient and unneeded. [1] https://discussion.fedoraproject.org/t/gnome-software-is-unresponsive-when-a-repository-with-repo-gpgcheck-1-exists/189222
(In reply to Milan Crha from comment #3) > Kamil, the article [1], it's a bit misleading. The problem is not > `repo_gpgcheck=1`, but that some repos do not have imported their keys. That's great feedback, but it doesn't seem to be the case at least on my system. The key seems imported here and the problem persists. $ cat /etc/yum.repos.d/cursor.repo [cursor] name=Cursor baseurl=https://downloads.cursor.com/yumrepo enabled=1 gpgcheck=1 gpgkey=https://downloads.cursor.com/keys/anysphere.asc repo_gpgcheck=1 $ rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n' | grep -iE "cursor|anysphere" gpg-pubkey-380ff4bcdc34a4bd92a3565342a1772e62e492d6-686ffed8 Anysphere Inc <security> public key $ curl -sL https://downloads.cursor.com/keys/anysphere.asc | gpg --show-keys pub rsa4096 2025-07-10 [SC] 380FF4BCDC34A4BD92A3565342A1772E62E492D6 uid Anysphere Inc <security> I even ran $ sudo rpm --import 'https://downloads.cursor.com/keys/anysphere.asc' manually, but no change. I update through `dnf distro-sync --offline` regularly, didn't see a prompt. As mentioned in bug 2458182 comment 9 , this is also broken just by running `dnf5daemon-client repoinfo`, so it doesn't seem to be specific to gnome-software.
> I update through `dnf distro-sync --offline` regularly, didn't see a prompt. Hmm, I do not know how much it's the same as running plain `dnf update`. It probably is the same in this regard. being it so, you probably face a different problem then? > this is also broken just by running `dnf5daemon-client repoinfo`, so it doesn't seem to be specific to gnome-software. Right, right, either it's some problem in the dnf5daemon-server, or it's caused by the way the clients use the D-Bus API, like in case of the gnome-software, when it does not respond to the key import questions.
> $ cat /etc/yum.repos.d/cursor.repo Nice, I can reproduce it with your repo too. I also verified both distro-sync and update commands ask for the key when it's not imported. The dnf5damon server is waiting in: Thread 3 (Thread 0x7f876f7fe6c0 (LWP 4245) "dnf5daemon-serv"): #0 0x00007f8777c80e92 in __syscall_cancel_arch () at /lib64/libc.so.6 #1 0x00007f8777c750cc in __internal_syscall_cancel () at /lib64/libc.so.6 #2 0x00007f8777c75417 in __futex_abstimed_wait_cancelable64 () at /lib64/libc.so.6 #3 0x00007f8777c780ec in pthread_cond_clockwait () at /lib64/libc.so.6 #4 0x000055c573a842f1 in dnf5daemon::KeyImportRepoCB::repokey_import(libdnf5::rpm::KeyInfo const&) () #5 0x00007f877836b00d in libdnf5::repo::RepoPgp::import_key(int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () at /lib64/libdnf5.so.2 #6 0x00007f8778370bfe in libdnf5::repo::RepoSack::Impl::update_and_load_repos(libdnf5::repo::RepoQuery&, bool) [clone .constprop.0] () at /lib64/libdnf5.so.2 #7 0x00007f8778371f36 in libdnf5::repo::RepoSack::load_repos() () at /lib64/libdnf5.so.2 #8 0x000055c573ac479e in Session::read_all_repos() () #9 0x000055c573a8f28d in Base::read_all_repos(sdbus::MethodCall&) () #10 0x000055c573a92acb in std::thread::_State_impl<std::thread::_Invoker<std::tuple<ThreadsManager::handle_method<Base, true>(Base&, sdbus::MethodReply (Base::*)(sdbus::MethodCall&), sdbus::MethodCall&, std::optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >)::{lambda(Base&, sdbus::MethodReply (Base::*)(sdbus::MethodCall&), sdbus::MethodCall, std::optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >)#1}, std::reference_wrapper<Base>, sdbus::MethodReply (Base::*)(sdbus::MethodCall&), sdbus::MethodCall, std::optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > >::_M_run() () #11 0x00007f8777e51eb6 in execute_native_thread_routine () at /lib64/libstdc++.so.6 #12 0x00007f8777c787b9 in start_thread () at /lib64/libc.so.6 #13 0x00007f8777cfcacc in __clone3 () at /lib64/libc.so.6 Thread 2 (Thread 0x7f876effd6c0 (LWP 4246) "dnf5daemon-serv"): #0 0x00007f8777c80e92 in __syscall_cancel_arch () at /lib64/libc.so.6 #1 0x00007f8777c750cc in __internal_syscall_cancel () at /lib64/libc.so.6 #2 0x00007f8777c75417 in __futex_abstimed_wait_cancelable64 () at /lib64/libc.so.6 #3 0x00007f8777c77c6c in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libc.so.6 #4 0x00007f8777e480e0 in std::condition_variable::wait(std::unique_lock<std::mutex>&) () at /lib64/libstdc++.so.6 #5 0x00007f87783788d0 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<libdnf5::repo::RepoSack::Impl::update_and_load_repos(libdnf5::repo::RepoQuery&, bool)::{lambda()#1}> > >::_M_run() [clone .lto_priv.0] () at /lib64/libdnf5.so.2 #6 0x00007f8777e51eb6 in execute_native_thread_routine () at /lib64/libstdc++.so.6 #7 0x00007f8777c787b9 in start_thread () at /lib64/libc.so.6 #8 0x00007f8777cfcacc in __clone3 () at /lib64/libc.so.6
Can you reproduce the problem even when the key is correctly imported?
On my system, /var/cache/libdnf5/redacted-redacted/pubring exists, but /var/cache/dnf5daemon-server/redacted-redacted/pubring does not. So this may not be related to `rpm --import`; the daemon appears to use a separate cache/keyring location. I am not completely sure yet, but that difference seems relevant.
> Can you reproduce the problem even when the key is correctly imported? Yeah, the backtrace is from the time when it was imported for the dnf command line. > So this may not be related to `rpm --import` I've been told, and the last time I tried it, the keys are in `rpmkeys -l` and when I've been testing the key import prompt in the dnf5 gnome-software plugin I used the rpmkeys to trigger it (I simply removed the keys). It's some time ago though, it can be the dnf5 changed something meanwhile, which splits the rpm keys or anything else.
Fix from Byoungchan [1] on the gnome-software side helps: 10:06:39:412 GsDnf5 gs_dnf5_repo_key_import_request_cb: key_id:'62E492D6' user_ids:["Anysphere Inc <security>"] key_fingerprint:'380FF4BCDC34A4BD92A3565342A1772E62E492D6' key_url:'https://downloads.cursor.com/keys/anysphere.asc' timestamp:1752170200 10:06:39:412 GsDnf5 gs_dnf5_repo_key_import_request_cb: rejecting non-interactive repository key import request for key '62E492D6' With it gnome-software starts flawlessly. [1] https://gitlab.gnome.org/mcrha/gnome-software/-/merge_requests/1
(In reply to Byoungchan Lee from comment #8) Not sure if it's expected or not, but I can confirm the same on my system: $ ls /var/cache/libdnf5/cursor-57cee92e3e966e02/pubring/ 42A1772E62E492D6.pub $ ls /var/cache/dnf5daemon-server/cursor-57cee92e3e966e02/pubring ls: cannot access '/var/cache/dnf5daemon-server/cursor-57cee92e3e966e02/pubring': No such file or directory $ ls /var/cache/dnf5daemon-server/cursor-57cee92e3e966e02/ repodata solv
Like I mentioned in previous comments, I think the best fix is to make both sides defensive: the server (`dnf5daemon`) and clients (`dnf5daemon-client`, GNOME Software, and so on). I also reproduced the `dnf5daemon-client repoinfo` hang, captured a stack trace, and found two related issues: - On the client side, `dnf5daemon-client repoinfo` makes a synchronous D-Bus call. This is similar to the GNOME Software refresh case: the call can trigger a repository key-import request, but the client is blocked waiting for the original method reply and cannot handle the prompt path, so it cannot make progress. - On the server side, the daemon can ask for interactive confirmation even when the client may not be able to handle it. I made two commits and uploaded a draft PR here: https://github.com/rpm-software-management/dnf5/pull/2716 Since this changes `dnf5daemon` behavior, I am not fully sure whether the changes are valid in terms of D-Bus API contract or compatibility, so I opened it as a draft. From my testing, either side of the fix is enough to avoid the `dnf5daemon-client repoinfo` hang, but they address different parts of the same failures.
FEDORA-2026-64904d9210 (gnome-software-50.1-3.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-64904d9210
FEDORA-2026-64904d9210 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-64904d9210` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-64904d9210 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Unfortunately this doesn't help in my case. GS still takes 5 minutes to load the app icons on the welcome screen. From the verbose log: 07:10:58:723 GsPluginFlatpak org.winehq.Wine.mono needs update 07:10:58:723 OSTree using fuse: 0 07:10:58:723 flatpak Checking installation ‘user’ for EOL unused refs and autoprunes 07:10:58:723 flatpak Checking installation ‘user’ for EOL unused refs and autoprunes 07:10:58:723 OSTree using fuse: 0 07:15:01:287 Gs Setting I/O priority of thread 0x55bc79fc8ec0 to IDLE, 7 07:15:01:287 GsDnf5 Using existing session 07:15:01:287 Gs Setting I/O priority of thread 0x55bc79fa2c10 to IDLE, 7 07:15:01:287 Gs Downloading 2 icons for app org.gnome.Polari 07:15:01:287 GsPluginMalcontent No OARS ratings provided for ‘*/*/*/app.drey.Dialect/*’: assuming most extreme 07:15:01:287 GsPluginMalcontent No OARS ratings provided for ‘*/*/*/de.haeckerfelix.Fragments/*’: assuming most extreme
Created attachment 2138845 [details] GS verbose log
Icons have nothing to do with pgp keys, the less with the dnf5 (or PackageKit) plugin. You rather mean: https://gitlab.gnome.org/GNOME/gnome-software/-/work_items/2966 The log shows the Software does download the icons, one by one, but it may want a lot of icons, thus those you look at can be "at the end of the queue". Some failed, but most had been downloaded.
Sorry, that was confusing. I said icons, but I meant "nothing changed, gnome-software is still completely blank and none of the pages work". I meant this: https://gitlab.gnome.org/GNOME/gnome-software/-/work_items/2975 And similarly, every other page has just white rectangles with three dots, or infinite spinners, until 5 minutes pass, and then it starts working. As seen from the log.
Unfortunately the log does not show what it is trying to do between those 5 minutes: 07:10:58:723 flatpak Checking installation ‘user’ for EOL unused refs and autoprunes 07:10:58:723 OSTree using fuse: 0 07:15:01:287 Gs Setting I/O priority of thread 0x55bc79fc8ec0 to IDLE, 7 07:15:01:287 GsDnf5 Using existing session The dnf5 plugin is not much verbose in logging. I understood you are a bit more further in the process, as before it has got stuck within "Refreshing metadata", while this time you see the Explore page and the others, just the icons are an indication that the app is waiting for something. Is that correct? Could you get a backtrace of the gnome-software process, please? DEBUGINFOD_URLS='' gdb --batch --ex "t a a bt" --pid=`pidof gnome-software` &>bt.txt It will show what it's doing. The log shows only three related GsDnf5 lines in the log for the first five minutes, where the pasted line above is the third.
I just re-tried with gnome-software-50.1-3.fc44.x86_64 and I cannot reproduce it, while with 50.1-2 I can. I have your repo set, but I do not have anything installed from it.
Created attachment 2138867 [details] bug demonstration video I have recorded a video so that you can understand exactly how GS behaves while being stuck. In my previous log file, I wasn't doing anything, I kept it waiting on the home screen, and exactly 5 minutes later, it comes to live and suddenly everything works. In this video, I explore all the tabs, which does print new lines into the log. I can collect that log if you want and upload it here. I'll try to collect the backtrace as well.
Backtrace of gnome-software and dnf5daemon-server processes will be the best. The log is useless in this case.
I've tested a clean F44 VM with default F44 Workstation install, updated to latest stable updates. Installed cursor-3.2.16.el8.x86_64.rpm there from vendor website (which adds the repo during installation). Ran a "dnf update", which asked to add the cursor gpg key, I did. With gnome-software-0:50.1-2, the GS interface was unusable. After updating to gnome-software-0:50.1-3, it works perfectly. Interesting, there must be something else on my production setup. Furthermore, I'm baffled that in the VM, I don't see the cursor gpg key listed, even though I confirmed adding it: $ rpmkeys -l 36f612dcf27f7d1a48a835e4dbfcf71c6d9f90a6 Fedora (44) <fedora-44-primary> public key $ rpm -q gpg-pubkey --qf '%{SUMMARY}: %{VERSION}-%{RELEASE}\n' Fedora (44) <fedora-44-primary> public key: 36f612dcf27f7d1a48a835e4dbfcf71c6d9f90a6-6786af3b But on my production system, it's there (comment 4).
Created attachment 2138870 [details] backtrace while GS UI is non-functional Here's the requested backtrace from GS while it's non-functional on my production system.
Created attachment 2138871 [details] backtrace from dnf5daemon-server This is from dnf5daemon-server, taken half a minute later. (I can do better next time, if needed).
Thanks for the backtraces. I see it's the same problem, the dnf5daemon-server is waiting for a response from the client(s) on the key import, but gnome-software is in "list" call, checking for packages, which I'd not expect to also need to import the key. I'm investigating further.
There seem to be two incompatible storage areas for GPG keys: Machine 1 - a key added through rpm --import is not seen by DNF: $ rpmkeys -l 36f612dcf27f7d1a48a835e4dbfcf71c6d9f90a6 Fedora (44) <fedora-44-primary> public key $ sudo rpm --import 'https://downloads.cursor.com/keys/anysphere.asc' $ rpmkeys -l 380ff4bcdc34a4bd92a3565342a1772e62e492d6 Anysphere Inc <security> public key 36f612dcf27f7d1a48a835e4dbfcf71c6d9f90a6 Fedora (44) <fedora-44-primary> public key $ sudo dnf update Updating and loading repositories: Cursor 100% | 6.7 KiB/s | 4.3 KiB | 00m01s >>> repomd.xml GPG signature verification error: Signing key not found https://downloads.cursor.com/keys/anysphere.asc 100% | 4.0 KiB/s | 1.6 KiB | 00m00s Importing OpenPGP key 0x62E492D6: UserID : "Anysphere Inc <security>" Fingerprint: 380FF4BCDC34A4BD92A3565342A1772E62E492D6 From : https://downloads.cursor.com/keys/anysphere.asc Is this ok [y/N]: Machine 2 - a key added through DNF is not seen by rpmkeys: $ rpmkeys -l 36f612dcf27f7d1a48a835e4dbfcf71c6d9f90a6 Fedora (44) <fedora-44-primary> public key $ sudo dnf update Updating and loading repositories: Cursor 100% | 4.8 KiB/s | 4.3 KiB | 00m01s >>> repomd.xml GPG signature verification error: Signing key not found https://downloads.cursor.com/keys/anysphere.asc 100% | 8.7 KiB/s | 1.6 KiB | 00m00s Importing OpenPGP key 0x62E492D6: UserID : "Anysphere Inc <security>" Fingerprint: 380FF4BCDC34A4BD92A3565342A1772E62E492D6 From : https://downloads.cursor.com/keys/anysphere.asc Is this ok [y/N]: y The key was successfully imported. Cursor 100% | 164.6 KiB/s | 174.5 KiB | 00m01s Repositories loaded. Nothing to do. $ rpmkeys -l 36f612dcf27f7d1a48a835e4dbfcf71c6d9f90a6 Fedora (44) <fedora-44-primary> public key I don't know whether it can explain why some machines are still affected by this bug, and some are not, but I suppose it could.
(In reply to Kamil Páral from comment #27) > There seem to be two incompatible storage areas for GPG keys: Reported as bug 2464087
With this PR, GS works great for me: https://github.com/rpm-software-management/dnf5/pull/2717
*** Bug 2464668 has been marked as a duplicate of this bug. ***
FEDORA-2026-64904d9210 (gnome-software-50.1-4.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.