Issues with Flatpak Updates in Discover & CLI

[tiryns (Mycenius)]

As fate would have it - it just failed again - there were about 20-25 updates in Discover and 13 failed with VPN connected. 13 instances of:

While fetching https://cdn.registry.fedoraproject.org/deltas/ba/a108bc8a6dd7b939f55acf8c045a901200f48c17da5a82840902d55ed9de1e.tardiff: [56] Failure when receiving data from the peer

A retry also failed, it included mostly system updates and similar, plus a few apps:

However they all updated fine via sudo flatpak update via the VPN. (Note: I’ve removed the ‘no longer supported’ notifications - same as were in the earlier run log I posted):

        ID                                                     Branch                  Op             Remote              Download
 1. [✓] org.fedoraproject.Platform                             f44                     u              fedora              10.7 MB / 516.2 MB
 2. [✓] org.freedesktop.Platform.Compat.i386                   26.08                   u              flathub              3.2 MB / 140.1 MB
 3. [✓] org.freedesktop.Platform.GL.default                    26.08                   u              flathub              3.3 MB / 150.5 MB
 4. [✓] org.freedesktop.Platform.GL.default                    26.08-extra             u              flathub              3.3 MB / 150.5 MB
 5. [✓] org.freedesktop.Platform.GL32.default                  26.08                   u              flathub              3.4 MB / 160.4 MB
 6. [✓] org.freedesktop.Platform.GL32.default                  26.08-extra             u              flathub              2.3 MB / 160.4 MB
 7. [✓] org.freedesktop.Platform.Locale                        26.08                   u              flathub             18.6 kB / 385.2 MB
 8. [✓] org.freedesktop.Platform.codecs-extra                  26.08-extra             u              flathub             74.0 kB / 15.7 MB
 9. [✓] org.freedesktop.Platform.codecs_extra.i386             26.08-extra             u              flathub             73.2 kB / 14.7 MB
10. [✓] org.freedesktop.Platform                               26.08                   u              flathub              7.1 MB / 281.7 MB
        ID                                                     Branch                  Op             Remote              Download
 1. [✓] org.fedoraproject.Platform                             f44                     u              fedora              10.7 MB / 516.2 MB
 2. [✓] org.freedesktop.Platform.Compat.i386                   26.08                   u              flathub              3.2 MB / 140.1 MB
 3. [✓] org.freedesktop.Platform.GL.default                    26.08                   u              flathub              3.3 MB / 150.5 MB
 4. [✓] org.freedesktop.Platform.GL.default                    26.08-extra             u              flathub              3.3 MB / 150.5 MB
 5. [✓] org.freedesktop.Platform.GL32.default                  26.08                   u              flathub              3.4 MB / 160.4 MB
 6. [✓] org.freedesktop.Platform.GL32.default                  26.08-extra             u              flathub              2.3 MB / 160.4 MB
 7. [✓] org.freedesktop.Platform.Locale                        26.08                   u              flathub             18.6 kB / 385.2 MB
 8. [✓] org.freedesktop.Platform.codecs-extra                  26.08-extra             u              flathub             74.0 kB / 15.7 MB
 9. [✓] org.freedesktop.Platform.codecs_extra.i386             26.08-extra             u              flathub             73.2 kB / 14.7 MB
10. [✓] org.freedesktop.Platform                               26.08                   u              flathub              7.1 MB / 281.7 MB
11. [✓] me.proton.Pass                                         stable                  u              flathub             34.8 MB / 144.3 MB
12. [✓] me.proton.Mail                                         stable                  u              flathub              2.0 MB / 115.8 MB
13. [✓] com.tutanota.Tutanota                                  stable                  u              flathub             29.3 MB / 160.5 MB
14. [✓] org.standardnotes.standardnotes.Locale                 stable                  u              flathub              6.6 kB / 11.0 MB
15. [✓] org.standardnotes.standardnotes                        stable                  u              flathub              1.4 MB / 157.3 MB

Updates complete.

[pg-tips (P G)]

@tiryns

Yes. Again intermittently and about as frequently as it does with random apps.

However I’ve also never seen dnf update fail on anything when I’ve tried it (but that’s only been occasionally - I haven’t tried it every time Discover has failed).

