Update timed out because libpamac-flatpak-plugin requires internet access

heyjo · 21 June 2025 10:28

When updating the plasma 6.4 packages along with the package libpamac-flatpak-plugin in TTY3, the update timed out for 9 minutes because libpamac-flatpak-plugin requires instant internet access ( which the system does not have in TTY, because of downloading packages with sudo pacman -Syuw prior TTY log in).

2025-06-21T06:53:47+0200] [ALPM] upgraded libpamac (11.7.3-4 -> 11.7.3-5)
[2025-06-21T06:53:47+0200] [ALPM] upgraded libpamac-flatpak-plugin (11.7.3-4 -> 11.7.3-5)
[2025-06-21T07:04:54+0200] [ALPM-SCRIPTLET] Fehler: Can't load uri https://flathub.org/repo/flathub.flatpakrepo: While fetching https://flathub.org/repo/flathub.flatpakrepo: [28] Timeout was reached
[2025-06-21T07:04:54+0200] [ALPM-SCRIPTLET]
[2025-06-21T07:04:55+0200] [ALPM] upgraded linux612 (6.12.33-1 -> 6.12.34-1)
[2025-06-21T07:04:57+0200] [ALPM] upgraded linux612-headers (6.12.33-1 -> 6.12.34-1)

Moderator edit: In the future, please use proper formatting: [HowTo] Post command output and file content as formatted text

linux-aarhus · 21 June 2025 10:40

All package downloads require internet access - this is not limited to the flatpak plugin.

And if you are simply switching from the display manager or from your desktop your system should have a working internet connection.

The message is more likely a coincidence - the flathub repo service timed out.

heyjo · 21 June 2025 11:05

Did you read my sentence “which the system does not have in TTY, because of downloading packages with sudo pacman -Syuw prior TTY log in”?

That means sudo pacman -Syuw in graphical environment and sudo pacman -Su in TTY3, so all packages were downloaded before switching to TTY3.

linux-aarhus · 21 June 2025 11:08

Yes - I did - perhaps I misunderstood something? Did you disconnect your system from network after syncing the packages to your system? Prior to switching to TTY?

Unless you have a very unusual setup - a Manjaro system has active network - even in TTY.

An unusual setup may include

not using NetworkManager
deliberately disconnecting from network to run updates
having a WiFi connection which is not shared with all users on the system
using a WiFi adapter which requires custom module to function

There may be other factors I have not thought of - but usually - a network connection will be active - even in TTY.

You may want to check in TTY

ip a

EDIT
I tried to replicate what you describe

 $ sudo pacman -Syuw pamac-flatpak-plugin
[sudo] password for fh: 
:: Synchronizing package databases...
 core is up to date
 extra                                                                          8,5 MiB  20,4 MiB/s 00:00 [---------------------------------------------------------------] 100%
 multilib is up to date
 sublime-text is up to date
 nix-repo is up to date
:: Starting full system upgrade...
resolving dependencies...

Package (2)                    Old Version    New Version    Net Change  Download Size

extra/vivaldi                  7.4.3684.52-1  7.4.3684.55-1    0,00 MiB     165,20 MiB
extra/libpamac-flatpak-plugin                 11.7.3-5         0,07 MiB       0,03 MiB

Total Download Size:  165,23 MiB

:: Proceed with download? [Y/n] 
:: Retrieving packages...
 libpamac-flatpak-plugin-11.7.3-5-x86_64   30,1 KiB   255 KiB/s 00:00 [-------] 100%
 vivaldi-7.4.3684.55-1-x86_64             165,2 MiB  40,1 MiB/s 00:04 [-------] 100%
 Total (2/2)                              165,2 MiB  39,8 MiB/s 00:04 [-------] 100%
(2/2) checking keys in keyring                                        [-------] 100%
(2/2) checking package integrity                                      [-------] 100%

Disable my network connection

13:16:09 ○ [fh@tiger] ~
 $ sudo pacman -Syu
