Pacman hooks not run in unpriviledged containers.
I'm running a archlinux:base-devel
-derived test in gitlab-ci with docker-based ci-runners that builds a LaTeX-document.
The config roughly looks like this:
archlinuxRolling:
image: archlinux:base-devel
extends:
- .buildthesis
before_script:
- >
pacman -Syy && \
pacman -Syu --noconfirm && \
pacman -S --noconfirm \
texlive-meta \
texlive-lang \
biber \
perl-clone
# Ensure that biber is in PATH from now on
- source /etc/profile
# The hooks do not reliably trigger as chroot is not supported in gitlabci
# Use subshells to scope the cd /
- (cd / && /usr/share/libalpm/scripts/mktexlsr)
- (cd / && /usr/share/libalpm/scripts/texlive-language)
- (cd / && /usr/share/libalpm/scripts/texlive-fmtutil)
- (cd / && /usr/share/libalpm/scripts/texlive-updmap)
However, the texlive-related hooks do not work:
:: Running post-transaction hooks...
( 1/13) Creating system user accounts...
could not change the root directory (Operation not permitted)
( 2/13) Reloading system manager configuration...
error: command failed to execute correctly
could not change the root directory (Operation not permitted)
error: command failed to execute correctly
( 3/13) Arming ConditionNeedsUpdate...
could not change the root directory (Operation not permitted)
error: command failed to execute correctly
( 4/13) Updating the MIME type database...
could not change the root directory (Operation not permitted)
( 5/13) Updating fontconfig configuration...
error: command failed to execute correctly
could not change the root directory (Operation not permitted)
error: command failed to execute correctly
( 6/13) Updating TeXLive filename database...
could not change the root directory (Operation not permitted)
( 7/13) Updating TeXLive language files...
error: command failed to execute correctly
could not change the root directory (Operation not permitted)
( 8/13) Updating TeXLive format files...
error: command failed to execute correctly
could not change the root directory (Operation not permitted)
( 9/13) Updating TeXLive font maps...
error: command failed to execute correctly
could not change the root directory (Operation not permitted)
(10/13) Reloading system bus configuration...
error: command failed to execute correctly
could not change the root directory (Operation not permitted)
error: command failed to execute correctly
(11/13) Warn about old perl modules
could not change the root directory (Operation not permitted)
error: command failed to execute correctly
(12/13) Updating fontconfig cache...
could not change the root directory (Operation not permitted)
error: command failed to execute correctly
(13/13) Probing GDK-Pixbuf loader modules...
could not change the root directory (Operation not permitted)
error: command failed to execute correctly
This also happens spuriously on certain package installs:
installing perl-xml-sax...
could not change the root directory (Operation not permitted)
error: command failed to execute correctly
Full CI-Log excerpt is attached
As can be seen in the CI-job configuration, the error actually prevents hook execution, so to get a working texlive installation, I have to manually trigger the pacman hook scripts (last four lines of the CI configuration), which is quite unsatisfactory.
By cursory browsing of pacmans code, this seems to fit:
Hooks are run via _alpm_hook_run_hook
, which uses _alpm_run_chroot
to actually run hook commands, errorcodes from chroot then lead to an early exit of hook execution here.
The calls seem unconditional, so I do not believe that there is a commandline option or similar to skip the chroot...
Other information in case this is helpful: This is running on my universities CI-runners, which run via the gitlab-runner
packages provided from https://packages.gitlab.com/runner/gitlab-runner/debian bullseye/main
on debian bullseye (currently version 16.2.0), running the debian-bullseye version of docker, CI-runners run as unpriveledged containers. But as this bug concerns chroot and this is a rather established systemcall, I'd assume that this is not docker-version related.
There is #56 which is vagualy related, but as the discussion there centers around faccessat2
and friends, I opted for creating a new issue.
Thank you for reading this far and maintaining the dockercontainer in the first place :D
~ Simon