This is interesting. Next time you have this situation (i.e. Discover fails on an update containing pure dnf content, nothing Flatpak-related) it would be good to see what errors appear in the journal.

[barryascott]

Only when the VPN is active do you see failures?
That sounds like a networking issue that the VPN causes.

[tiryns (Mycenius)]

@barryascott

That sounds like a networking issue that the VPN causes.

I have assumed thats highly unlikely to be the case as (mentioned previously) it only manifests for updates and only on VPN in my country; never for anything else or any other site or service I access through the VPN. It also doesn’t manifest if I use VPN through a different country (e.g. US or UK) for updates.

Only thing I haven’t explored is if its related to repository / Fastly CDN mirrors located in NZ - if any. But I had ruled that out regardlesd as it works fine without VPN so even if there are its probably not the cause.

[tiryns (Mycenius)]

Just FWIW had another error that was flatpak related (this time with GIMP). Both Discover and sudo flatpak update had the same error log/description (see below from the latter):

sudo flatpak update
Looking for updates…
error: While fetching https://dl.flathub.org/repo/summaries/dd6aafc620026a67908aa68324e050c645371b9290e1672e6fa6d303601f9bfa.gz: [56] Failure when receiving data from the peer

Disconnecting the VPN and retrying allowed it to complete the update successfully.

Haven’t had another failure on a system update as yet…

[barryascott]

I wonder if the VPN sets the MTU size too big?

[tiryns (Mycenius)]

I’m using wireguard and the default setting for the MTU for that protocol is currently automatic. Which looks like it sets it to 1420:

netstat -i
Kernel Interface table
Iface             MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
enp4s0           1500    59534      0      1 0         23036      0      0      0 BMRU
lo              65536       34      0      0 0            34      0      0      0 LRU
proton0          1420    55367      0      0 0         22631      0      0      0 OPRU
pvpnksintrf0     1500        0      0      0 0           204      0      0      0 BORU

(proton0 is the active VPN connection, and pvpnksintrf0 is the local ‘killswitch’ interface for it.)

EDIT: Looks like 1420 (1392 + 28) should be fine for dl.flathub.org?

ping -M do -s 1392 dl.flathub.org -c 4
PING dualstack.n.sni.global.fastly.net (151.101.xxx.xx) 1392(1420) bytes of data.
1400 bytes from 151.101.xxx.xx: icmp_seq=1 ttl=59 time=15.7 ms
1400 bytes from 151.101.xxx.xx: icmp_seq=2 ttl=59 time=15.9 ms
1400 bytes from 151.101.xxx.xx: icmp_seq=3 ttl=59 time=16.7 ms
1400 bytes from 151.101.xxx.xx: icmp_seq=4 ttl=59 time=16.1 ms

--- dualstack.n.sni.global.fastly.net ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 15.695/16.105/16.654/0.353 ms

P.S. This is it’s cap - anything above this fails (e.g. 1428):

ping -M do -s 1400 dl.flathub.org -c 4
PING dualstack.n.sni.global.fastly.net (151.101.xxx.xx) 1400(1428) bytes of data.
ping: sendmsg: Message too long
ping: sendmsg: Message too long
ping: sendmsg: Message too long
ping: sendmsg: Message too long

--- dualstack.n.sni.global.fastly.net ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3068ms

[tiryns (Mycenius)]

Here’s the latest failure example where 3 GNOME updates failed in Discover, and with flatpak update in CLI:

While pulling runtime/org.gnome.Platform/x86_64/50 from remote flathub: While fetching https://dl.flathub.org/repo/objects/fc/b865726be8e8df01fe612c3b33e45c834d15787a1cecf59017ce369d2d31b2.filez: [56] Failure when receiving data from the peer
While pulling runtime/org.gnome.Platform/x86_64/50 from remote flathub: While fetching https://dl.flathub.org/repo/objects/fc/b865726be8e8df01fe612c3b33e45c834d15787a1cecf59017ce369d2d31b2.filez: [56] Failure when receiving data from the peer
While pulling runtime/org.gnome.Platform/x86_64/50 from remote flathub: While fetching https://dl.flathub.org/repo/objects/fc/b865726be8e8df01fe612c3b33e45c834d15787a1cecf59017ce369d2d31b2.filez: [56] Failure when receiving data from the peer

