search

docker-library / mysql

Docker Official Image packaging for MySQL Community Server
https://dev.mysql.com/
GNU General Public License v2.0
2.42k stars 2.18k forks source link

CPU does not support x86-64-v2 in the latest 8.4.0 #1055

Open mauropiccini opened 1 month ago

mauropiccini commented 1 month ago

The latest 8.4.0 image cannot run on older CPUs (maybe after upgrading to oracle linux 9). The only message in docker logs is Fatal glibc error: CPU does not support x86-64-v2

PopC0rnwalk commented 1 month ago

Hi,

Same here, affected by the same issue. the docker image was automatically updated in my system and since it is running oracle linux 9 started to failed.

As workarround and emergency to get the site back online I switched to the debian image and updated mysql version to 8.4.0, here is the dockerfile content if help:

FROM mysql:8.0-debian

# Remove mysql repo list file
RUN rm -f /etc/apt/sources.list.d/mysql.list

# Update package lists and upgrade existing packages
RUN apt update && apt install -y wget

# Download MySQL APT configuration package
WORKDIR /home/
RUN wget https://dev.mysql.com/get/mysql-apt-config_0.8.30-1_all.deb

# Install MySQL APT configuration package and select option 4 automatically
RUN DEBIAN_FRONTEND=noninteractive
RUN echo "4" | apt install -y ./mysql-apt-config_0.8.30-1_all.deb
RUN apt update && apt full-upgrade -y

Then I executed: docker build -t custom/mysql:8.4.0 --network=host .

LaurentGoderre commented 1 month ago

I don't think this is related to the version specifically but to #1047 which switched the oraclelinux base from 8 to 9

LaurentGoderre commented 1 month ago

If you want to keep using oracle linux, you will need to pin to a tag prior to the update such as mysql:8.4.0-oraclelinux8 (note that the tag will not be getting any update though)

Danny-Donuts commented 1 month ago

I'm also experiencing the same issue. Hoping it's a quick update to the docker image. Currently on vacation and can't manually downgrade.

yosifkit commented 1 month ago

Assuming that mysql:8.4.0-oraclelinux8 fixes the problem:

If there are enough users requiring the orcalelinux8-based image because of CPU restrictions, it might make sense for us to continue to build both (until the first of OL8 and the MySQL version is EOL) since these users cannot move to the newer Oracle Linux release. So, if mysql:8.4.0-oraclelinux9 doesn't work for you in the way described in this issue and mysql:8.4.0-oraclelinux8 does work, please 👍 this comment or the opening comment (https://github.com/docker-library/mysql/issues/1055#issue-2282294327) to help us gauge user need.

yosifkit commented 1 month ago

Confirmed that Oracle Linux 9 requires the x86-64-v2 microarchitecture level (docs.oracle.com):

Available Architectures

The release is available for installation on the following platforms:

  • Intel® 64-bit (x86_64) (x86-64-v2)
  • AMD 64-bit (x86_64) (x86-64-v2)
Danny-Donuts commented 1 month ago

I'm also experiencing the same issue. Hoping it's a quick update to the docker image. Currently on vacation and can't manually downgrade.

I swapped out mysql:latest to mysql:8.4.0-oraclelinux8 and that fixed my issue.

Thanks!

crlsgms commented 1 month ago

Our dev environment also broke, as we were working with mysql:8.0 tag, and now its pushing the image from 2 days ago

last working verwion was 8.0.32, will validate if pushing this old image will fix the issue

before finding this issue the workarround we did as devvms are running over proxmox, was to change the processor from kvm64(default) to Broadwell-no-TSX and 8.0.37 worked

NotGovernor commented 1 month ago

Our server running mysql:8 on a proxmox instance is now dead with this update.

Error: Fatal glibc error: CPU does not support x86-64-v2

crlsgms commented 1 month ago

To add more info on my tests, here is what I got from digging up the issue after the hack changing the cpu model on the machines to support the new image

Dev team usually when rebuild images get the same image:tag to lock versions image

but for some reason the 8.0 tag now points to a different image, as we can see on the image hub it was changed in the same day as the new.37 version. Maybe it it like it is, and minor tags 8.0.xx will fetch the lates commit without locking on the minors.

image image

I have an internal repository on harbor, where devs can also get older images to validate, and comparing size / dates we can see that both 8.0 versions are quite different in size and release date image

So, if this tag is used like this to always push another image, may be needed to clarify on the hub so whoever uses them on production do not break the environment as a different service will be pushed, even compromising data on the database itself.

not everyone uses an orchastrator behindo to tune cpu flags, or will be lost before finding out that is using a completely different image with the same tag

just for reference, difference between images / tags on our dockerhub harbor proxy image

yosifkit commented 1 month ago

but for some reason the 8.0 tag now points to a different image

Every active tag in official images can and will be updated to point to an image as new as the tag's specificity allows:

(And so on for lts-* and innovation-*, etc)

Tags will also point to a rebuilt image in the parent image is updated. So, a new OL9 or Debian Bookworm image would cause those MySQL images from them to be rebuilt and the tags updated.