unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
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 --]

  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).