pacman cannot resolve host if DownloadUser is set to default 'alpm'

FelixZY · 2025-03-20 20:57:06

I'm working on my own installer for arch and have run into a bit of an issue. Pacman refuses to install packages on the system unless the DownloadUser option is commented out in /etc/pacman.conf .

Steps to reproduce

Use archlinux-2025.03.01-x86_64.iso
Setup partitions etc.
Run pacstrap -K /mnt base linux linux-firmware
Run arch-chroot /mnt
Run pacman -Syu --debug

Expected
No problems

Actual
Pacman fails, claiming it cannot resolve the mirror hosts

Fix
Comment out DownloadUser = alpm in /etc/pacman.conf and try again.

Question
This does not seem like the correct solution. I'd like to understand why pacman fails and how to fix it properly.

"Successful" logs
https://gist.github.com/FelixZY/d6ef429 … 2b321b3200

Failure logs
https://gist.github.com/FelixZY/713dbe6 … 28b8cbff72

seth · 2025-03-20 22:02:58

debug: core.db: curl returned result 6 from transfer
error: failed retrieving file 'core.db' from de.arch.niranjan.co : Could not resolve host: de.arch.niranjan.co
warning: fatal error from de.arch.niranjan.co, skipping for the remainder of this transaction

The DNS resolution fails, VPN, firewall, etc?

Edit:
What does your resolver config look like?
"resolvectl status", /etc/resolv.conf, /etc/systemd/resolved.conf ?

Possibly related, the restricted FS access …

debug: option 'sandboxuser' = alpm
:: Synchronizing package databases...
 core downloading...
 extra downloading...
debug: filesystem access has been restricted to /var/lib/pacman/sync/download-RVG0Qs/, landlock ABI is 6

Last edited by seth (2025-03-20 22:09:00)

FelixZY · 2025-03-20 22:59:27

Yes, I can see that the DNS resolution fails but I don't understand why. As you can see, everything works fine if the DownloadUser is commented out (i.e. set to root if I understand correctly). I can also run e.g. ping against these hosts just fine, so I doubt it's a network issue.

The resolver config is unmodified from the installation medium. I can get back to you with it but I doubt that's the problem.

I would guess that there's a file with invalid permissions somewhere but I'm not aware of any file that would cause this kind of issue (though it no doubt exists).

Last edited by FelixZY (2025-03-20 23:00:35)

seth · 2025-03-20 23:02:32

I can also run e.g. ping against these hosts just fine

But not as alpm user/out of that sandbox…?!

See the edit: how're network/resolver configure tbw?

FelixZY · 2025-03-21 11:42:04

resolvectl status

(as root)

$ resolvectl status
Global
           Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: stub
Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net
                      8.8.8.8#dns.google 2606:4700:4700::1111#cloudflare-dns.com
                      2620:fe::9#dns.quad9.net 2001:4860:4860::8888#dns.google

