My build pipeline has stopped working all of a sudden which was working fine a few weeks ago. I'm using Dockerfile to build my app with python:3.8 as the base image. It has started failing on the apt-get update && apt-get install part. I didn't change anything in the Dockerfile.

My Dockerfile looks like this:

FROM python:3.8
...
...
...
RUN apt-get update && \
    apt-get install -y default-libmysqlclient-dev libffi-dev libssl-dev git jq tree
...
...
...

Below is the error I'm getting:

W: GPG error: http://deb.debian.org/debian bookworm InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0E98404D386FA1D9 NO_PUBKEY 6ED0E7B82643E131 NO_PUBKEY F8D2585B8783D481
E: The repository 'http://deb.debian.org/debian bookworm InRelease' is not signed.

What is the cause of this? How to fix it?

2

There are 2 answers

0
Abdullah Khawer On BEST ANSWER

Why this happened?

The Python docker images have been updated recently to use Debian 12 bookworm version which was released on 10 June 2023 instead of Debian 10 buster.

Sources:

What is the root cause?

It is Docker with libseccomp so a newer syscall used in Debian Bookworm packages/libs is being blocked. libseccomp lets you configure allowed syscalls for a process. Docker sets a default seccomp profile for all containers such that only certain syscalls are allowed and everything else is blocked (so, newer syscalls that are not yet known to libseccomp or docker are blocked).

Source: python:3.9 - Failed run apt update from the last version of the image #837

Possible Solutions:

Either

  • Add the following in the Dockerfile:
RUN mv -i /etc/apt/trusted.gpg.d/debian-archive-*.asc  /root/
RUN ln -s /usr/share/keyrings/debian-archive-* /etc/apt/trusted.gpg.d/

Or

  • Use any of the bullseye image (e.g., python:3.8-slim-bullseye).

Or

  • Update libseccomp and docker on the host running the containers.
0
syats On

Updating the docker system is the only solution that worked for me.

The ones listed above are not always applicable, e.g. if you are building not directly from a python:3.8 image, but from some image that derives from it, then you have no control over what is the base debian version.