CPU does not support x86-64-v2

[mauropiccini]

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

---

Edit: all mysql images regardless of MySQL version that are based on Oracle Linux 9 require a CPU with x86-64-v2 support. See links below in #1055 (comment)

[PopC0rnwalk]

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]

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

[LaurentGoderre]

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]

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]

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 (#1055 (comment)) to help us gauge user need.

[yosifkit]

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]

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]

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 version was 8.0.32, I'll 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]

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]

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

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.

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

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

[yosifkit]

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:

• 8 -> the newest 8.x on the newest Oracle Linux (currently equal to 8.4.0-oraclelinx9)
• 8-oraclelinux9 -> the newest 8.x on Oracle Linux 9 (currently equal to 8.4.0-oraclelinx9)
• 8.4 -> will be the newest 8.4.x on the newest Oracle Linux (currently equal to 8.4.0-oraclelinx9)
• 8.4.0 -> the newest 8.4.0 on the newest Oracle Linux (currently 8.4.0-oraclelinx9, not updated once .1 comes out)
• 8.4.0-oraclelinux9 -> the newest 8.4.0 on Oracle Linux 9 (not updated once .1 comes out)
• 8.0 -> will be the newest 8.0.x on the newest Oracle Linux (currently equal to 8.0.37-oraclelinx9)
• 8.0-debian -> the newest 8.0.x on the newest Debian (currently 8.0.37-bookworm)
• inactive tags:
  • not updated anymore: CPU does not support x86-64-v2 #1055 (comment))
  • 8-oraclelinux8 -> the newest 8.x on Oracle Linux 8 (currently 8.4.0-oraclelinux8)
  • 8.0-oraclelinux8 -> the newest 8.0.x on Oracle Linux 8 (currently 8.0.37-oraclelinux8)

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

Tags will also point to a rebuilt image if 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.