sudo flatpak update
Looking for updates…

        ID                          Branch         Op         Remote          Download
 1. [✗] org.gnome.Platform          51             u          flathub         43.2 MB / 432.2 MB
 2. [✗] org.gnome.Platform          50             u          flathub         35.4 MB / 419.7 MB
 3. [✗] org.gnome.Platform          49             u          flathub         43.0 MB / 418.8 MB

Error: While pulling runtime/org.gnome.Platform/x86_64/51 from remote flathub: While fetching https://dl.flathub.org/repo/objects/75/fa1e5c79042ee228c957d5a21f12587c19f8a615a880f26c76b6047d4cd074.filez: [56] Failure when receiving data from the peer
Error: While pulling runtime/org.gnome.Platform/x86_64/50 from remote flathub: While fetching https://dl.flathub.org/repo/objects/fc/b865726be8e8df01fe612c3b33e45c834d15787a1cecf59017ce369d2d31b2.filez: [56] Failure when receiving data from the peer
Error: While pulling runtime/org.gnome.Platform/x86_64/49 from remote flathub: While fetching https://dl.flathub.org/repo/objects/41/ab4aade58c3cd95dd264a64b6dbbdd0485fba8c14595f21b87651a01ea1a65.filez: [55] Failed sending data to the peer
Updates complete.
error: There were one or more errors

They all seem to start download successfully, then fail partway through - the initial download that happens before the failure can appear to be unusually slow BTW (I am on a very fast fibre connection, but data is often significantly slower through the VPN than what my raw connection is capable of). So could that indicate something other than MTU setting causing a time out or similar disconnection (given CLI run log show 2 failed receiving data from flathub, then third failed due to couldn’t send data to flathub)?

[tiryns (Mycenius)]

Looking around I’m starting to wonder if my issue is related to the one described a year ago below - my issues been on going for some time too so may actually date from last year (if been using Linux full time as my daily driver now for 21+ months) - and the above errors suggest something potentially related to the issues in the below thread (connection speed, stability of connection, etc) - although doesn’t seem there was a resolution for the OP:

Flathub Fastly CDN have slow connection in PL

This has been going on for over a year since I started playing with Linux desktop, across all distros I have tried: Flatpak sucks badly, to the point of being unusable. RPM, APT, whatever… flies, I can install Krita from RPM in a matter of seconds. Installing a small utility from Flathub can take 10-20 minutes. It crawls at tens of KILOBYTES per second. Every time I’m doing a new Linux install I want to scream in rage. I’m stuck again… Doing a fresh F43 install and I have been unable to instal…

[tiryns (Mycenius)]

Further update - had the issue again today with various flatpak updates (both in Discover and CLI flatpak update). Disconnecting VPN resolved the issue.

I’ve also looked at this recent thread below (August) that sounds vaguely similar on the surface (hanging during update). Doesn’t look to be related though, but I have done the cache clearance, etc, listed in the solution post in it - just to be safe. Will see if that eliminates future issues with next updates (and/or will retry it just to see if I get an issue). But I’m assuming this is not likely to be my issue:

Discover fails to fetch updates due to Fedora OCI Flatpak remotes (system,oci)

Hi! This is my first time reporting a bug. I have been using Fedora for some time, starting from Fedora 42 Workstation, and now for the last couple of months I am using Fedora 44 KDE Desktop Edition. The experience is quite smooth, except for a recent hiccup. Whenever there is a pop-up for new update, opening Discover and checking for it keeps the “Fetching update” screen hung up indefinitely. This surfaced a few weeks ago, and I for the time being installed the updates from Konsole. However, I…

P.S. for the record my my flatpak repo status is (and has always been):

flatpak remotes
Name    Options
fedora  system,oci
flathub system

[kingshukargha (Kingshuk Chakravorty)]

Hey there!

Yours and my issue sounds quite similar, although a point to note is that I do not use any VPN on my laptop. I can suggest you one fix that has worked for me: keep the flatpak repos as they are. In Discover, untick the Fedora Flatpaks (testing) repo (check the image).

