Offline pi-gen Build Fails: Docker Execution Without Mounting Host /dev

[TheRealRobinHood]

Hello everyone,

I am working in an offline environment and am planning to build an image using pi-gen within a GitLab pipeline.
The GitLab Runner registered for this task is utilizing a Docker executor.
During my research, I came across the following issues:

• Feature request: Offline build (like buildroot source) #539
• How to lock package versions. #665

To execute the build.sh script offline, I cached the necessary packages with apt-cacher-ng and then copied them into my Docker image. The Docker image itself initiates a local apt-cacher-ng proxy to provide the packages. To enforce apt-cacher-ng to use only cached packages, I activated the offline mode (Offlinemode: 1) in the configuration file of acng, which is located at /etc/apt-cacher-ng/acng.conf. Subsequently, the build.sh script can be executed in the container with the configuration APT_PROXY=http://0.0.0.0:3142.

Dockerfile:

FROM debian:12

RUN DEBIAN_FRONTEND=noninteractive                          &&\
    apt-get --yes update                                    &&\
    apt-get --yes upgrade                                   &&\
    apt-get --yes install --no-install-recommends             \
                    coreutils quilt parted                    \
                    qemu-user-static debootstrap zerofree     \
                    zip dosfstools libarchive-tools           \
                    libcap2-bin grep rsync xz-utils file      \
                    git curl bc qemu-utils kpartx gpg pigz    \ 
                    apt-cacher-ng xxd kmod

COPY acng.conf     /etc/apt-cacher-ng/acng.conf
COPY apt-cacher-ng /var/cache/apt-cacher-ng
COPY entrypoint.sh /sbin/entrypoint.sh

RUN mkdir -p   /home/workspace                                                  &&\
    echo "Acquire::http::Proxy  \"http://0.0.0.0:3142\";"  >> /etc/apt/apt.conf &&\
    apt-get --yes clean autoclean                                               &&\
    apt-get --yes autoremove 

EXPOSE 3142/tcp

HEALTHCHECK --interval=10s --timeout=2s --retries=3 \
    CMD wget -q -t1 -O /dev/null  http://localhost:3142/acng-report.html || exit 1

WORKDIR /home/workspace 
ENTRYPOINT ["/sbin/entrypoint.sh"]

entrypoint.sh:

#!/bin/bash

echo -n "INFO: Setting permissions on /var/cache/apt-cacher-ng, /var/log/apt-cacher-ng, and /var/run/apt-cacher-ng..."
chown -R apt-cacher-ng:apt-cacher-ng /var/cache/apt-cacher-ng /var/log/apt-cacher-ng /var/run/apt-cacher-ng

git config --global --add safe.directory /home/user/workspace
mount -t binfmt_misc binfmt_misc /proc/sys/fs/binfmt_misc
service apt-cacher-ng start

echo "INFO: entrypoint complete; executing CMD '${*}'"
exec "${@}"

The image can be started locally with the following command:

sudo docker run --privileged -it --rm -v <path-to-pi-gen>:/home/workspace <image-name>:<tag> bash

By analyzing the docker run command, it becomes evident that the container is executed without mounting the host /dev directory.
This issue has already been discussed in the following issue:

• losetup fails with docker-in-docker #482

Omitting -v /dev:/dev in the docker run command leads to the build.sh script failing with the following error:

[18:23:01] Begin /home/workspace/stage5
[18:23:01] End /home/workspace/stage5
[18:23:01] Begin /home/workspace/export-image
[18:23:01] Begin /home/workspace/export-image/prerun.sh
Creating loop device...
mkdosfs: unable to open /dev/loop5p1: No such file or directory

By adding the following code (as also described in Issue #482) to the export-image/prerun.sh script, below the 'until ensure_next_loopdev' statement, this issue can be resolved, and the build.sh script should run successfully.

PARTITIONS=$(lsblk --raw --output "MAJ:MIN" --noheadings ${LOOP_DEV} | tail -n +2)
COUNTER=1
for i in $PARTITIONS; do
    echo "Creating node file for partition $i..."
    MAJ=$(echo $i | cut -d: -f1)
    MIN=$(echo $i | cut -d: -f2)
    if [ ! -e "${LOOP_DEV}p${COUNTER}" ]; then mknod ${LOOP_DEV}p${COUNTER} b $MAJ $MIN; fi
    COUNTER=$((COUNTER + 1))
done

Since Issue #482 has already been closed, assuming the problem has been fixed, I have opened a new issue.
Additionally, I opened a new issue as it indirectly addresses questions from other issues.