Foreman and Proxy versions: foremanctl-3.0.0.develop-2.20260703073244501988
Foreman and Proxy plugin versions:
Distribution and version: Rocky Linux 9.8
Other relevant data:
Hello everyone,
I updated foremanctl, then ran foremanctl pull-images followed by foremanctl deploy, and I’m stuck at this point:
TASK [valkey : Start the Valkey Service] **************************************************************************************************
fatal: [localhost]: FAILED! =>
changed: false
msg: |-
Unable to start service valkey: Job for valkey.service failed because the control process exited with error code.
See “systemctl status valkey.service” and “journalctl -xeu valkey.service” for details.
PLAY RECAP ********************************************************************************************************************************
localhost : ok=67 changed=0 unreachable=0 failed=1 skipped=28 rescued=0 ignored=0
[root@foremancontainer ~]# systemctl status valkey.service
× valkey.service
Loaded: loaded (/etc/containers/systemd/valkey.container; generated)
Active: failed (Result: exit-code) since Fri 2026-07-03 18:55:45 CEST; 7min ago
Process: 10043 ExecStart=/usr/bin/podman run --name valkey --replace --rm --cgroups=split --network host --sdnotify=container -d -v /var/lib/valkey:/data:rw,Z Quay run-valkey --supervised systemd (code=exited, status=127)
Process: 10062 ExecStopPost=/usr/bin/podman rm -v -f -i valkey (code=exited, status=0/SUCCESS)
Main PID: 10043 (code=exited, status=127)
CPU: 225ms
Jul 03 18:55:45 foremancontainer.linux.schnell.er podman[10028]: 2026-07-03 18:55:45.524167108 +0200 CEST m=+0.135623660 container init 155f191593f9e58e18c1d12e2ef80239cc51822396fbd780d6fb4b066485eade (image=quay.io/sclorg/valkey-8-c10s:latest, name=valkey, org.label-schema.schema>
Jul 03 18:55:45 foremancontainer.linux.schnell.er podman[10028]: 2026-07-03 18:55:45.529351051 +0200 CEST m=+0.140807575 container start 155f191593f9e58e18c1d12e2ef80239cc51822396fbd780d6fb4b066485eade (image=quay.io/sclorg/valkey-8-c10s:latest, name=valkey, org.label-schema.schem>
Jul 03 18:55:45 foremancontainer.linux.schnell.er valkey[10043]: Fatal glibc error: CPU does not support x86-64-v3
Jul 03 18:55:45 foremancontainer.linux.schnell.er valkey[10028]: 155f191593f9e58e18c1d12e2ef80239cc51822396fbd780d6fb4b066485eade
Jul 03 18:55:45 foremancontainer.linux.schnell.er podman[10047]: 2026-07-03 18:55:45.570144847 +0200 CEST m=+0.025081153 container died 155f191593f9e58e18c1d12e2ef80239cc51822396fbd780d6fb4b066485eade (image=quay.io/sclorg/valkey-8-c10s:latest, name=valkey, summary=Valkey in-memor>
Jul 03 18:55:45 foremancontainer.linux.schnell.er podman[10047]: 2026-07-03 18:55:45.633060612 +0200 CEST m=+0.087996904 container remove 155f191593f9e58e18c1d12e2ef80239cc51822396fbd780d6fb4b066485eade (image=quay.io/sclorg/valkey-8-c10s:latest, name=valkey, org.label-schema.sche>
Jul 03 18:55:45 foremancontainer.linux.schnell.er podman[10047]: 2026-07-03 18:55:45.640342076 +0200 CEST m=+0.095278382 volume remove cec7c021fd2a9fd492269398a3acab848a803d594ec81a6e638ba93d945419e9
Jul 03 18:55:45 foremancontainer.linux.schnell.er systemd[1]: valkey.service: Main process exited, code=exited, status=127/n/a
Jul 03 18:55:45 foremancontainer.linux.schnell.er systemd[1]: valkey.service: Failed with result ‘exit-code’.
Jul 03 18:55:45 foremancontainer.linux.schnell.er systemd[1]: Failed to start valkey.service.
Is there a specific reason why the service needs a chip that supports x86-64-v3? For RHEL 10 as the operating system?
Or has something gone wrong?
Best regards
Dirk
This is an unexpected side effect of the upgrade. Thank you for catching this early, so we can deal with it properly.
Our goal will be to only support EL10, as soon as we can provide a migration path away from EL9. I’m leaning to declaring this as a release note and a prerequisite. How big of an issue would that be for users?
It should be not too limiting as Intel support is from 2013, AMD from 2015. Virtual infrastructure just needs to be configured properly. But as we see here it can be a problem, perhaps @dirk_2809 can describe his setup so we know more about why he is hitting it.
In the end I would expect we get easier support for other architectures like arm with the container based installation and this benefit will outweigh the limitation we get. Especially as we would have the limitation anyway when moving to EL10 as all except Alma Linux have moved to the newer microarchitecturelevel which requires them to rebuild also all EPEL packages so we would need to build twice, too.
I know the CPU can’t handle it, which is why I’m setting up a different configuration now. But it would have been nice to read that a switch to EL 10 was happening.
Or did I miss that?
