Do these network transcripts look ok, or problematic?

kdemeoz · May 30, 2026, 10:13pm

since installing kdelinux on HW recently i have been having persistent difficulties installing flatpaks in Discover or konsole [can take up to 30’ for any response to occur], & system updates have proven 100% impossible in Discover [timeout error message; Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.] & ~80% impossible in konsole [also timeout related errors, eg]. otoh my browsers work well, & ookla speedtests therein consistently report nice low ping & my expected ISP-contracted up/download speeds.

konsole pings seem ok afaict? –

me@kdelinux:~] $ ping 9.9.9.9 -c7
PING 9.9.9.9 (9.9.9.9) 56(84) bytes of data.
64 bytes from 9.9.9.9: icmp_seq=1 ttl=54 time=6.07 ms
64 bytes from 9.9.9.9: icmp_seq=2 ttl=54 time=4.67 ms
64 bytes from 9.9.9.9: icmp_seq=3 ttl=54 time=5.17 ms
64 bytes from 9.9.9.9: icmp_seq=4 ttl=54 time=5.04 ms
64 bytes from 9.9.9.9: icmp_seq=5 ttl=54 time=4.84 ms
64 bytes from 9.9.9.9: icmp_seq=6 ttl=54 time=5.16 ms
64 bytes from 9.9.9.9: icmp_seq=7 ttl=54 time=4.98 ms

--- 9.9.9.9 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6007ms
rtt min/avg/max/mdev = 4.665/5.131/6.067/0.415 ms

i really don’t understand these apparent contradictions, & feel unsure what to do. i believe it is not my HW, because when i boot back into my normal archlinux plasma system all pkg installations & updates work fast & well. to begin with, i wonder if these results look correct or problematic, to anyone who understands networking [i do not]:

me@kdelinux:~] $ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Fri 2026-05-29 19:30:00 AEST; 1 day 11h ago
 Invocation: 54f3db1ec14b4f829f9bff947b8f9a26
TriggeredBy: ● systemd-resolved-varlink.socket
             ● systemd-resolved-monitor.socket
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://systemd.io/WRITING_NETWORK_CONFIGURATION_MANAGERS
             https://systemd.io/WRITING_RESOLVER_CLIENTS
   Main PID: 807 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 38028)
     Memory: 17M (peak: 18.3M)
        CPU: 3.049s
     CGroup: /system.slice/systemd-resolved.service
             └─807 /usr/lib/systemd/systemd-resolved

May 31 07:26:41 kdelinux systemd-resolved[807]: Using degraded feature set TCP instead of UDP for DNS server 2606:4700:4700::1002.
May 31 07:26:47 kdelinux systemd-resolved[807]: Using degraded feature set TCP instead of UDP for DNS server 2606:4700:4700::1112.
May 31 07:27:18 kdelinux systemd-resolved[807]: Using degraded feature set TCP instead of UDP for DNS server 2606:4700:4700::1002.
May 31 07:27:22 kdelinux systemd-resolved[807]: Using degraded feature set UDP instead of TCP for DNS server 2606:4700:4700::1112.
May 31 07:27:28 kdelinux systemd-resolved[807]: Using degraded feature set UDP instead of TCP for DNS server 2606:4700:4700::1002.
May 31 07:27:34 kdelinux systemd-resolved[807]: Using degraded feature set UDP instead of TCP for DNS server 2606:4700:4700::1112.
May 31 07:27:54 kdelinux systemd-resolved[807]: Using degraded feature set TCP instead of UDP for DNS server 2606:4700:4700::1112.
May 31 07:28:00 kdelinux systemd-resolved[807]: Using degraded feature set UDP instead of TCP for DNS server 2606:4700:4700::1002.
May 31 07:28:04 kdelinux systemd-resolved[807]: Using degraded feature set TCP instead of UDP for DNS server 2606:4700:4700::1002.
May 31 07:28:10 kdelinux systemd-resolved[807]: Using degraded feature set TCP instead of UDP for DNS server 2606:4700:4700::1112.
[me@kdelinux:~] $ 



[me@kdelinux:~] $ systemctl status systemd-networkd
○ systemd-networkd.service - Network Management
     Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; disabled; preset: disabled)
     Active: inactive (dead)
TriggeredBy: ○ systemd-networkd-varlink-metrics.socket
             ○ systemd-networkd-resolve-hook.socket
             ○ systemd-networkd.socket
             ○ systemd-networkd-varlink.socket
       Docs: man:systemd-networkd.service(8)
             man:org.freedesktop.network1(5)
   FD Store: 0 (limit: 512)
