| Summary: | Discover says it is offline when trying to update when NetworkManager is in use but not managing any networks | ||
|---|---|---|---|
| Product: | [Applications] Discover | Reporter: | Sol <ssol> |
| Component: | discover | Assignee: | Dan Leinir Turthra Jensen <leinir> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | aleixpol, davehill, elsner, nate |
| Priority: | NOR | ||
| Version: | 5.15.4 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| URL: | https://github.com/hughsie/PackageKit/issues/336 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Sol
2019-05-21 18:39:10 UTC
Same here. Discover says it's offline, while the network is doing ok. Even this bug reporting works from within Discover. Error mesg: "Keine Netzwerkverbindung verfügbar / Cannot download packages whilst offline" and "Cannot refresh cache whilst offline". I also upgraded from kubuntu 18.10 to 19.04. The setup worked fine before the upgrade. I have this too. It seemed to come with upgrade from Debian 9 to 10 last week. Apper has a similar message ("There is no network connection available. Please check your connection settings and try again.").
Workaround: use apt or apt-get (haven't tried other tools)
Here's what Info Centre says about my setup:
Operating System: Debian GNU/Linux 10
KDE Plasma Version: 5.14.5
Qt Version: 5.11.3
KDE Frameworks Version: 5.54.0
Kernel Version: 4.19.0-5-amd64
OS Type: 64-bit
I wonder if this might actually be a problem with PackageKit - it appears to be behind Apper and Discover. When I try to refresh using its console application, pkcon, I get: "Fatal error: Cannot refresh cache whilst offline" Either use NetworkManager to manage at least one network interface or disable it. Checked for reports of PackageKit error and found lots. It seems that PackageKit looks to NetworkManager for online status. If NetworkManager is not managing any network interface (nmcli d), PackageKit concludes its off-line. Disabling NetWorkManager is said to fix the problem: https://github.com/cockpit-project/cockpit/issues/8477. sudo systemctl disable NetworkManager.service That works on my machine. Mine is a Xen host, so I need finer control of the network interface than is available in NetworkManager, so I don't use it. Disabling it was fine for my needs at least. It sounds like another solution might be to actually manage the network interface with NetworkManager. small addition: the update message in the system tray works correctly and acknowlidges pending updates. And yes, apt works ok. Thanks to anyone looking into this! > It seems that PackageKit looks to NetworkManager for online status. If > NetworkManager is not managing any network interface (nmcli d), PackageKit > concludes its off-line. Thanks for uncovering the key information! Since this is an issue in PackageKit, and Discover uses PackageKit for its updates, it looks like there isn;t a way to fix this in Discover. Can you file a bug on PackageKit: https://github.com/hughsie/PackageKit/issues/ ... and then add the link to your PackageKit bug report to the URL field in this one? Thanks! Thank you! Response from PackageKit, closing bug: If you have NetworkManager installed, we expect it to be configured and working. I think PK is doing exactly what it should do here, sorry. In my view, NM is installed, configured and working correctly - unmanaged interfaces are within normal behaviour for NM. Anyone else? Yeah, disappointing resolution from the PackageKit side. :/ Still, if PK won't work properly in this circumstance, there's nothing Discover can do about it. You'll need to plead your case to the PK maintainer or remove NM entirely. FWIW that's what we did in my last job where I was supporting a lot of Linux boxes; if you're not using NM at all, just get rid of it. I have plead my case on the PK bug report. I agree that it's hard to see how Apper or Discover could address this, other than perhaps a more informative error message, but that seems counter-productive and contrary to the PK concept. (In reply to Nate Graham from comment #10) > Yeah, disappointing resolution from the PackageKit side. :/ > > Still, if PK won't work properly in this circumstance, there's nothing > Discover can do about it. You'll need to plead your case to the PK > maintainer or remove NM entirely. FWIW that's what we did in my last job > where I was supporting a lot of Linux boxes; if you're not using NM at all, > just get rid of it. I got this reply to my plea to reopen: Is there anything on the D-Bus interface that tells us to ignore NM? If you work out the library calls we need to do and open a PR I guess we can re-open this. So I'll dig around and see what I can find. Re: removal - yes, sure. I'm not chasing this for me but for the next poor soul who trips across this. It's not exactly obvious what's causing the error. Re: Discover (and Apper) - I agree. They could in theory I suppose trap the "whilst offline" error message and provide more detail, but that'd be as kludgy as can be - as Wikipedia says "clumsy, inelegant, inefficient, difficult to extend and hard to maintain" - so no. |