Hope that helps. I do not think it to be a Fedora specific issue though; could be related to Discover/KDE itself.

[tiryns (Mycenius)]

@kingshukargha

I can suggest you one fix that has worked for me: keep the flatpak repos as they are. In Discover, untick the Fedora Flatpaks (testing) repo (check the image).

Thanks - yes I saw the other thread I thought your issue and mine might be related in some way. However I already don’t (use testing) - and I’ve never had the testing repo enabled in Discover - so that won’t be the cause of my issue unfortunately…

Although I’m not convinced the VPN is the direct cause of the issue, I have recently switched to the ProtonVPN beta, on the off chance that might have some effect in the issue with any new capability… But I feel pretty sure it’s something to with the repo host (whether the MTU size idea @barryascott suggested, or something else similar causing an unstable connection at that end).

@kingshukargha

I do not think it to be a Fedora specific issue though; could be related to Discover/KDE itself.

No, it’s not a Discover (or Fedora OS) specific issue anymore, as originally it seemed that way but have since had sudo flatpak update errors with CLI updates. So definitely a comms / connectivity issue with the repo host(s).

[tiryns (Mycenius)]

@tiryns

No, it’s not a Discover (or Fedora OS) specific issue anymore

P.S. I’d edit the thread title to reflect that but this forum doesn’t permit editing of titles.

[barryascott]

@tiryns

I’d edit the thread title to reflect that but this forum doesn’t permit editing of titles.

Editing depends on the trust level of your account.
I’d be happy to update the title for you; what do you suggest the new title should be?

[tiryns (Mycenius)]

@barryascott

Editing depends on the trust level of your account.

Good point - I’d forgotten I haven’t actually posted as much here as I have on some other (discourse) forums.

@barryascott

I’d be happy to update the title for you; what do you suggest the new title should be?

Thanks Barry - maybe just: “Issues with Flatpak Updates in Discover & CLI”

[pg-tips (P G)]

@tiryns

Thanks Barry - maybe just: “Issues with Flatpak Updates in Discover & CLI”

And specifically with Flathub, right?

[tiryns (Mycenius)]

Yes it seems so - I did think it was failing with occasional system updates too (dnf) but only in Discover - However I have been unable to replicate that. So at this stage looks like it’s specifically a flathub/flatpak thing (and both Discover and sudo flatpak update exhibit similar errors when it happens - which is intemittent).

This is over a VPN usually when it happens (I’m in NZ and normally have VPN connected to NZ) - the work around is to not use the VPN; or in some cases, change the VPN to another country (e.g. from NZ I connect to US or UK or DE), and it resolves. However the VPN itself doesn’t seem to be the issue (as MTU looks okay, and issue is intermittent - not constant), so it seems to be connectivity at the repo host end…?

[tiryns (Mycenius)]

Just as an aside, I was looking through the journal for a different reason (squeezelite issue) and noticed these while at it - could any of them have any relevance to the flatpak update issue above? These are just examples (not the full list):

Oct 12 07:14:16 PC NetworkManager[830]: <warn>  [1791742456.1137] dns-sd-resolved[e4f41548269d223e]: send-updates SetLinkDNS@3 failed: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Invalid DNS server address
Oct 12 07:14:16 PC NetworkManager[830]: <info>  [1791742456.1142] device (pvpnksintrf0): state change: ip-config -> ip-check (reason 'none', managed-type: 'full')