[me@kdelinux:~] [3] $ 



[me@kdelinux:~] [3] $ networkctl
IDX LINK   TYPE     OPERATIONAL SETUP    
  1 lo     loopback -           unmanaged
  2 enp2s0 ether    -           unmanaged

2 links listed.
[me@kdelinux:~] $ 



[me@kdelinux:~] $ systemctl status NetworkManager.service
● NetworkManager.service - Network Manager
     Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; preset: enabled)
     Active: active (running) since Fri 2026-05-29 19:30:03 AEST; 1 day 12h ago
 Invocation: 950d2be78522445c910e7035b11692c9
       Docs: man:NetworkManager(8)
   Main PID: 962 (NetworkManager)
      Tasks: 4 (limit: 38028)
     Memory: 40.5M (peak: 42M)
        CPU: 29.534s
     CGroup: /system.slice/NetworkManager.service
             └─962 /usr/bin/NetworkManager --no-daemon

May 31 07:06:42 kdelinux NetworkManager[962]: <info>  [1780175202.6286] device (enp2s0): state change: ip-check -> secondaries (reason 'none', managed-type: 'full')
May 31 07:06:42 kdelinux NetworkManager[962]: <info>  [1780175202.6288] device (enp2s0): state change: secondaries -> activated (reason 'none', managed-type: 'full')
May 31 07:06:42 kdelinux NetworkManager[962]: <info>  [1780175202.6291] manager: NetworkManager state is now CONNECTED_SITE
May 31 07:06:42 kdelinux NetworkManager[962]: <info>  [1780175202.6293] device (enp2s0): Activation: successful, device activated.
May 31 07:06:47 kdelinux NetworkManager[962]: <info>  [1780175207.9175] manager: NetworkManager state is now CONNECTED_GLOBAL
May 31 07:27:54 kdelinux NetworkManager[962]: <info>  [1780176474.2633] audit: op="statistics" interface="enp2s0" ifindex=2 args="2000" pid=3595 uid=1000 result="success"
May 31 07:27:54 kdelinux NetworkManager[962]: <info>  [1780176474.2703] audit: op="statistics" interface="enp2s0" ifindex=2 args="500" pid=2979 uid=1000 result="success"
May 31 07:28:03 kdelinux NetworkManager[962]: <info>  [1780176483.5678] audit: op="statistics" interface="enp2s0" ifindex=2 args="0" pid=3595 uid=1000 result="success"
May 31 07:28:03 kdelinux NetworkManager[962]: <info>  [1780176483.5771] audit: op="statistics" interface="enp2s0" ifindex=2 args="500" pid=2979 uid=1000 result="success"
May 31 07:28:13 kdelinux NetworkManager[962]: <info>  [1780176493.3552] audit: op="connection-update" uuid="f41b9468-7301-385c-954a-01d5e41e94f4" name="Wired connection 1" args="connection.timestamp,connection.autoconnect-priority,connection.interface-name,ipv6.method,ipv6.addr-gen-mode" pid=166985 uid=1000 result="success"
[me@kdelinux:~] $

btw, none of those Using degraded feature set… messages appear when i boot back to arch.

thanks in confused hope.

kdemeoz · May 30, 2026, 10:26pm

i tried editing my OP to add typical speeds, but the forum refused me permission, so here is that para 1 again, but with inclusion of speeds:

since installing kdelinux on HW recently i have been having persistent difficulties installing flatpaks in Discover or konsole [can take up to 30’ for any response to occur, & then download at excruciatingly slow few hundreds of kbps], & system updates have proven 100% impossible in Discover [timeout error message; Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.] & ~80% impossible in konsole [also timeout related errors, eg]. otoh my browsers work well, & ookla speedtests therein consistently report nice low ping & my expected ISP-contracted up/download speeds [>500/40 mbps].

kdemeoz · May 31, 2026, 3:29am

more info.

my archlinux distrobox that i created a few days ago, reliably does its base system updates, & lets me install new pkgs, within seconds [literally a few seconds]. it’s a total contrast to every interaction i have with both flathub, & with the kdelinux server/s, which commonly manifest those ridiculously slow download speeds of only hundreds of kbps… despite my browser always achieving the >500/40 mbps i mentioned before.

how does this kdelinux installation manage to have both atrocious and also excellent network connectivity?

i hazard to guess the repeat system update timeouts might directly relate to the terrible download speeds from the kdelinux server… ?

does kdelinux use only a single central server, or does it like archlinux have mirrors all over the world? i am in australia - is it possible for me to set a mirror either in or nearer to here than the one which might be configured atm?

