Pacman doesn't work in Docker image

Question

I need to run an Arch Linux container but I can't install anything on it :

When I try to run pacman -Syyu --noconfirm

error: failed to initialize alpm library
(could not find or read directory: /var/lib/pacman/)

Following that thread

I ran

pacman-db-upgrade

but that also failed :

==> ERROR: You must have correct permissions to upgrade the database.

This container is a vanilla archlinux:latest-based container launched with docker run -it archlinux

I did a little bit of testing, and I was able to identify with strace that pacman calls syscall_0x1b7, which returns the EPERM error. If I launch the container as `--privileged`, it still calls that syscall, but it returns as follows before continuing normally: `syscall_0x1b7(0xffffff9c, 0x7ffc1afb50c0, 0, 0x200, 0x1, 0xffffffffffffffff) = -1 ENOSYS (Function not implemented)` `--privileged` is not a proper solution. Maybe pacman needs a different switch or other configuration so it doesn't call that syscall? closest thing I could find: https://bugzilla.redhat.com/show_bug.cgi?id=1869030 — programmerq, Feb 09 '21 at 21:18
Upgrading your docker version may fix this; at least it did for me when trying to run an archlinux container on Ubuntu. See https://stackoverflow.com/a/66385784/14558 — andrew.n, Apr 23 '21 at 19:12
I'm seeing the same problem when running arch in unprivileged podman container. This seems to be bigger problem with glibc (at the time I write this comment the issue is still not solved). I use older base image, the one from 10th of January 2021. — Greg0ry, May 10 '21 at 12:00

sickcodes · Answer 1 · 2022-01-24T20:55:11.317

EDIT3: This is now fixed, and glibc has been added to /etc/pacman.conf as a HoldPkg to prevent an official image from failing in the future.

EDIT2: Add this before & after running pacman anywhere inside the Dockerfile.

# TEMP-FIX for pacman issue
RUN patched_glibc=glibc-linux4-2.33-4-x86_64.pkg.tar.zst \
    && curl -LO "https://raw.githubusercontent.com/sickcodes/Docker-OSX/master/${patched_glibc}" \
    && bsdtar -C / -xvf "${patched_glibc}" || echo "Everything is fine."
# TEMP-FIX for pacman issue

I added it 4 times inside our Dockerfile: https://github.com/sickcodes/Docker-OSX/pull/159

EDIT: An unofficial patch is available, which we copied from: https://github.com/qutebrowser/qutebrowser/commit/478e4de7bd1f26bebdcdc166d5369b2b5142c3e2

# WORKAROUND for glibc 2.33 and old Docker
# See https://github.com/actions/virtual-environments/issues/2658
# Thanks to https://github.com/lxqt/lxqt-panel/pull/1562
RUN patched_glibc=glibc-linux4-2.33-4-x86_64.pkg.tar.zst && \
    curl -LO "https://repo.archlinuxcn.org/x86_64/$patched_glibc" && \
    bsdtar -C / -xvf "$patched_glibc"

ORIGINAL: This is a live bug, should be fixed (allegedly) this week.

https://bugs.archlinux.org/index.php?do=details&task_id=69563

The bug is due to backwards compatability of glibc 2.33, but almost every other distro will not build glibc 2.33 inside Docker.

If you build it on an Arch host, it will build.

It has to do with runc, which has actually already been patched, but we're waiting on one of two outcomes:

All of the other distros and building services catching up (don't hold your breath)
Or for this util-linux fix to be implemented: https://bugs.archlinux.org/index.php?do=details&task_id=69613

We have the exact same issue here preventing all hub.docker.com builds:

https://github.com/sickcodes/Docker-OSX/issues/144

Shakiba Moshiri · Answer 2 · 2021-02-11T09:23:54.057

As long as I understood it is because of privilege configuration with the Docker and running a container. When we login to the OS, it seems we are root but infact we do not have the right root permission. And here is a simple try:

root[0]docker:~# docker run -it archlinux:latest bash
[root@c565c90fdb7f /]# pacman
error: failed to initialize alpm library
(could not find or read directory: /var/lib/pacman/)
[root@c565c90fdb7f /]# exit
exit

but if we give the right root permission when we login to the container then it is okay.

root[0]docker:~# docker run -it --privileged=true archlinux:latest bash
[root@0d95575abec6 /]# dir
bin  boot  dev  etc  home  lib  lib64  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
[root@0d95575abec6 /]# pacman
warning: database file for 'core' does not exist (use '-Sy' to download)
warning: database file for 'extra' does not exist (use '-Sy' to download)
warning: database file for 'community' does not exist (use '-Sy' to download)
error: no operation specified (use -h for help)
[root@0d95575abec6 /]# pacman -Sy
:: Synchronizing package databases...
 core                                                                                                        131.2 KiB  10.7 MiB/s 00:00 [####################################################################################] 100%
 extra                                                                                                      1654.4 KiB   101 MiB/s 00:00 [####################################################################################] 100%
 community                                                                                                     5.4 MiB   270 MiB/s 00:00 [####################################################################################] 100%
[root@0d95575abec6 /]# exit
exit

So for login to Arch Linux this options --privileged=true should be used whereas for Debian , Alpine, Ubunut it seems we do not need it.

Has been tested on:

cat /etc/os-release

NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://www.archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://bugs.archlinux.org/"
LOGO=archlinux

and

 pacman -V

 .--.                  Pacman v5.2.2 - libalpm v12.0.2
/ _.-' .-.  .-.  .-.   Copyright (C) 2006-2020 Pacman Development Team
\  '-. '-'  '-'  '-'   Copyright (C) 2002-2006 Judd Vinet
 '--'
                       This program may be freely redistributed under
                       the terms of the GNU General Public License.

and Docker

docker -v
Docker version 19.03.6, build 369ce74a3c

How to apply this trick (which works in a container) to a Dockerfile? — Andrew Arnott, Apr 03 '21 at 19:49
@AndrewArnott - look at this [Run command as --privileged in Dockerfile](https://stackoverflow.com/questions/41602856/run-command-as-privileged-in-dockerfile) it may help you. — Shakiba Moshiri, Apr 04 '21 at 06:22

score 1 · Answer 3 · answered Feb 16 '21 at 12:07

1

Things don't work properly neither with the patched glibc nor the --privileged=true option. Its a really big problem if archlinux us not an option for docker.

Example: building with dotnet just outputs loads of:

realpath(): Operation not permitted

answered Feb 16 '21 at 12:07

Jakob Simon-Gaarde

73
5

score 1 · Answer 4 · answered Mar 26 '21 at 14:56

I'm using Docker Desktop 3.2.2 for Mac. Based on this bug report (opened 2021-02-06), I visited Docker Hub and located the latest tag prior to that date. It worked.

$ docker run -it archlinux:base-devel-20210131.0.14634 bash
[root@ec8c7574f481 /]# pacman -Syy
:: Synchronizing package databases...
 core       131.1 KiB   478 KiB/s 00:00 [########] 100%
 extra     1649.2 KiB   345 KiB/s 00:05 [########] 100%
 community    5.4 MiB   133 KiB/s 00:42 [########] 100%

Note: If you run pacman -Syu it will update to [basically] the same as the :latest docker tag, and the problem will resurface.

Won't satisfy everyone's needs, but it's info that will help some. ☮️❤️‼️

Pacman doesn't work in Docker image

4 Answers4