fedora-kde / SIG

#51 Discover's first launch takes a very long time
Closed: Fixed by eiglow. Opened by eiglow.

Closed: Fixed
Reopen Issue

Running it from the terminal, here is the full output:

file:///usr/lib64/qt5/qml/org/kde/kirigami.2/ActionToolBar.qml:109:18: QML ToolBarLayout: Binding loop detected for property "actions"
could not list fwupd remotes Error calling StartServiceByName for org.freedesktop.fwupd: Timeout was reached
adding empty sources model FwupdSourcesModel(0x5638eb12bcc0)
invalid kns backend! "/usr/share/knsrcfiles/servicemenu.knsrc" because: "Config group not found! Check your KNS3 installation."
kf.newstuff.core: The CustomName property is deprecated and will be removed in KF6
kf.newstuff.core: The ChecksumPolicy feature is defunct
kf.newstuff.core: The SignaturePolicy feature is defunct
kf.newstuff.core: The ChecksumPolicy feature is defunct
kf.newstuff.core: The SignaturePolicy feature is defunct
adding empty sources model QStandardItemModel(0x5638eb909010)
org.kde.plasma.libdiscover: Couldn't find a category for  "fwupd-backend"
file:///usr/lib64/qt5/qml/org/kde/kirigami.2/private/PrivateActionToolButton.qml:74:5: QML Binding: Binding loop detected for property "value"
Could not open the AppStream metadata pool "Many components have been recognized as invalid. See debug output for details."
The Theme singleton is deprecated (since 5.39). Import Kirigami 2.2 or higher and use the attached property instead.

Notice the lines about fwupd, I think it hangs on that. This might also be the cause of the AppStream message that comes up when you start up discover, but I don't know.

Please report the fwupd-backend thing upstream to bugs.kde.org, the sooner they know about this the better.

Please report the fwupd-backend thing upstream to bugs.kde.org, the sooner they know about this the better.

Well I reported it here because I didn't experience this on my Neon Unstable VM. So maybe it's something that's been fixed between the current version of stuff in f34 and the current version of stuff in Neon Unstable, but either way, it's still currently an issue in f34.

I believe we might be hitting this bug. I found that fwupd.service itself wasn't loaded but inactive until starting Discover, which seemed to cause it to start. Although, the whole time that discover is stuck, fwupd is in an "activating" state, right up until discover finally starts. Maybe it should start automatically upon login, and that could avoid this issue? I'm not an expert on these things though, I could be wrong.

As of now, this doesn't happen anymore. The appstream message is still there, but I guess its unrelated.

Metadata Update from @eiglow:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.