pg-tips · May 31, 2026, 8:51am

kdemeoz:

May 31 07:26:41 kdelinux systemd-resolved[807]: Using degraded feature set TCP instead of UDP for DNS server 2606:4700:4700::1002.
May 31 07:26:47 kdelinux systemd-resolved[807]: Using degraded feature set TCP instead of UDP for DNS server 2606:4700:4700::1112.

These made me a bit curious about what would happen if you disabled IPv6 so that everything was forced to use IPv4.

But if you get Arch package updates fine in your distrobox, then I think you’re right that there’s a bottleneck somewhere between your location and the KDELinux and Flathub servers.

kdemeoz · May 31, 2026, 11:01am

yesterday i’d wondered the same thing, so did this [pic], but it seems to have not actually changed the behaviour, per the ongoing transcripts

Summary

i doubt i can make any progress here now, unless someone from the project is able to guide me what needs to be done. it’s sad, because the system is working nicely & is very pleasant to use… but otoh if i can’t actually update it any longer, it becomes unviable.

kdemeoz · May 31, 2026, 12:31pm

nope, another failure… ofc

[me@kdelinux:~] [1] $ run0 /usr/lib/systemd/systemd-sysupdate update
Discovering installed instances…
Discovering available instances…
⤵ Acquiring manifest file https://files.kde.org/kde-linux/sysupdate/v2/SHA256SUMS…
Pulling 'https://files.kde.org/kde-linux/sysupdate/v2/SHA256SUMS'.
Downloading 631B for https://files.kde.org/kde-linux/sysupdate/v2/SHA256SUMS.
Acquired 631B for https://files.kde.org/kde-linux/sysupdate/v2/SHA256SUMS.
Download of https://files.kde.org/kde-linux/sysupdate/v2/SHA256SUMS complete.
Downloading 119B for https://files.kde.org/kde-linux/sysupdate/v2/SHA256SUMS.gpg.
Acquired 119B for https://files.kde.org/kde-linux/sysupdate/v2/SHA256SUMS.gpg.
Download of https://files.kde.org/kde-linux/sysupdate/v2/SHA256SUMS.gpg complete.
gpg: Signature made Sun 31 May 2026 13:04:16 AEST
gpg:                using EDDSA key 15AB3EE61CE450CFED1407BF4121B5F4EAEB53CA
gpg: Good signature from "KDE Linux <linux@kde.org>" [unknown]
gpg: WARNING: Using untrusted key!
Signature verification succeeded.
Operation completed successfully.
Exiting.
⤵ Acquiring manifest file http://localhost:3129/kde-linux/sysupdate/v2/SHA256SUMS…
Pulling 'http://localhost:3129/kde-linux/sysupdate/v2/SHA256SUMS'.
Downloading 631B for http://localhost:3129/kde-linux/sysupdate/v2/SHA256SUMS.
Acquired 631B for http://localhost:3129/kde-linux/sysupdate/v2/SHA256SUMS.
Download of http://localhost:3129/kde-linux/sysupdate/v2/SHA256SUMS complete.
Downloading 119B for http://localhost:3129/kde-linux/sysupdate/v2/SHA256SUMS.gpg.
Acquired 119B for http://localhost:3129/kde-linux/sysupdate/v2/SHA256SUMS.gpg.
Download of http://localhost:3129/kde-linux/sysupdate/v2/SHA256SUMS.gpg complete.
gpg: Signature made Sun 31 May 2026 13:04:16 AEST
gpg:                using EDDSA key 15AB3EE61CE450CFED1407BF4121B5F4EAEB53CA
gpg: Good signature from "KDE Linux <linux@kde.org>" [unknown]
gpg: WARNING: Using untrusted key!
Signature verification succeeded.
Operation completed successfully.
Exiting.
Determining installed update sets…
Determining available update sets…
Selected update '202605310254' for install.
Making room for 1 updates…
♻ Removing old pending '/system/.sysupdate.pending.kde-linux_202605300254.erofs.caibx' (regular-file).
♻ Removing old pending '/system/.sysupdate.pending.kde-linux_202605300254.erofs' (regular-file).
♻ Removing old pending '/system/.sysupdate.pending.kde-linux_202605300254.erofs.caibx' (regular-file).
♻ Removing old pending '/boot/EFI/Linux/.sysupdate.pending.kde-linux_202605300254+2-0.efi' (regular-file).
Removed 2 instances.
⤵ Acquiring https://files.kde.org/kde-linux/sysupdate/v2/kde-linux_202605310254_root-x86-64.caibx → /system/kde-linux_202605310254.erofs.caibx...
Pulling 'https://files.kde.org/kde-linux/sysupdate/v2/kde-linux_202605310254_root-x86-64.caibx', saving as '/system/.sysupdate.partial.kde-linux_202605310254.erofs.caibx'.
Downloading 99K for https://files.kde.org/kde-linux/sysupdate/v2/kde-linux_202605310254_root-x86-64.caibx.
Got 16% of https://files.kde.org/kde-linux/sysupdate/v2/kde-linux_202605310254_root-x86-64.caibx. 15min 25s left at 91B/s.
Acquired 99K for https://files.kde.org/kde-linux/sysupdate/v2/kde-linux_202605310254_root-x86-64.caibx.
Download of https://files.kde.org/kde-linux/sysupdate/v2/kde-linux_202605310254_root-x86-64.caibx complete.
Operation completed successfully.
Exiting.
Successfully acquired 'https://files.kde.org/kde-linux/sysupdate/v2/kde-linux_202605310254_root-x86-64.caibx'.
⤵ Acquiring http://localhost:3129/kde-linux/sysupdate/v2/kde-linux_202605310254_root-x86-64.erofs → /system/kde-linux_202605310254.erofs...
Pulling 'http://localhost:3129/kde-linux/sysupdate/v2/kde-linux_202605310254_root-x86-64.erofs', saving as '/system/.sysupdate.partial.kde-linux_202605310254.erofs'.
Transfer failed: Timeout was reached
Failed to retrieve image file.
Exiting.
(sd-pull-raw) failed with exit status 1: Input/output error
[me@kdelinux:~] [1] $ 