:: Synchronizing package databases...
 core.db failed to download
 extra.db failed to download
 multilib.db failed to download
 sublime-text.db failed to download
error: failed retrieving file 'multilib.db' from uex.dk/repos/manjaro : Could not resolve host: uex.dk
warning: fatal error from uex.dk, skipping for the remainder of this transaction
error: failed retrieving file 'core.db' from uex.dk/repos/manjaro : Could not resolve host: uex.dk
error: failed retrieving file 'extra.db' from uex.dk/repos/manjaro : Could not resolve host: uex.dk
error: failed to synchronize all databases (failed to retrieve some files)

Run a an update only when offline

13:16:29 ○ [fh@tiger] ~
 $ sudo pacman -Su
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...

Package (1)    Old Version    New Version    Net Change

extra/vivaldi  7.4.3684.52-1  7.4.3684.55-1    0,00 MiB

Total Installed Size:  409,54 MiB
Net Upgrade Size:        0,00 MiB

:: Proceed with installation? [Y/n] 
(1/1) checking keys in keyring                          [----------------] 100%
(1/1) checking package integrity                        [----------------] 100%
(1/1) loading package files                             [----------------] 100%
(1/1) checking for file conflicts                       [----------------] 100%
(1/1) checking available disk space                     [----------------] 100%
:: Processing package changes...
(1/1) upgrading vivaldi                                 [----------------] 100%
:: Running post-transaction hooks...
(1/4) Arming ConditionNeedsUpdate...
(2/4) Refreshing PackageKit...
(3/4) Updating icon theme caches...
(4/4) Updating the desktop file MIME type cache...

Installing the flatpak plugin

 $ sudo pacman -S pamac-flatpak-plugin
[sudo] password for fh: 
resolving dependencies...
looking for conflicting packages...

Package (1)                    New Version  Net Change

extra/libpamac-flatpak-plugin  11.7.3-5       0,07 MiB

Total Installed Size:  0,07 MiB

:: Proceed with installation? [Y/n] 
(1/1) checking keys in keyring                         [--------------] 100%
(1/1) checking package integrity                       [--------------] 100%
(1/1) loading package files                            [--------------] 100%
(1/1) checking for file conflicts                      [--------------] 100%
(1/1) checking available disk space                    [--------------] 100%
:: Processing package changes...
(1/1) installing libpamac-flatpak-plugin               [--------------] 100%
error: Can't load uri https://flathub.org/repo/flathub.flatpakrepo: While fetching https://flathub.org/repo/flathub.flatpakrepo: [6] Could not resolve hostname

error: command failed to execute correctly
:: Running post-transaction hooks...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Refreshing PackageKit...

Please note the different message - when I deliberately disconnected from network.

error: Can't load uri https://flathub.org/repo/flathub.flatpakrepo: While fetching https://flathub.org/repo/flathub.flatpakrepo: [6] Could not resolve hostname

Compared the message you got

The mesages are two different messages - indicating that your issues was an intermittent network issue.

In any case the issue is not critical and it will resolve itself.

heyjo · 21 June 2025 12:06

For Network set up I have NetworkManager and wpa_supplicant installed and for DNS resolving systemd-resolved and nss-mds, so current standard I guess.

ip a shows the same in tty3 and graphics manager (IP addresses assigned for ethernet and wifi etc in both). However network does not work in tty3 (and never worked).

When I run sudo pacman -Syu in tty3 it responds with "can’t resolve …(for all server addresses).

Aragorn · 21 June 2025 17:10

My experience has shown that systemd-resolved is unreliable when running in combination with NetworkManager. The latter is perfectly capable of name resolution all by itself, but running both together will cause name resolution to fail after a certain timeout.

Also, glibc cannot handle more than three name servers, and if you’re going to be running multiple name resolvers, then you’ll be getting many more in your /etc/resolv.conf.

Nachlese · 21 June 2025 17:54

In my absolutely unaltered standard installation
(in a VM - stable branch, three Manjaro VM’s, one of each major flavor)
internet is up and available no matter whether I’m logged in to the graphical session or not.
It’s there after boot and TTY login.