Link 2 (enp1s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6
         Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.122.1
       DNS Servers: 192.168.122.1
     Default Route: yes

(as alpm)

$ sudo -H -u alpm resolvectl status
Global
           Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: stub
Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net
                      8.8.8.8#dns.google 2606:4700:4700::1111#cloudflare-dns.com
                      2620:fe::9#dns.quad9.net 2001:4860:4860::8888#dns.google

Link 2 (enp1s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6
         Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.122.1
       DNS Servers: 192.168.122.1
     Default Route: yes

/etc/resolv.conf

All comments

/etc/systemd/resolved.conf

All comments except

[Resolve]

ping

(as root)

$ ping -c 4 google.com
PING google.com (142.250.74.46) 56(84) bytes of data.
64 bytes from arn09s22-in-f14.1e100.net (142.250.74.46): icmp_seq=1 ttl=52 time=4.18 ms
64 bytes from arn09s22-in-f14.1e100.net (142.250.74.46): icmp_seq=2 ttl=52 time=4.36 ms
64 bytes from arn09s22-in-f14.1e100.net (142.250.74.46): icmp_seq=3 ttl=52 time=3.95 ms
64 bytes from arn09s22-in-f14.1e100.net (142.250.74.46): icmp_seq=4 ttl=52 time=4.11 ms

--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 3.952/4.152/4.364/0.148 ms

(as alpm)

$ sudo -H -u alpm ping -c 4 google.com
ping: google.com: Temporary failure in name resolution

FelixZY · 2025-03-21 11:59:31

Additional research:

Both Server Fault and Red Hat suggest permissions on /etc/resolv.conf can be a problem (should be 644 instead of 600). In my case:

$ ls -al /etc/resolv.conf
-rw-r--r-- 1 systemd-resolve systemd-resolve 920 Mar21 10:46 /etc/resolv.conf

$ ls -al /etc/systemd/resolved.conf
-rw-r--r-- 1 root root 1709 Mar  6 14:46 /etc/systemd/ersolved.conf

I can also ping IP addresses directly as the alpm user, just not resolve DNS names...

FelixZY · 2025-03-21 12:04:41

Going by https://docs.redhat.com/en/documentatio … le-gen-dns I got this which might be interesting:

$ dig _ldap._tcp.ipa.example.com. SRV

; <<>> DiG 9.20.7 <<>> _ldap._tcp.ipa.example.com. SRV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 13124
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;_ldap._tcp.ipa.example.com.	IN	SRV

;; Query time: 165 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Mar 21 12:03:58 UTC 2025
;; MSG SIZE  rcvd: 55


$ sudo -H -u alpm dig _ldap._tcp.ipa.example.com. SRV
dig: parse of /etc/resolv.conf failed

FelixZY · 2025-03-21 12:19:25

Found it!

I tried to run

$ sudo -H -u alpm ls /etc/resolv.conf

and was met with a permission denied. Comparing the listing of

$ ls -al /

from my arch machine with an ubuntu machine, I found that the /etc directory had invalid permissions.

Expected: 755
Actual: 700

Running

$ chmod 755 /etc

as root resolved the issue.

Edit

Looks like /var/cache/pacman has invalid permissions as well. I had to do the following to fix that:

$ chown -R alpm:alpm /var/cache/pacman

Last edited by FelixZY (2025-03-21 12:56:45)

FelixZY · 2025-03-21 12:42:26

In an attempt to try and find the cause, I did the following. Seems like there's a bug with pacstrap that should be reported somewhere. Any ideas where?

$ ls -al /mnt
total 24
drwxr-xr-x 4 root root  4096 Mar 21 12:37 .
drwxr-xr-x 1 root root   160 Mar 21 12:37 ..
drwx------ 2 root root  4096 Jan  1  1970 efi
drwx------ 2 root root 16384 Mar 21 12:37 lost+found

$ pacstrap -K /mnt base linux linux-firmware
[truncated]

$ ls -al /mnt
total 80
drwxr-xr-x 18 root root  4096 Mar 21 12:37 .
drwxr-xr-x  1 root root   180 Mar 21 12:38 ..
lrwxrwxrwx  1 root root     7 Nov 21 08:56 bin -> usr/bin
drwxr-xr-x  2 root root  4096 Mar 21 12:38 boot
drwxr-xr-x  2 root root  4096 Mar 21 12:37 dev
drwx------  2 root root  4096 Jan  1  1970 efi
drwx------ 41 root root  4096 Mar 21 12:38 etc
drwxr-xr-x  2 root root  4096 Nov 21 08:56 home
lrwxrwxrwx  1 root root     7 Nov 21 08:56 lib -> usr/lib
lrwxrwxrwx  1 root root     7 Nov 21 08:56 lib64 -> usr/lib
drwx------  2 root root 16384 Mar 21 12:37 lost+found
drwxr-xr-x  2 root root  4096 Nov 21 08:56 mnt
drwxr-xr-x  2 root root  4096 Nov 21 08:56 opt
dr-xr-xr-x  2 root root  4096 Mar 21 12:37 proc
drwxr-x---  4 root root  4096 Mar 21 12:38 root
drwxr-xr-x  2 root root  4096 Mar 21 12:37 run
lrwxrwxrwx  1 root root     7 Nov 21 08:56 sbin -> usr/bin
drwxr-xr-x  4 root root  4096 Mar 21 12:37 srv
dr-xr-xr-x  2 root root  4096 Mar 21 12:37 sys
drwxrwxrwt  2 root root  4096 Mar 21 12:37 tmp
drwxr-xr-x  8 root root  4096 Mar 21 12:38 usr
drwxr-xr-x 12 root root  4096 Mar 21 12:37 var

seth · 2025-03-21 15:18:27

https://gitlab.archlinux.org/archlinux/ … heads#L102

[truncated]

That part might be rather interesting, also what does "pacman -Qikk filesystem" say afterwards?

anon1283 · 2025-05-27 16:02:16

I had this problem too (on Parabola linux), thank you for finding the solution

chmod o+rx /etc/
chmod o+rx /var/cache/pacman

alpm only needs to read the pkg folder, root creates and moves files inside.

I would like to open a ticket about that on the bug tracker if it doesn't exist yet but for some reason Arch devs decided to use a service that requires JavaScript.
Arch devs, do you believe the reptilian shapeshifters will treat you better if you kiss their feet or what is wrong with you?

And while looking at folder ownership... correct me if I'm wrong but does pacstrap download files as root? What are you, former Windows XP devs?

seth · 2025-05-27 20:36:32

gitlab actually requires oauth 2fa and because the scratchpad is subject to constant abuse you'll have to appeal for an account…
You might want to read the documentation or strace pacman, but the entire point the sandbox, the permission issues… is that pacman does no longer download stuff as root.

That being said: this is NOT the subject of this thread, the OP has issues w/ dns resolution w/ the alpm user - for remainingly unclear reasons - well, since you have those on parabola and likewise apparently wrong permissions on those directories (your commands are inert on archlinux, those paths are 755 anyway) it would seem that the OP might likewise be a parabola user.

Incidentally *that* is also where you need to direct the bug report.

schard · 2025-05-28 11:58:05

I took the liberty of reproducing the OP's setup in a virtual machine:
https://srv.richard-neumann.de/pub/Bild … -55-53.png

~/Downloads> sha256sum archlinux-2025.03.01-x86_64.iso
8150e3c1a479de9134baa13cea4ff78856cca5ebeb9bdfa87ecfce2e47ac9b5b  archlinux-2025.03.01-x86_64.iso

As you can see, /etc has the correct permissions.
So the issue with faulty permissions is not related to the Arch Linux setup process.

Allan · 2025-05-28 12:17:16

$ pacman -Qlq arch-install-scripts | xargs grep mkdir
...
/usr/bin/pacstrap:  mkdir -m 0755 -p "$newroot"/var/{cache/pacman/pkg,lib/pacman,log} "$newroot"/{dev,run,etc/pacman.d}

anon1283 · 2025-05-28 17:09:24

Thank you, schard and Allan.
In that case I can report the problem further downstream.
I wonder why OP said he was using an arch iso.

There is still the issue of pacstrap downloading files as root, which is how it was able to access /etc/resolv.conf (or whatever it is called on systemd-distros).
Is that also solved in arch and only a problem in arch-based distros?
Considering that it can mean not only the remote hijacking of the installation but also the host or installation medium from which it was run I'm kinda taking this seriously.

Just asking before I go back and forth like in Terry Gilliam's Brazil.

Last edited by anon1283 (2025-05-28 17:16:29)

Scimmia · 2025-05-28 17:31:22

No, it doesn't have to access resolv.conf, it uses the glibc resolver. Beyond that, what, exactly, makes you think it's downloading as root?

Edit: wait, the parabola ISO is ancient, the whole DownloadUser thing is new with pacman 7. This is just your distro being dumb.

Last edited by Scimmia (2025-05-28 17:48:57)

anon1283 · 2025-05-28 18:10:07

Scimmia wrote:

No, it doesn't have to access resolv.conf, it uses the glibc resolver. Beyond that, what, exactly, makes you think it's downloading as root?

I thought so because pacstrap was able to resolve DNS (on my x86-distro and whatever OP is using), but not pacman running as alpm.
Thinking about it, I realize that pacstrap uses the hosts resolv.conf, while pacman in chroot uses the new installation's resolv.conf (or attempts to).
Or glibc, which apparently also uses resolv.conf with the calling program's privileges.

Thank you for helping me realize my mistake and providing at least anecdotal evidence that OP indeed made incorrect claims.
It would be nice if more people treated bug reports like you do instead of throwing around accusations without any evidence.

This is just your distro being dumb.

Well, you try to find something that I can dual-boot on my windows xp gaming machine if I can't be arsed to set up gentoo
I honestly did not expect OP to post misinformation about what kind of distro he was using or I would not have posted here.
And the /etc/ permissions problem is not a problem of pacman being too old, otherwise commenting out that line in the config would not have worked for the OP.

PS: Wait, so you're saying that up to 2024 archlinux downloaded files as root? Ima log out now before I post something that triggers the Anunnaki or whatever.

Last edited by anon1283 (2025-05-28 18:31:44)

seth · 2025-05-29 06:11:19

providing at least anecdotal evidence that OP indeed made incorrect claims.

Just for the record, nothing here evidences false claims by the OP and nobody but you has ever suggested such.

seth wrote:

the OP has issues w/ dns resolution w/ the alpm user - for remainingly unclear reasons - well, since you have those on parabola and likewise apparently wrong permissions on those directories (your commands are inert on archlinux, those paths are 755 anyway) it would seem that the OP might likewise be a parabola user

It's entirely possible that the OP has screwed the permissions in a completely different way, I've just provided and explanation what the remainingly unclear reasons might be based on the analogy to your situation.

You've also made unbased accusations against pacman, the arch developer, the OP and then projected your behavior by reading stuff into my post that is simply not there.
Here's a pro tip to not get into this kind of situation: ask why this is and what can be done about it instead of coming up with some non-factual explanation for your local situation and then yelling that into the internet as loud as possible.
Lies run fast, but reality is a wall.

Arch Linux

#1 2025-03-20 20:57:06

pacman cannot resolve host if DownloadUser is set to default 'alpm'

#2 2025-03-20 22:02:58

Re: pacman cannot resolve host if DownloadUser is set to default 'alpm'

#3 2025-03-20 22:59:27

Re: pacman cannot resolve host if DownloadUser is set to default 'alpm'

#4 2025-03-20 23:02:32

Re: pacman cannot resolve host if DownloadUser is set to default 'alpm'

#5 2025-03-21 11:42:04

Re: pacman cannot resolve host if DownloadUser is set to default 'alpm'

#6 2025-03-21 11:59:31

Re: pacman cannot resolve host if DownloadUser is set to default 'alpm'

#7 2025-03-21 12:04:41

Re: pacman cannot resolve host if DownloadUser is set to default 'alpm'

#8 2025-03-21 12:19:25

Re: pacman cannot resolve host if DownloadUser is set to default 'alpm'

#9 2025-03-21 12:42:26

Re: pacman cannot resolve host if DownloadUser is set to default 'alpm'

#10 2025-03-21 15:18:27

Re: pacman cannot resolve host if DownloadUser is set to default 'alpm'

#11 2025-05-27 16:02:16

Re: pacman cannot resolve host if DownloadUser is set to default 'alpm'

#12 2025-05-27 20:36:32

Re: pacman cannot resolve host if DownloadUser is set to default 'alpm'

#13 2025-05-28 11:58:05

Re: pacman cannot resolve host if DownloadUser is set to default 'alpm'

#14 2025-05-28 12:17:16

Re: pacman cannot resolve host if DownloadUser is set to default 'alpm'

#15 2025-05-28 17:09:24

Re: pacman cannot resolve host if DownloadUser is set to default 'alpm'

#16 2025-05-28 17:31:22

Re: pacman cannot resolve host if DownloadUser is set to default 'alpm'

#17 2025-05-28 18:10:07

Re: pacman cannot resolve host if DownloadUser is set to default 'alpm'

#18 2025-05-29 06:11:19

Re: pacman cannot resolve host if DownloadUser is set to default 'alpm'

Board footer