[me@kdelinux:~] [1] $ updatectl vacuum
Deleted 1 instance(s) of host.
[me@kdelinux:~] $

ngraham · June 1, 2026, 5:09am

This is all fairly odd. But if you’re getting good speeds for some things not others, it implies your hardware is fine and the bottleneck is elsewhere.

Still, can you mention what networking hardware you’re using?

If flatpak install [something] from Konsole is slow, this would imply that you’ve hit a bad mirror or something. Or maybe there’s a more general networking problem between your ISP and certain servers outside of Australia?

kdemeoz · June 1, 2026, 9:04am

hi Nate, many thanks for replying.

my arrangement is extremely simple & minimal. i have no home network per se at all, merely one FttP (fibre to the premises) modem-router, connected by wire to my FttP connection to my house. my primary pc, the one in question here for all my kdelinux posts & threads, is ethernet-connected to this modem-router. my ISP contracted plan is 500/40 mbps, which it routinely exceeds eg, 540/47, in my browser per Ookla. this pc has archlinux & kdelinux on it. when booted into Arch, & doing routine system updates sudo pacman -Syu, i always hit my full ISP d/l rate. otoh, since my comparatively recent return to kdelinux on this second SSD [i have been jumping between it, kinoite, & kalpa], as per several of my threads my system update UX has been simply miserable… persistently ghastly-slow d/l speeds <300 kbps, & thus most updates have failed with timeout errors.

however, i have tentative delightful news now to report… success!

i am now in the latest build, 202606010254

Summary of my contemporaneous notes

today i had a new idea; i suspect it might be an IPv6 problem, in that kdelinux seems to want to use that protocol for these updates [ Do these network transcripts look ok, or problematic? ], but afaik my ISP does not support it! so, after research, i cobbled together this string, which first shows the IPv6 status [active], then disables it for this runtime, then does the updates:

ip -6 addr show && sudo sysctl net.ipv6.conf.all.disable_ipv6=1 && sudo sysctl net.ipv6.conf.default.disable_ipv6=1 && flatpak update && updatectl update

initial appearances were poor, in that the flatpak updates remained hideously slow, then finally timed out with one still to do. i manually then did that one ok, then manually ran just the nuclear system update command run0 /usr/lib/systemd/systemd-sysupdate update (ISPv6 still remains disabled, thus forcing the process to use my good IPv4).

this time the difference was substantial - finally, & for the first time, the system update achieved my proper ISP d/l speeds of 500+ mbps! the transcript indicates success, but will it boot ok…?

YES, it boots! i am now in the latest build, 202606010254, yaaaaaaaay!

i have now created this alias:

alias upd="ip -6 addr show && sudo sysctl net.ipv6.conf.all.disable_ipv6=1 && sudo sysctl net.ipv
6.conf.default.disable_ipv6=1 && run0 /usr/lib/systemd/systemd-sysupdate update && flatpak update"

i am very pleased, but not yet willing to state i have found a solid workaround, until & unless the next few updates also prove successful.