That is how I often update my VM’s - I don’t bother starting the GUI, go to TTY and run the update …

linux-aarhus · 22 June 2025 05:43

I use the same combination - never any issues.

That is expected - it should show the addresses assigned - and your comment verifies that network is indeed active

This point to an issue local to your network.

It is impossible to deduce what this is without more information…

Since you state that network is working using a virtual terminal - but not TTY - please run this command from a TTY

nmcli > ~/nmcli-tty.txt

Then in a virtual terminal

nmcli > ~/nmcli-vt.txt

Copy the content of the text file and paste into a new comment - stating which is which

Hmm - that is contradicting upstream Arch Linux wiki and my personal experience

Automatically

systemd-resolved will work out of the box with a network manager using /etc/resolv.conf. No particular configuration is required since systemd-resolved will be detected by following the /etc/resolv.conf symlink. This is going to be the case with systemd-networkd, NetworkManager, and iwd.
– systemd-resolved - ArchWiki

NetworkManager cannot resolve names on it’s own.

I just tested on my system
disable systemd-resolved

07:51:44 ○ [fh@tiger] ~
 $ sudo systemctl disable --now systemd-resolved
Removed '/etc/systemd/system/dbus-org.freedesktop.resolve1.service'.
Removed '/etc/systemd/system/sysinit.target.wants/systemd-resolved.service'.

do a lookup

07:52:17 ○ [fh@tiger] ~
 $ drill dr.dk
Error: error sending query: Could not send or receive, because of network error

reenable systemd-resolved

07:52:51 ○ [fh@tiger] ~
 $ sudo systemctl enable --now systemd-resolved
Created symlink '/etc/systemd/system/dbus-org.freedesktop.resolve1.service' → '/usr/lib/systemd/system/systemd-resolved.service'.
Created symlink '/etc/systemd/system/sysinit.target.wants/systemd-resolved.service' → '/usr/lib/systemd/system/systemd-resolved.service'.

same lookup one more time

07:53:28 ○ [fh@tiger] ~
 $ drill dr.dk
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 38050
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; dr.dk.       IN      A

;; ANSWER SECTION:
dr.dk.  60      IN      A       2.23.172.114
dr.dk.  60      IN      A       2.23.172.130

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 57 msec
;; SERVER: 127.0.0.53
;; WHEN: Sun Jun 22 07:55:52 2025
;; MSG SIZE  rcvd: 55

[Offtopic] I know of only one place where a conflict could occur - that is with Avahi daemon - as noted on the same page in section 2.2.

Aragorn · 22 June 2025 05:57

Well, my experience is off-topic here, but I do not have avahi-daemon.{socket,service} running. In fact, it’s masked over here.

Yes it can, and it does. It will automatically invoke one of several installed DNS subsystems, be it systemd-resolved, dnsmasq, or something else. But the activation of systemd-resolved by itself via systemctl was what was causing name resolution problems over here.

heyjo · 22 June 2025 13:13

So, here is what my system does and how it is set up:

nmcli in TTY vs DE (plasma 6.4): no difference and all good

nmcli > ~/nmcli-tty.txt

wlp3s0: verbunden to WLAN1
“Intel 8265 / 8275”
wifi (iwlwifi), 30:24:32:44:F9:03, hw, mtu 1500
ip4-Vorgabe
inet4 192.168.150.44/24
route4 192.168.150.0/24 metric 600
route4 default via 192.168.150.1 metric 600

lo: verbunden (extern) to lo
“lo”
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
inet4 127.0.0.1/8
inet6 ::1/128

enp0s31f6: nicht verfügbar
“Intel I219-LM”
ethernet (e1000e), 8C:16:45:93:70:C5, hw, mtu 1500

vmnet1: nicht verwaltet
“vmnet1”
ethernet (unknown), 00:50:56:C0:00:01, hw, mtu 1500

