Repository navigation
The current machine does not support all of the following CPU features that are required by the image #148326
Description
Activity
Same here. Had to downgrade everything back to 9.3.4.
There's something wrong this this 9.4.0 release.
Reacted by Chris and TrixFor me it was a VM running on the Proxmox hypervisor.
The solution was to change the processors’ type toNative.
A clearer error message would’ve been nicer though.
Trying to turn off the ML features (xpack.ml.enabled: false) didn’t help either - I had to change the server vCPUs type.
@grizzlydev-sarl that might help you too!Pinging @elastic/es-core-infra (Team:Core/Infra)
I have observed the same problem on a bare-metal installation with an older processor (Sandybridge). Versions older than 9.4.0 work without issue.
This is also on an up-to-date Debian kernel
uname -a Linux <hostname> 6.12.85+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.85-1 (2026-04-30) x86_64 GNU/LinuxCPU flags from
/proc/cpuinfo:flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm pti ssbd ibrs ibpb stibp tpr_shadow flexpriority ept vpid xsaveopt dtherm ida arat pln pts vnmi md_clear flush_l1dI'm experiencing the same issue. I have a cluster running bare-metal on old HP ProLiant DL380p Gen8 servers with Intel(R) Xeon(R) CPU E5-2620 (Nahalem) CPUs. The OS is Ubuntu 24.04 LTS with the deb based package installation.
May 07 08:33:52 elk3 systemd[1]: Starting elasticsearch.service - Elasticsearch... May 07 08:33:53 elk3 systemd-entrypoint[1016]: The current machine does not support all of the following CPU features that are required by the image: [CX8, CMOV, FXSR, MMX, SSE, SSE2, SSE3, SSSE3, SSE4_1, SSE4_2, POPCNT, LZCNT, AVX, AVX2, BMI1, BMI2, FMA, F16C]. May 07 08:33:53 elk3 systemd-entrypoint[1016]: Please rebuild the executable with an appropriate setting of the -march option. May 07 08:33:53 elk3 systemd[1]: elasticsearch.service: Main process exited, code=exited, status=1/FAILURE May 07 08:33:53 elk3 systemd[1]: elasticsearch.service: Failed with result 'exit-code'. May 07 08:33:53 elk3 systemd[1]: Failed to start elasticsearch.service - Elasticsearch.$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 45 model name : Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz stepping : 7 microcode : 0x71a cpu MHz : 2500.000 cache size : 15360 KB physical id : 0 siblings : 12 core id : 0 cpu cores : 6 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb pti ssbd ibrs ibpb stibp tpr_shadow flexpriority ept vpid xsaveopt dtherm ida arat pln pts vnmi md_clear flush_l1d ibpb_exit_to_user vmx flags : vnmi preemption_timer invvpid ept_x_only ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_unknown vmscape bogomips : 3990.39 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management:I spun up an Ubuntu VM in our Hyper-V environment on hosts with Intel(R) Xeon(R) CPU E5-2670 v3 (Haswell) CPUs . The VM had no issues running Elasticsearch 9.4.0. Comparing the supported flags show the Haswell CPU supports AVX2, BMI1, BMI2, FMA, and F16C while the Nahalem CPU doesn't.
Is AVX2 now a requirement to run Elasticsearch?
- added a commit that references this issue
on May 7, 2026 - added a commit that references this issue
on May 7, 2026 I'm investigating.
I have a potential fix, I see 9.4.0 ships a GraalVM native-image server-launcher built without an explicit -march, so it inherits GraalVM 25's default x86-64-v3 baseline and refuses to start on pre-Haswell CPUs (Nehalem/Sandy Bridge/Ivy Bridge). The fix pins -march=x86-64-v2 on the x86_64 task.
PR: #148542
I'll also investigate a workaround.
Reacted by Chris and hgshogginsI have also facing similar problem. Can you please help me to find solution?
root@virtkibana:
# journalctl -u elasticsearch.service --no-pager#
May 08 04:19:04 virtkibana systemd[1]: Starting elasticsearch.service - Elasticsearch...
May 08 04:19:04 virtkibana systemd-entrypoint[8297]: The current machine does not support all of the following CPU features that are required by the image: [CX8, CMOV, FXSR, MMX, SSE, SSE2, SSE3, SSSE3, SSE4_1, SSE4_2, POPCNT, LZCNT, AVX, AVX2, BMI1, BMI2, FMA, F16C].
May 08 04:19:04 virtkibana systemd-entrypoint[8297]: Please rebuild the executable with an appropriate setting of the -march option.
May 08 04:19:04 virtkibana systemd[1]: elasticsearch.service: Main process exited, code=exited, status=1/FAILURE
May 08 04:19:04 virtkibana systemd[1]: elasticsearch.service: Failed with result 'exit-code'.
May 08 04:19:04 virtkibana systemd[1]: Failed to start elasticsearch.service - Elasticsearch.
May 08 04:21:41 virtkibana systemd[1]: Starting elasticsearch.service - Elasticsearch...
May 08 04:21:41 virtkibana systemd-entrypoint[8356]: The current machine does not support all of the following CPU features that are required by the image: [CX8, CMOV, FXSR, MMX, SSE, SSE2, SSE3, SSSE3, SSE4_1, SSE4_2, POPCNT, LZCNT, AVX, AVX2, BMI1, BMI2, FMA, F16C].
May 08 04:21:41 virtkibana systemd-entrypoint[8356]: Please rebuild the executable with an appropriate setting of the -march option.
May 08 04:21:41 virtkibana systemd[1]: elasticsearch.service: Main process exited, code=exited, status=1/FAILURE
May 08 04:21:41 virtkibana systemd[1]: elasticsearch.service: Failed with result 'exit-code'.
May 08 04:21:41 virtkibana systemd[1]: Failed to start elasticsearch.service - Elasticsearch.
root@virtkibana:
root@virtkibana:## lscpu | grep -E "Flags|Model"
root@virtkibana:
Model name: Westmere E56xx/L56xx/X56xx (Nehalem-C)
BIOS Model name: pc-i440fx-noble-v2 CPU @ 2.0GHz
Model: 44
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes hypervisor lahf_lm cpuid_fault pti ssbd ibrs ibpb stibp tpr_shadow ept vpid tsc_adjust arat vnmi umip flush_l1d arch_capabilities
root@virtkibana:##
root@virtkibana:
root@virtkibana:# grep -o -w 'sse4_2|avx|fma' /proc/cpuinfo | sort -u#
sse4_2
root@virtkibana:
root@virtkibana:## lscpu | grep -E "avx|fma"
root@virtkibana:
root@virtkibana:~# exitConfirming that we've seen this issue on Proxmox/Talos VM nodes.
The fix should go out in the
9.4.1patch (and is included in the9.5.0release): #148542Until the patch release ships, you can force the launcher to take the JVM fallback path:
sudo systemctl stop elasticsearch sudo chmod -x /usr/share/elasticsearch/lib/tools/server-launcher/server-launcher sudo systemctl start elasticsearchThe startup script bin/elasticsearch checks [ -x "$NATIVE_LAUNCHER" ] and falls through to a JVM launcher if the native binary isn't executable. Performance impact is negligible, the launcher is a short-lived bootstrap, not on the request path. Note: package upgrades reinstall the binary with 0755, so the workaround needs to be reapplied after each upgrade until you're on a release containing the fix.
If you're on a hypervisor (VMware / Proxmox / Hyper-V) and your physical host CPU is Haswell or newer, switching the guest CPU type to host-passthrough is an alternative that doesn't require touching files (but caveats apply when live-migrating hosts between mixed generations).
The native launcher is a startup-time optimization introduced in 9.4.0 — it replaces a small JVM-based launcher process that ran for the life of the node in 9.3.x and earlier, saving ~40–90 MB of RSS and ~1–2 s of startup latency. Disabling it returns the launcher to the pre-9.4 JVM-based path, which has shipped unchanged for years and is still the default on Windows, macOS, and any Linux install without the native binary. There is no functional or security difference; the actual Elasticsearch server JVM behaves identically.
Reacted by grizzlydev-sarlReacted by amorrowbellarmine, hgshoggins, Henrique Azevedo, Chris and BennettThe fix should go out in the
9.4.1patch (and is included in the9.5.0release): #148542Looks like the fix didn't make it into the 9.4.1 release. It landed after the 9.4.1 release tag: v9.4.0...v9.4.1, v9.4.1...9.4
Update on the workaround:
chmod a-xcovers the case whenumask=0077.sudo systemctl stop elasticsearch sudo chmod a-x /usr/share/elasticsearch/lib/tools/server-launcher/server-launcher sudo systemctl start elasticsearch
- marked Elasticsearch 9.4.0 fails to start after upgrade from 9.3.0 due to new CPU feature requirements #151026 as a duplicate of this issue
on Jun 9, 2026
Elasticsearch Version
9.4.0
Installed Plugins
No response
Java Version
openjdk version "21.0.11" 2026-04-21
OS Version
Linux tlog-server 6.12.85+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.85-1 (2026-04-30) x86_64 GNU/Linux
Problem Description
After running
apt update && apt upgrade --yeson my Debian machine, I upgraded my ELK stack from 9.3.4 to 9.4.0:From that point kibana, logstash and metricbeat worked - while elasticsearch failed to start.
systemctl status elasticsearchproduced:From inspecting
/proc/cpuinfoIt seems my machine does support all of the above flags - BUTSSE3is listed aspni(Prescott New Instructions - Intel's name forSSE3).No matter what I try, I cannot get it to run. What am I missing? I suppose this is the upgrade that happened today to 9.4.0 that made the difference - but I'm not sure why :((
Steps to Reproduce
Running this command shows how the elasticsearch/logstash JDK versions are different from some reason:
Logs (if relevant)
No response