GitLab CI/CD: Attempted to remove disk file system under "/run/systemd/nspawn/propagate/root"

GitLab CI/CD
,
1

Hey all,

I am trying to build Kali Linux VM images (Kali Linux / Build-Scripts / kali-vm · GitLab) via GitLab CI/CD using kalilinux/kali-rolling Docker image. There have been a few hurdles, which I managed to solve, however, there is one that is preventing me from successfully generating the images.

Currently, the .gitlab-ci.yml looks like the following:

stages:
  - build

.setup:
  image: docker.io/kalilinux/kali-rolling

  stage: build

  tags:
    - saas-linux-medium-amd64

  timeout: 2h

  before_script:
    # Install core dependencies:
    - apt-get update && apt-get full-upgrade -y
    - apt-get install -y debos git p7zip qemu-utils zerofree

    # Create /dev/disk, because for some reason it doesn't exist and it causes an error within 3-4 minutes of the pipeline starting, thus failing the pipeline:
    - mkdir -p /dev/disk

    - git clone https://gitlab.com/kalilinux/build-scripts/kali-vm.git
    - cd ./kali-vm

    # Before finishing, fix GitLab Runners throwing noexec or nodev errors, which prevents us from building the ISOs:
    - mount -i -o remount,exec,dev /builds/

.build:
  extends: .setup

  script:
    - ./build.sh -a ${ARCH} -b ${DISTRO} -v ${VARIANT} -z -s 20 -x snapshot

include:
  - .gitlab/manual.yml

With these modifications, the building starts off well, and proceeds well, until the end. Towards the end, when the VM image is finalized, the following error occurs, due to how GitLab CI/CD runs:

2024/12/16 13:20:49 ==== Finish installation ====
2024/12/16 13:20:50 finish-install.sh debconf etc-hosts terminal usergroups zsh | INFO: adding line '127.0.1.1 kali' to /etc/hosts
2024/12/16 13:20:50 finish-install.sh debconf etc-hosts terminal usergroups zsh | INFO: setting x-terminal-emulator alternative to 'qterminal'
2024/12/16 13:20:50 finish-install.sh debconf etc-hosts terminal usergroups zsh | info: Selecting GID from range 100 to 999 ...
2024/12/16 13:20:50 finish-install.sh debconf etc-hosts terminal usergroups zsh | info: Adding group `kaboxer' (GID 137) ...
2024/12/16 13:20:50 finish-install.sh debconf etc-hosts terminal usergroups zsh | info: The group `wireshark' already exists as a system group. Exiting.
2024/12/16 13:20:50 finish-install.sh debconf etc-hosts terminal usergroups zsh | INFO: adding user 'kali' to groups 'adm dialout kaboxer sudo vboxsf wireshark'
2024/12/16 13:20:50 finish-install.sh debconf etc-hosts terminal usergroups zsh | INFO: changing default shell of user 'kali' to zsh
2024/12/16 13:20:50 finish-install.sh debconf etc-hosts terminal usergroups zsh | INFO: changing default shell of user 'root' to zsh
2024/12/16 13:20:50 finish-install.sh debconf etc-hosts terminal usergroups zsh | Attempted to remove disk file system under "/run/systemd/nspawn/propagate/root", and we can't allow that.
2024/12/16 13:20:50 ==== Final cleanup (from within) ====

[...]

2024/12/16 13:20:53 cleanup-in.sh | Attempted to remove disk file system under "/run/systemd/nspawn/propagate/root", and we can't allow that.
2024/12/16 13:20:53 ==== Final cleanup (from outside) ====
2024/12/16 13:20:54 ==== recipe ====
2024/12/16 13:20:54 ==== Setup the disk image ====
2024/12/16 13:20:54 parted | Error: Partition(s) 1 on /dev/loop0 have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.
2024/12/16 13:20:54 Action `recipe` failed at stage Run, error: exit status 1
section_end:1734355275:step_script

As seen above, the CI/CD (or rather, debos), throws an error saying Attempted to remove disk file system under "/run/systemd/nspawn/propagate/root", and we can't allow that.. I have been trying to find a way to “fix” this, using GitLab’s own runners (not self-hosted ones, I already have self-hosted ones running this perfectly fine).

I believe this might be related to the fact that the runners are running in unprivileged Docker containers, but I can’t figure out a way to solve this. As it stands, a self-hosted runner is not an option, as I wish to use my team’s compute quota, which can support this action (as well as quite more).

What can I do to fix this issue to ensure that our CI/CD succeeds, so that I can get this CI/CD up and running ASAP?

TIA.

2 Likes