You are not logged in.
Hello,
After updating pacman to 7.0.0.r3.g7736133-1 I get an error message when trying to update.
# pacman -Sy
:: Synchronizing package databases...
core 117.7 KiB 1471 KiB/s 00:00 [#######################################################] 100%
extra 7.4 MiB 11.3 MiB/s 00:01 [#######################################################] 100%
error: restricting filesystem access failed because landlock is not supported by the kernel!
After downgrading to previous version pacman-6.1.0-3 this error goes away.
What is landlock and why is it not supported by my kernel?
--
Br / David
Last edited by mr-andersson (2024-09-14 17:46:05)
Offline
What is your kernel? Pacman 7 added a sandbox for the downloaduser, read the current news item, or pass --disable-sandbox or configure the DisableSandbox option if you really need to use a kernel without landlock.
See https://gitlab.archlinux.org/pacman/pac … type=heads as well
Last edited by V1del (2024-09-14 16:59:54)
Offline
Ah, I'm running arch in a container under Proxmox. That's why it was missing landlock in my kernel.
Running pacman with --disable-sandbox mitigated the issue. Thanks!
The work around solution, while not having recompile your kernel with landlock support.
If you want to continue to run pacman without the above switch each time, you can just uncomment line 39: DisableSandbox in /etc/pacman.conf like so
Last edited by mr-andersson (2024-09-22 14:03:10)
Offline
Where are packages temporarily downloaded in this sandbox? I hope it is not /tmp dir or RAM, because I have to many packages.
Offline
In the same location as before (/var/cache/pacman/pkg by default) ?
From what I understand of the MRs that added this, the sandbox uses a dedicated user to restrict downloads to the designated areas.
Until pacman 7 downloads where done with root rights so could potentially overwrite stuff anywhere on the system.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Yeah, I've faced the same problem and I am here, in proxmox containers where you are running everything with root user it's safe to disable this option either way.
Offline