From: Simon Josefsson via <help-guix@gnu.org>
To: help-guix@gnu.org
Cc: "Ludovic Courtès" <ludo@gnu.org>,
suhail@bayesians.ca, "Cayetano Santos" <csantosb@inventati.org>
Subject: GitLab container /etc symlink problem (was: Re: Building a Docker image for GitLab-CI)
Date: Mon, 23 Dec 2024 19:57:50 +0100 [thread overview]
Message-ID: <878qs6rzv5.fsf_-_@kaka.sjd.se> (raw)
In-Reply-To: <87ldw7pp6d.fsf@kaka.sjd.se> (Simon Josefsson via's message of "Sun, 22 Dec 2024 19:07:06 +0100")
[-- Attachment #1: Type: text/plain, Size: 4001 bytes --]
Simon Josefsson via <help-guix@gnu.org> writes:
>>> Re /etc=etc it seems GitLab's docker setup bind-mounts things below
>>> /etc/ and it cannot handle the root /etc symlink. A workaround is to
>>> use `lndir` which I use in the `test-amd64-package-install` job. This
>>> is limitation of GitLab's docker setup: I tried running a `-S
>>> /etc=etc` image on my own GitLab runner based on Trisquel [1] and it
>>> worked fine, it mounted things below the symlinked tree properly.
>>> Could `guix pack` be teached how to do a lndir-approach for /etc
>>> instead of symlink, perhaps?
>>
>> It could symlink individual files and make /etc a directory.
>
> Is this possible now? How?
>
> The --symlink is defined like this now:
>
> ‘-S SPEC’
> Add the symlinks specified by SPEC to the pack. This option can
> appear several times.
> SPEC has the form ‘SOURCE=TARGET’, where SOURCE is the symlink that
> will be created and TARGET is the symlink target.
> For instance, ‘-S /opt/gnu/bin=bin’ creates a ‘/opt/gnu/bin’
> symlink pointing to the ‘bin’ sub-directory of the profile.
>
> Could we extend that somehow to support the model of recursively
> creating directories, but symlink files within them?
>
> Or a new --symlink-mkdir parameter or similar?
>
>> (What’s ‘lndir’, if I may ask?)
>
> Exactly that :)
I found out that the lndir approach doesn't work. The /etc symlinks are
modified by 'guix package -i'. It only occurs sometimes, probably
depending on if it happens to pull in a new version of 'net-base'. It
seems 'guix package -i hello' works but 'guix package -i skopeo'
doesn't.
https://gitlab.com/debdistutils/guix/container/-/jobs/8713723100
...
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
61.5 MB will be downloaded
retrying download of '/gnu/store/bfp25w47fxn8z0fdwj45prx2609sx59j-net-base-5.3' with other substitute URLs...
guix substitute: warning: ci.guix.gnu.org: host not found: Servname not supported for ai_socktype
guix substitute: error: failed to find alternative substitute for '/gnu/store/bfp25w47fxn8z0fdwj45prx2609sx59j-net-base-5.3'
substitution of /gnu/store/bfp25w47fxn8z0fdwj45prx2609sx59j-net-base-5.3 failed
guix package: error: some substitutes for the outputs of derivation `/gnu/store/cviappwxgh7ilhprl44x5ya2nypwlcj7-skopeo-1.17.0.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source
You can see that networking worked initially, but broke down later on.
lrwxrwxrwx 1 root 0 70 Dec 23 18:24 protocols -> /gnu/store/bfp25w47fxn8z0fdwj45prx2609sx59j-net-base-5.3/etc/protocols
After running 'guix package -i skopeo' that symlink is danling:
++ echo '$ ls -ld /gnu/store/*net-base*'
++ ls -ld /gnu/store/bfp25w47fxn8z0fdwj45prx2609sx59j-net-base-5.3.lock /gnu/store/i705faz4w4wnq1frrbbrk2jnhwhsr2k9-net-base-5.3-builder /gnu/store/kaqyk1rn9f4q36h8nc0919wrlam0xl0g-net-base-5.3.drv
-rw------- 1 root 0 0 Dec 23 18:26 /gnu/store/bfp25w47fxn8z0fdwj45prx2609sx59j-net-base-5.3.lock
-r--r--r-- 1 root 0 893 Jan 1 1970 /gnu/store/i705faz4w4wnq1frrbbrk2jnhwhsr2k9-net-base-5.3-builder
-r--r--r-- 1 root 0 990 Jan 1 1970 /gnu/store/kaqyk1rn9f4q36h8nc0919wrlam0xl0g-net-base-5.3.drv
++ echo '$ ls -ld /gnu/store/*profile*'
I've reverted back to this hack:
cp -rL /gnu/store/*profile/etc/* /etc/
Is there a clean solution to this? Perhaps we could debug further why
GitLab/docker barfs on a /etc symlink. It is probably related to them
having these mount points:
/dev/sda1 /etc/hostname ext4 rw,nosuid,nodev,relatime,commit=30 0 0
/dev/sda1 /etc/hosts ext4 rw,nosuid,nodev,relatime,commit=30 0 0
/dev/sda1 /etc/resolv.conf ext4 rw,nosuid,nodev,relatime,commit=30 0 0
Maybe -S /etc=etc works if we make sure to remove just those three
files..
/Simon
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]
next prev parent reply other threads:[~2024-12-23 18:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-14 12:36 Building a Docker image for GitLab-CI Suhail
2024-12-15 21:05 ` Cayetano Santos
2024-12-15 21:27 ` Cayetano Santos
2024-12-16 10:42 ` Simon Josefsson via
2024-12-16 11:04 ` Andreas Enge
2024-12-18 19:17 ` Simon Josefsson via
2024-12-18 22:31 ` Cayetano Santos via
2024-12-17 7:52 ` Ludovic Courtès
2024-12-17 8:07 ` Simon Josefsson via
2024-12-17 10:24 ` Ludovic Courtès
2024-12-17 23:46 ` Simon Josefsson via
2024-12-21 15:33 ` Ludovic Courtès
2024-12-22 18:07 ` Simon Josefsson via
2024-12-23 18:08 ` Container image entrypoints on Gitlab (was: Re: Building a Docker image for GitLab-CI) Simon Josefsson via
2024-12-25 18:13 ` Container image entrypoints on Gitlab Simon Josefsson via
2024-12-23 18:57 ` Simon Josefsson via [this message]
2024-12-25 20:38 ` Building a Docker image for GitLab-CI Simon Josefsson via
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878qs6rzv5.fsf_-_@kaka.sjd.se \
--to=help-guix@gnu.org \
--cc=csantosb@inventati.org \
--cc=ludo@gnu.org \
--cc=simon@josefsson.org \
--cc=suhail@bayesians.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).