Oct 12 09:02:11 PC plasma-discover[9140]: QIODevice::read (QSslSocket): device not open
Oct 12 09:02:15 PC plasma-discover[9140]: libostree HTTP error from remote flathub for <https://dl.flathub.org/repo/objects/9d/08904e3c0c845b162fd69b4bd99ce9d38f57f0a9c63bc88265a9b3d8dcc0aa.filez>: Failure when receiving data from the peer
Oct 12 09:02:15 PC plasma-discover[9140]: libostree HTTP error from remote flathub for <https://dl.flathub.org/repo/objects/ba/36787ca5e00091ab98f2e45d04ee6ba9d0a89d6e0b7908a4f7cb41e1b36375.dirtree>: Failed sending data to the peer
Oct 12 09:02:15 PC plasma-discover[9140]: libostree HTTP error from remote flathub for <https://dl.flathub.org/repo/objects/45/0697bc5deca882f198df3c41ed70c2bf164e3f941c7cd433705b0d06404020.dirtree>: Failed sending data to the peer
Oct 12 09:02:17 PC plasma-discover[9140]: libostree HTTP error from remote flathub for <https://dl.flathub.org/repo/objects/9d/08904e3c0c845b162fd69b4bd99ce9d38f57f0a9c63bc88265a9b3d8dcc0aa.filez>: SSL connect error
Oct 12 09:02:28 PC plasma-discover[9140]: libostree HTTP error from remote flathub for <https://dl.flathub.org/repo/objects/9d/08904e3c0c845b162fd69b4bd99ce9d38f57f0a9c63bc88265a9b3d8dcc0aa.filez>: Failure when receiving data from the peer
 
Oct 12 09:04:14 PC plasma-discover[9140]: libostree HTTP error from remote flathub for <https://dl.flathub.org/repo/objects/9d/08904e3c0c845b162fd69b4bd99ce9d38f57f0a9c63bc88265a9b3d8dcc0aa.filez>: Failure when receiving data from the peer
Oct 12 09:04:16 PC plasma-discover[9140]: libostree HTTP error from remote flathub for <https://dl.flathub.org/repo/objects/9d/08904e3c0c845b162fd69b4bd99ce9d38f57f0a9c63bc88265a9b3d8dcc0aa.filez>: SSL connect error
Oct 12 09:04:23 PC plasma-discover[9140]: libostree HTTP error from remote flathub for <https://dl.flathub.org/repo/objects/9d/08904e3c0c845b162fd69b4bd99ce9d38f57f0a9c63bc88265a9b3d8dcc0aa.filez>: Failure when receiving data from the peer
Oct 12 09:04:25 PC plasma-discover[9140]: libostree HTTP error from remote flathub for <https://dl.flathub.org/repo/objects/9d/08904e3c0c845b162fd69b4bd99ce9d38f57f0a9c63bc88265a9b3d8dcc0aa.filez>: SSL connect error
Oct 12 09:04:26 PC plasma-discover[9140]: libostree HTTP error from remote flathub for <https://dl.flathub.org/repo/objects/9d/08904e3c0c845b162fd69b4bd99ce9d38f57f0a9c63bc88265a9b3d8dcc0aa.filez>: SSL connect error
Oct 12 09:04:28 PC plasma-discover[9140]: libostree HTTP error from remote flathub for <https://dl.flathub.org/repo/objects/9d/08904e3c0c845b162fd69b4bd99ce9d38f57f0a9c63bc88265a9b3d8dcc0aa.filez>: SSL connect error

Oct 12 09:04:28 PC plasma-discover[9140]: Failed to refresh appstream metadata for flathub: "While pulling appstream2/x86_64 from remote flathub: While fetching https://dl.flathub.org/repo/objects/9d/08904e3c0c845b162fd69b4bd99ce9d38f57f0a9c63bc88265a9b3d8dcc0aa.filez: [35] SSL connect error"

Oct 12 09:02:59 PC plasma-discover[9140]: Warning: Treating remote fetch error as non-fatal since runtime/org.winehq.Wine.mono/x86_64/stable-25.08 is already installed: No such ref 'runtime/org.winehq.Wine.mono/x86_64/stable-25.08' in remote flathub
Oct 12 09:02:59 PC plasma-discover[9140]: Warning: Treating remote fetch error as non-fatal since runtime/org.winehq.Wine.mono/x86_64/stable-21.08 is already installed: No such ref 'runtime/org.winehq.Wine.mono/x86_64/stable-21.08' in remote flathub
Oct 12 09:02:59 PC plasma-discover[9140]: Warning: Treating remote fetch error as non-fatal since runtime/org.winehq.Wine.gecko/x86_64/stable-25.08 is already installed: No such ref 'runtime/org.winehq.Wine.gecko/x86_64/stable-25.08' in remote flathub
Oct 12 09:02:59 PC plasma-discover[9140]: Warning: Treating remote fetch error as non-fatal since runtime/org.winehq.Wine.gecko/x86_64/stable-21.08 is already installed: No such ref 'runtime/org.winehq.Wine.gecko/x86_64/stable-21.08' in remote flathub
Oct 12 09:02:59 PC plasma-discover[9140]: Warning: Treating remote fetch error as non-fatal since runtime/org.winehq.Wine.DLLs.dxvk/x86_64/stable-21.08 is already installed: No such ref 'runtime/org.winehq.Wine.DLLs.dxvk/x86_64/stable-21.08' in remote flathub

