Debian Question posted in
The oficial documentation can be found here.

Failing installation of msodbcsql17 – Debian

I am trying to update a docker image that uses python:3.9 as base (which uses Debian GNU/Linux 10 (buster)), but it now fails with steps that before gave no problems.
The new image sha is @sha256:8f642902ba368481c9aca0a100f08daf93793c6fa14d3002253ea3cd210383a7, and the commands I use can be found in here https://learn.microsoft.com/en-us/sql/connect/odbc/linux-mac/installing-the-microsoft-odbc-driver-for-sql-server?view=sql-server-ver15#debian17.

Here it comes the output error:

#20 0.380 Reading package lists...
#20 0.838 Building dependency tree...
#20 0.942 Reading state information...
#20 0.998 Some packages could not be installed. This may mean that you have
#20 0.998 requested an impossible situation or if you are using the unstable
#20 0.998 distribution that some required packages have not yet been created
#20 0.998 or been moved out of Incoming.
#20 0.998 The following information may help to resolve the situation:
#20 0.998
#20 0.998 The following packages have unmet dependencies:
#20 1.049  libodbc1 : PreDepends: multiarch-support but it is not installable
#20 1.049  odbcinst1debian2 : PreDepends: multiarch-support but it is not installable
#20 1.062 E: Unable to correct problems, you have held broken packages.
------
executor failed running [/bin/sh -c ACCEPT_EULA=Y apt-get install -y msodbcsql17]: exit code: 100

does anyone have an idea why did it stop to work with the new image release?

Tags:

4

Answers


  1. Chosen as BEST ANSWER
    0

    as mentioned by @AlwaysLearning in the comments, indeed the debian version was updated. I solved the problem using python:3.9-buster as base


  2. 0

    TL;DR: The bullseye build, which uses Debian 11, is now the default for python 3 base images. You can either switch to the ‘-buster’ build or fix the minor version number to the previous one.

    I faced the same problem yesterday and fixed it by reverting to the previous version of the python base image.

    In your Dockerfile, if you were using:

    FROM python:3.9, then change it to FROM python:3.9.5

    FROM python:3.8, then change it to FROM python:3.8.10

    FROM python:3.7, then change it to FROM python:3.7.10

    FROM python:3.6, then change it to FROM python:3.6.13

    This doesn’t fix the root cause and it will prevent you from getting fixes introduced in the minor version upgrades of the base Docker image.

    Alternately, you could stick to the buster builds, for example, python:3.9-buster.

    The bullseye build was released 4 days ago and was made the default for all python 3 images. This included an upgrade to Debian 11 from Debian 9.

    However, for production systems, I would suggest fixing the minor version number to the one that works for you.

    Login or Signup to reply.
  3. 0

    Root cause is incompatibility of MS DB drivers with Debian distribution version used by newly released Python 3.9 image. You can verify it by looking at configuration in your dockerfile, that registers MS repository. It will be specific to older Debian.

    If MS Driver supports new Debian, then you can find updated configuration on MS official documentation of their db driver.

    If MS Driver does not support new Debian, then you need to use variant of Python image that is still based on supported Debian version, and keep repository configuration.

    Login or Signup to reply.
  4. 0

    For me the only fix was to change the base image in the Dockerfile from FROM python:3.6-buster to FROM --platform=linux/amd64 python:3.6-buster. The –platform flag is probably needed for people building the image on a M1 chip (apple).

    If you would rather not to change the platform specificacion in the Dockerfile, you can add it while building the image as docker build --platform=linux/amd64 and that should work too.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search