vmnet8: nicht verwaltet
“vmnet8”
ethernet (unknown), 00:50:56:C0:00:08, hw, mtu 1500

DNS configuration:
servers: 192.168.150.1
domains: fritz.box
interface: wlp3s0

nmcli > ~/nmcli-vt.txt

wlp3s0: verbunden to WLAN1
“Intel 8265 / 8275”
wifi (iwlwifi), 30:24:32:44:F9:03, hw, mtu 1500
ip4-Vorgabe
inet4 192.168.150.44/24
route4 192.168.150.0/24 metric 600
route4 default via 192.168.150.1 metric 600

lo: verbunden (extern) to lo
“lo”
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
inet4 127.0.0.1/8
inet6 ::1/128

enp0s31f6: nicht verfügbar
“Intel I219-LM”
ethernet (e1000e), 8C:16:45:93:70:C5, hw, mtu 1500

vmnet1: nicht verwaltet
“vmnet1”
ethernet (unknown), 00:50:56:C0:00:01, hw, mtu 1500

vmnet8: nicht verwaltet
“vmnet8”
ethernet (unknown), 00:50:56:C0:00:08, hw, mtu 1500

DNS configuration:
servers: 192.168.150.1
domains: fritz.box
interface: wlp3s0

tracepath fritz.box in TTY vs DE (plasma 6.4): no difference and all good

tracepath fritz.box > ~/tracepath-tty-2.txt

1?: [LOCALHOST] pmtu 1500
1: fritz.box 1.914ms erreicht
1: fritz.box 1.917ms erreicht
Fazit: pmtu 1500 Hops 1 zurück 1

tracepath fritz.box > ~/tracepath-gui.txt

1?: [LOCALHOST] pmtu 1500
1: fritz.box 5.007ms erreicht
1: fritz-nas.box 5.871ms erreicht
Fazit: pmtu 1500 Hops 1 zurück 1

resolvectl in TTY vs DE (plasma 6.4): no difference and all good

resolvectl > ~/resolvectl-tty.txt

Global
Protocols: -LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (enp0s31f6)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Default Route: no

Link 3 (wlp3s0)
Current Scopes: DNS mDNS/IPv4
Protocols: +DefaultRoute -LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.150.1
DNS Servers: 192.168.150.1
DNS Domain: fritz.box
Default Route: yes

Link 4 (vmnet1)
Current Scopes: mDNS/IPv4 mDNS/IPv6
Protocols: -DefaultRoute -LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Default Route: no

Link 5 (vmnet8)
Current Scopes: mDNS/IPv4 mDNS/IPv6
Protocols: -DefaultRoute -LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Default Route: no

resolvectl > ~/resolvectl-gui.txt

Global
Protocols: -LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (enp0s31f6)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Default Route: no

Link 3 (wlp3s0)
Current Scopes: DNS mDNS/IPv4
Protocols: +DefaultRoute -LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.150.1
DNS Servers: 192.168.150.1
DNS Domain: fritz.box
Default Route: yes

Link 4 (vmnet1)
Current Scopes: mDNS/IPv4 mDNS/IPv6
Protocols: -DefaultRoute -LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Default Route: no

Link 5 (vmnet8)
Current Scopes: mDNS/IPv4 mDNS/IPv6
Protocols: -DefaultRoute -LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Default Route: no

In TTY:

Both, ping -c 5 fritz.box and ping -c 5 192.168.150.1 (ip address of fritz.box) work.
ping -c 5 ulm.de does not respond. ping -c5 20.103.215.75 (ip address of ulm.de) works - ulm.de is an example for whatever url).
pinging of any ip address works
No DNS resolving works other than fritz.box

host dns.fritz.box (dns over TLS servers in fritz.box)

dns.fritz.box has address 5.9.164.112
dns.fritz.box has address 185.95.218.42
dns.fritz.box has address 194.242.2.2
dns.fritz.box has address 78.46.244.143
dns.fritz.box has address 185.95.218.43
dns.fritz.box has address 89.233.43.71