EDIT: Just some further information that reinforces the issue seems to be at the host end (and not caused by the VPN or similar), just had 2 flathub apps that needed updates in Discover - one updated fine, the second had the technical error below, if it was a VPN comms issue one would assume both should have failed?

Note also in this case the app subsequently updated fine with flatpak update despite failing 3 times in Discover with below error - all of this across VPN. This was the original issue I was experiencing but more extensive testing showed it also often failed via flatpak update too… just not always, and not in this instance.

While pulling app/org.standardnotes.standardnotes/x86_64/stable from remote flathub: While fetching https://dl.flathub.org/repo/objects/cc/d1c07c38e734325498f9fec18d2fe41e92fd35e162a4505387c03e379949c1.filez: [56] Failure when receiving data from the peer

sudo flatpak update
Looking for updates…

        ID                                        Branch           Op           Remote            Download
 1. [✓] org.standardnotes.standardnotes           stable           u            flathub           57.3 MB / 161.4 MB

Updating… ████████████████████ 100%  28.6 MB/s
Note that '/var/lib/flatpak/exports/share' is not in the search path
set by the XDG_DATA_HOME and XDG_DATA_DIRS
environment variables, so applications may not
be able to find it until you set them. The
directories currently searched are:

- /root/.local/share
        ID                                        Branch           Op           Remote            Download
 1. [✓] org.standardnotes.standardnotes           stable           u            flathub           57.3 MB / 161.4 MB

Updates complete.
Updating appstream data for remote flathub

However i haven’t seen this message before but see its related to using sudo for flatpak updates (so unrelated):

Note that ‘/var/lib/flatpak/exports/share’ is not in the search path set by the XDG_DATA_HOME and XDG_DATA_DIRS environment variables, so applications may not be able to find it until you set them.

[tiryns (Mycenius)]

As an aside in addition to the posts linked to above I found older thread with same issue dating from 2024:

Flatpak Flathub VPN

Is it normal I need to turn off my VPN to download apps from either of those? This is an example of the error I get. If I turn VPN off it downloads fine. Downloading from Fedora repo works fine. While pulling runtime/org.freedesktop.Platform.Compat.i386/x86_64/25.08 from remote flathub: While fetching https://dl.flathub.org/repo/deltas/go/bcUgvppkZWcMZK6TmWXW1E55kYcez+B3vOA0MrUwY/3: [56] Failure when receiving data from the peer

So maybe it might be a ProtonVPN issue somehow? I’m still sceptical but will try and log a support issue with Proton for it and see what happens.

EDIT: Had a response from ProtonVPN Support and as I kind of expected they refuse to look into it because even though I had been using ProtonVPN for Fedora GNOME Proton doesn’t support their VPN on Fedora KDE Plasma (nor any flatpak version - which I had also tried):

Flatpak packaging of our applications is not supported… Therefore, it is recommended that you instead acquire the application through official channels, or establish a manual connection to Proton VPN… Furthermore, we only officially support Linux on Debian, Ubuntu, and Fedora (on GNOME). We haven’t officially tested the Linux application on the specific Linux distro that you are using, therefore, it is not officially supported, and I will be unable to guarantee that it will work as intended nor provide extensive troubleshooting steps.

However the balance of the response has made me think of one last thing to try - the CLI version of ProtonVPN and/or a manual connection - to verify if the same issue happens there as well…

(The main problem with these is likely that, like the unofficial flatpak version, they will lack stealth and split-tunnelling options - so may not be an ideal solution going forward…)