In Plasma 6.4:
All network and dns resolving works

System set up:

cat /etc/hosts

Standard host addresses

127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

This host address

127.0.1.1 20l6s29eeee

cat /etc/nsswitch.conf

Name Service Switch configuration file.

See nsswitch.conf(5) for details.

passwd: files systemd
group: files [SUCCESS=merge] systemd
shadow: files systemd
gshadow: files systemd

publickey: files

hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns
networks: files

protocols: files
services: files
ethers: files
rpc: files

netgroup: files

cat /etc/resolv.conf (systemd-resolved, stub)

This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).

Do not edit.

This file might be symlinked as /etc/resolv.conf. If you’re looking at

/etc/resolv.conf and seeing this text, you have followed the symlink.

This is a dynamic resolv.conf file for connecting local clients to the

internal DNS stub resolver of systemd-resolved. This file lists all

configured search domains.

Run “resolvectl status” to see details about the uplink DNS servers

currently in use.

Third party programs should typically not access this file directly, but only

through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a

different way, replace this symlink by a static file or a different symlink.

See man:systemd-resolved.service(8) for details about the supported modes of

operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search fritz.box

systemctl status avahi-daemon (masked)

systemctl status avahi-daemon
○ avahi-daemon.service
Loaded: masked (Reason: Unit avahi-daemon.service is masked.)
Active: inactive (dead)

systemctl status systemd-networkd (disabled)

systemctl status systemd-networkd
○ systemd-networkd.service - Network Configuration
Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; disabled; preset: enabled)
Active: inactive (dead)
TriggeredBy: ○ systemd-networkd.socket
Docs: man:systemd-networkd.service(8)
man:org.freedesktop.network1(5)
FD Store: 0 (limit: 512)

DNS servers (DOT) are set up in router (Fritz box) - see above host dns.fritz.box

heyjo · 23 June 2025 17:19

Thanks to @linux-aarhus , @Nachlese , @Aragorn , I got motivated to solve this issue

Set log level of systemd-resolved to debug : sudo resolvectl log-level debug
Analyze system-resolved messages: journalctl --no-pager --boot=0 | grep systemd-resolved

There were error messages in tty but no in plasma 6.

tty error message -> can not (properly or unreliably) resolve fritz.box or any other URL

Jun 23 18:20:34 20l6s29eeee systemd-resolved[385]: Looking up RR for fritz.box IN A.
Jun 23 18:20:34 20l6s29eeee systemd-resolved[385]: Looking up RR for fritz.box IN AAAA.
Jun 23 18:20:34 20l6s29eeee systemd-resolved[385]: varlink-24-24: Sending message: {“parameters”:{“state”:“no-servers”,“question”:[{“class”:1,“type”:1,“name”
:“fritz.box”},{“class”:1,“type”:28,“name”:“fritz.box”}]},“continues”:true}
Jun 23 18:20:34 20l6s29eeee systemd-resolved[385]: varlink-25-25: Sending message: {“error”:“io.systemd.Resolve.NoNameServers”,“parameters”:{}}

Solution:

Internet access is network + dns resolving + firewall (if installed, and I have one installed)

My firewall opensnitch was set up to no outbound connections when the opensnitch daemon is not connected to the user interface (which it always is when logged into plasma but it isn’t when looged into tty).
Changing this under settings/knot/general/default action when gui is not connected to allow does no longer block dns resolving in tty.

Apparently opensnitch does not block ip connections, only URL’s.

linux-aarhus · 24 June 2025 04:58

So it is not Manjaro Linux which was at fault - but an improperly configured application.

Thank you for sharing your troubleshooting experience with us…

firewall vs. opensnitch

A firewall block incoming connection - it can also be used to block outgoing usually by service.

The opensnitch an application firewall which block outgoing connection based on origin (usually per application).

The opensnitch application can be very difficult to configure properly and one should always disable opensnitch when troubleshooting an unexplainable network issue.

system · 27 June 2025 04:58

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.