# Elasticseach 9.4.0 Won't Start on Nehalem CPU "does not support all the following CPU features"

**URL:** <https://discuss.elastic.co/t/elasticseach-9-4-0-wont-start-on-nehalem-cpu-does-not-support-all-the-following-cpu-features/386216>\
**Category:** Elasticsearch\
**Created:** [May 7, 2026, 2:35pm UTC](https://discuss.elastic.co/t/elasticseach-9-4-0-wont-start-on-nehalem-cpu-does-not-support-all-the-following-cpu-features/386216 "2026-05-07T14:35:49Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![amorrow](https://avatars.discourse-cdn.com/v4/letter/a/a5b964/32.png) [@amorrow](https://discuss.elastic.co/u/amorrow)\
**Post date:** [May 7, 2026, 2:35pm UTC](https://discuss.elastic.co/t/elasticseach-9-4-0-wont-start-on-nehalem-cpu-does-not-support-all-the-following-cpu-features/386216/1 "2026-05-07T14:35:49Z")

</div>

I got an unexpected surprise today when I tried to upgrade my Elasticsearch cluster from 9.3.4 to 9.4.0 on Ubuntu 24.04 LTS using deb packages. The service won't start.

```auto
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.

```

Granted, my cluster is built out of several old HP ProLiant DL380p Gen8 servers running Intel(R) Xeon(R) CPU E5-2620 (Nahalem) CPUs. But I read through the release notes for 9.4.0 and didn't see anything about changes to the supported CPU architectures. I wasn't sure if this was a compiling _oops_, or undocumented change to Elasticsearch's requirements

```auto
$ /lib64/ld-linux-x86-64.so.2 --help
Usage: /lib64/ld-linux-x86-64.so.2 [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked 'ld.so', the program interpreter for dynamically-linked
ELF programs. Usually, the program interpreter is invoked automatically
when a dynamically-linked executable is started.

You may invoke the program interpreter program directly from the command
line to load and run an ELF executable file; this is like executing that
file itself, but always uses the program interpreter you invoked,
instead of the program interpreter specified in the executable file you
run. Invoking the program interpreter directly provides access to
additional diagnostics, and changing the dynamic linker behavior without
setting environment variables (which would be inherited by subprocesses).

  --list list all dependencies and how they are resolved
  --verify verify that given object really is a dynamically linked
                        object we can handle
  --inhibit-cache Do not use /etc/ld.so.cache
  --library-path PATH use given PATH instead of content of the environment
                        variable LD_LIBRARY_PATH
  --glibc-hwcaps-prepend LIST
                        search glibc-hwcaps subdirectories in LIST
  --glibc-hwcaps-mask LIST
                        only search built-in subdirectories if in LIST
  --inhibit-rpath LIST ignore RUNPATH and RPATH information in object names
                        in LIST
  --audit LIST use objects named in LIST as auditors
  --preload LIST preload objects named in LIST
  --argv0 STRING set argv[0] to STRING before running
  --list-tunables list all tunables with minimum and maximum values
  --list-diagnostics list diagnostics information
  --help display this help and exit
  --version output version information and exit

This program interpreter self-identifies as: /lib64/ld-linux-x86-64.so.2

Shared library search path:
  (libraries located via /etc/ld.so.cache)
  /lib/x86_64-linux-gnu (system search path)
  /usr/lib/x86_64-linux-gnu (system search path)
  /lib (system search path)
  /usr/lib (system search path)

Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4
  x86-64-v3
  x86-64-v2 (supported, searched)

```

```auto
$ 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:

```

For comparison, I spun up a quick Hyper-V VM on a slightly newer Dell R730 server running Intel(R) Xeon(R) CPU E5-2670 v3 (Haswell) CPUs and Elasticsearch 9.4.0 started without issue.

```auto
/lib64/ld-linux-x86-64.so.2 --help
Usage: /lib64/ld-linux-x86-64.so.2 [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked 'ld.so', the program interpreter for dynamically-linked
ELF programs. Usually, the program interpreter is invoked automatically
when a dynamically-linked executable is started.

You may invoke the program interpreter program directly from the command
line to load and run an ELF executable file; this is like executing that
file itself, but always uses the program interpreter you invoked,
instead of the program interpreter specified in the executable file you
run. Invoking the program interpreter directly provides access to
additional diagnostics, and changing the dynamic linker behavior without
setting environment variables (which would be inherited by subprocesses).

  --list list all dependencies and how they are resolved
  --verify verify that given object really is a dynamically linked
                        object we can handle
  --inhibit-cache Do not use /etc/ld.so.cache
  --library-path PATH use given PATH instead of content of the environment
                        variable LD_LIBRARY_PATH
  --glibc-hwcaps-prepend LIST
                        search glibc-hwcaps subdirectories in LIST
  --glibc-hwcaps-mask LIST
                        only search built-in subdirectories if in LIST
  --inhibit-rpath LIST ignore RUNPATH and RPATH information in object names
                        in LIST
  --audit LIST use objects named in LIST as auditors
  --preload LIST preload objects named in LIST
  --argv0 STRING set argv[0] to STRING before running
  --list-tunables list all tunables with minimum and maximum values
  --list-diagnostics list diagnostics information
  --help display this help and exit
  --version output version information and exit

This program interpreter self-identifies as: /lib64/ld-linux-x86-64.so.2

Shared library search path:
  (libraries located via /etc/ld.so.cache)
  /lib/x86_64-linux-gnu (system search path)
  /usr/lib/x86_64-linux-gnu (system search path)
  /lib (system search path)
  /usr/lib (system search path)

Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)

```

```auto
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 63
model name : Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz
stepping : 2
microcode : 0xffffffff
cpu MHz : 1200.000
cache size : 30720 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 15
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid aperfmperf tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm pti ssbd ibrs ibpb stibp fsgsbase bmi1 avx2 smep bmi2 erms invpcid xsaveopt md_clear flush_l1d arch_capabilities
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_stale_data bhi its
bogomips : 4589.37
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:

```

Based on the comparing the flags, the Haswell CPU supports AVX2, BMI1, BMI2, FMA, and F16C while the Nahalem CPU doesn't.

---

<div class="post-metadata">

**Author:** ![amorrow](https://avatars.discourse-cdn.com/v4/letter/a/a5b964/32.png) [@amorrow](https://discuss.elastic.co/u/amorrow)\
**Post date:** [May 8, 2026, 11:55am UTC](https://discuss.elastic.co/t/elasticseach-9-4-0-wont-start-on-nehalem-cpu-does-not-support-all-the-following-cpu-features/386216/3 "2026-05-08T11:55:46Z")

</div>

A Github issue was opened May 5th for the same issue. It looks like the cause of the issue has been determined and a pull request exists to fix it. Don't know if there is anything that can be done to get 9.0.4 running, 🤞the pull request is merged for the next release.

> <https://github.com/elastic/elasticsearch/issues/148326>
>
> \### 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 --yes\` on my Debian machine, I upgraded my ELK stack from 9.3.4 to 9.4.0:
> 
> \`\`\`
> 00:01:31.910 Unpacking elasticsearch (9.4.0) over (9.3.4) ...
> 00:01:43.104 Unpacking kibana (9.4.0) over (9.3.4) ...
> 00:02:39.370 Unpacking logstash (1:9.4.0-1) over (1:9.3.4-1) ...
> 00:03:00.231 Unpacking metricbeat (9.4.0) over (9.3.4) ...
> \`\`\`
> 
> From that point kibana, logstash and metricbeat worked - while elasticsearch failed to start. \`systemctl status elasticsearch\` produced:
> 
> \`\`\`
> 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,\>
> Please rebuild the executable with an appropriate setting of the -march option.
> \`\`\`
> 
> From inspecting \`/proc/cpuinfo\` It seems my machine does support all of the above flags - BUT \`SSE3\` is listed as \`pni\` (\[Prescott New Instructions\](https://en.wikipedia.org/wiki/SSE3) - Intel's name for \`SSE3\`).
> 
> 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:
> 
> \`\`\`bash
> for prog in elasticsearch kibana logstash metricbeat; do
> echo "PROGRAM=${prog}"
> $(find /usr/share/${prog} -name java -type f -executable) --version 2\>/dev/null || $(find /usr/share/${prog} -name ${prog} -type f -executable) version
> echo
> done
> 
> PROGRAM=elasticsearch
> openjdk 26.0.1 2026-04-21
> OpenJDK Runtime Environment (build 26.0.1+8-34)
> OpenJDK 64-Bit Server VM (build 26.0.1+8-34, mixed mode, sharing)
> 
> PROGRAM=kibana
> {"log.level":"info","@timestamp":"2026-05-05T14:11:51.336Z","log.logger":"elastic-apm-node","ecs.version":"8.10.0","agentVersion":"4.15.0","env":{"pid":1781,"proctitle":"/usr/share/kibana/bin/../node/default/bin/node","os":"linux 6.12.85+deb13-amd64","arch":"x64","host":"tlog-server","timezone":"UTC+00","runtime":"Node.js v24.14.1"},"config":{"active":{"source":"start","value":true},"breakdownMetrics":{"source":"start","value":false},"captureBody":{"source":"start","value":"off","commonName":"capture\_body"},"captureHeaders":{"source":"start","value":false},"centralConfig":{"source":"start","value":false},"contextPropagationOnly":{"source":"start","value":true},"environment":{"source":"start","value":"production"},"globalLabels":{"source":"start","value":\[\["kibana\_uuid","6a99a60b-af9e-40e9-8d36-3a09771fce0a"\],\["git\_rev","b2e39752e03b56f48f51943214475ddba1f8e974"\]\],"sourceValue":{"kibana\_uuid":"6a99a60b-af9e-40e9-8d36-3a09771fce0a","git\_rev":"b2e39752e03b56f48f51943214475ddba1f8e974"}},"logLevel":{"source":"default","value":"info","commonName":"log\_level"},"metricsInterval":{"source":"start","value":120,"sourceValue":"120s"},"serverUrl":{"source":"start","value":"https://kibana-cloud-apm.apm.us-east-1.aws.found.io/","commonName":"server\_url"},"transactionSampleRate":{"source":"start","value":0.1,"commonName":"transaction\_sample\_rate"},"captureSpanStackTraces":{"source":"start","sourceValue":false},"secretToken":{"source":"start","value":"\[REDACTED\]","commonName":"secret\_token"},"serviceName":{"source":"start","value":"kibana","commonName":"service\_name"},"serviceVersion":{"source":"start","value":"9.4.0","commonName":"service\_version"}},"activationMethod":"require","message":"Elastic APM Node.js Agent v4.15.0"}
> Kibana should not be run as root. Use --allow-root to continue.
> 
> PROGRAM=logstash
> openjdk 21.0.10 2026-01-20 LTS
> OpenJDK Runtime Environment Temurin-21.0.10+7 (build 21.0.10+7-LTS)
> OpenJDK 64-Bit Server VM Temurin-21.0.10+7 (build 21.0.10+7-LTS, mixed mode, sharing)
> 
> PROGRAM=metricbeat
> metricbeat version 9.4.0 (amd64), libbeat 9.4.0 \[b988690b1bd5ae02f00c3facb413d4ee758563fe built 2026-04-30 13:28:43 +0000 UTC\] (FIPS-distribution: false)
> \`\`\`
> 
> \### Logs (if relevant)
> 
> \_No response\_

> <https://github.com/elastic/elasticsearch/pull/148542>
>
> 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). 
> 
> This PR pins \`-march=x86-64-v2\` on the x86\_64 task, matching Elasticsearch's de-facto JVM-tier floor. This is verified by running the rebuilt binary under \`qemu-x86\_64 -cpu IvyBridge-IBRS\`/\`Westmere\`/\`Nehalem\` (now starts) versus the shipping 9.4.0 binary (still errors). 
> 
> Closes #148326.

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [May 8, 2026, 2:56pm UTC](https://discuss.elastic.co/t/elasticseach-9-4-0-wont-start-on-nehalem-cpu-does-not-support-all-the-following-cpu-features/386216/4 "2026-05-08T14:56:51Z")

</div>

> [@amorrow](#):
>
> Don't know if there is anything that can be done to get 9.0.4 running

For info, a workaround is suggested in the pull request page (added minutes ago).

Worth a try for those impacted.

---

<div class="post-metadata">

**Author:** ![amorrow](https://avatars.discourse-cdn.com/v4/letter/a/a5b964/32.png) [@amorrow](https://discuss.elastic.co/u/amorrow)\
**Post date:** [May 8, 2026, 5:49pm UTC](https://discuss.elastic.co/t/elasticseach-9-4-0-wont-start-on-nehalem-cpu-does-not-support-all-the-following-cpu-features/386216/5 "2026-05-08T17:49:49Z")

</div>

The fix has been merged. Here are some details from the tracked issue in Github:

> The fix should go out in the `9.4.1` patch (and is included in the `9.5.0` release): [#148542](https://github.com/elastic/elasticsearch/pull/148542)
> 
> Until the patched release ships, you can force the launcher to take the JVM fallback path:
> 
> ```auto
> sudo systemctl stop elasticsearch
> sudo chmod -x /usr/share/elasticsearch/lib/tools/server-launcher/server-launcher
> sudo systemctl start elasticsearch
> 
> ```

> <https://github.com/elastic/elasticsearch/issues/148326#issuecomment-4407858531>
>
> \### 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 --yes\` on my Debian machine, I upgraded my ELK stack from 9.3.4 to 9.4.0:
> 
> \`\`\`
> 00:01:31.910 Unpacking elasticsearch (9.4.0) over (9.3.4) ...
> 00:01:43.104 Unpacking kibana (9.4.0) over (9.3.4) ...
> 00:02:39.370 Unpacking logstash (1:9.4.0-1) over (1:9.3.4-1) ...
> 00:03:00.231 Unpacking metricbeat (9.4.0) over (9.3.4) ...
> \`\`\`
> 
> From that point kibana, logstash and metricbeat worked - while elasticsearch failed to start. \`systemctl status elasticsearch\` produced:
> 
> \`\`\`
> 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,\>
> Please rebuild the executable with an appropriate setting of the -march option.
> \`\`\`
> 
> From inspecting \`/proc/cpuinfo\` It seems my machine does support all of the above flags - BUT \`SSE3\` is listed as \`pni\` (\[Prescott New Instructions\](https://en.wikipedia.org/wiki/SSE3) - Intel's name for \`SSE3\`).
> 
> 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:
> 
> \`\`\`bash
> for prog in elasticsearch kibana logstash metricbeat; do
> echo "PROGRAM=${prog}"
> $(find /usr/share/${prog} -name java -type f -executable) --version 2\>/dev/null || $(find /usr/share/${prog} -name ${prog} -type f -executable) version
> echo
> done
> 
> PROGRAM=elasticsearch
> openjdk 26.0.1 2026-04-21
> OpenJDK Runtime Environment (build 26.0.1+8-34)
> OpenJDK 64-Bit Server VM (build 26.0.1+8-34, mixed mode, sharing)
> 
> PROGRAM=kibana
> {"log.level":"info","@timestamp":"2026-05-05T14:11:51.336Z","log.logger":"elastic-apm-node","ecs.version":"8.10.0","agentVersion":"4.15.0","env":{"pid":1781,"proctitle":"/usr/share/kibana/bin/../node/default/bin/node","os":"linux 6.12.85+deb13-amd64","arch":"x64","host":"tlog-server","timezone":"UTC+00","runtime":"Node.js v24.14.1"},"config":{"active":{"source":"start","value":true},"breakdownMetrics":{"source":"start","value":false},"captureBody":{"source":"start","value":"off","commonName":"capture\_body"},"captureHeaders":{"source":"start","value":false},"centralConfig":{"source":"start","value":false},"contextPropagationOnly":{"source":"start","value":true},"environment":{"source":"start","value":"production"},"globalLabels":{"source":"start","value":\[\["kibana\_uuid","6a99a60b-af9e-40e9-8d36-3a09771fce0a"\],\["git\_rev","b2e39752e03b56f48f51943214475ddba1f8e974"\]\],"sourceValue":{"kibana\_uuid":"6a99a60b-af9e-40e9-8d36-3a09771fce0a","git\_rev":"b2e39752e03b56f48f51943214475ddba1f8e974"}},"logLevel":{"source":"default","value":"info","commonName":"log\_level"},"metricsInterval":{"source":"start","value":120,"sourceValue":"120s"},"serverUrl":{"source":"start","value":"https://kibana-cloud-apm.apm.us-east-1.aws.found.io/","commonName":"server\_url"},"transactionSampleRate":{"source":"start","value":0.1,"commonName":"transaction\_sample\_rate"},"captureSpanStackTraces":{"source":"start","sourceValue":false},"secretToken":{"source":"start","value":"\[REDACTED\]","commonName":"secret\_token"},"serviceName":{"source":"start","value":"kibana","commonName":"service\_name"},"serviceVersion":{"source":"start","value":"9.4.0","commonName":"service\_version"}},"activationMethod":"require","message":"Elastic APM Node.js Agent v4.15.0"}
> Kibana should not be run as root. Use --allow-root to continue.
> 
> PROGRAM=logstash
> openjdk 21.0.10 2026-01-20 LTS
> OpenJDK Runtime Environment Temurin-21.0.10+7 (build 21.0.10+7-LTS)
> OpenJDK 64-Bit Server VM Temurin-21.0.10+7 (build 21.0.10+7-LTS, mixed mode, sharing)
> 
> PROGRAM=metricbeat
> metricbeat version 9.4.0 (amd64), libbeat 9.4.0 \[b988690b1bd5ae02f00c3facb413d4ee758563fe built 2026-04-30 13:28:43 +0000 UTC\] (FIPS-distribution: false)
> \`\`\`
> 
> \### Logs (if relevant)
> 
> \_No response\_

---

<div class="post-metadata">

**Author:** ![yogesh119905](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/yogesh119905/32/145298_2.png) [@yogesh119905](https://discuss.elastic.co/u/yogesh119905)\
**Post date:** [May 14, 2026, 8:11am UTC](https://discuss.elastic.co/t/elasticseach-9-4-0-wont-start-on-nehalem-cpu-does-not-support-all-the-following-cpu-features/386216/6 "2026-05-14T08:11:47Z")

</div>

I have tested the latest version 9.4.1 and still getting same error.

root@ubuntu-elasticsearch:~# apt list --installed | grep -i elastic

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

**elasticsearch/stable,now 9.4.1 amd64 [installed]**  
root@ubuntu-elasticsearch:~# systemctl status elasticsearch.service  
× elasticsearch.service - Elasticsearch  
Loaded: loaded (/usr/lib/systemd/system/elasticsearch.service; disabled; preset: enabled)  
Drop-In: /etc/systemd/system/elasticsearch.service.d  
└─custom.conf  
Active: failed (Result: exit-code) since Thu 2026-05-14 08:01:24 UTC; 13s ago  
Docs: [https://www.elastic.co](https://www.elastic.co)  
Process: 8234 ExecStart=/usr/share/elasticsearch/bin/systemd-entrypoint -p ${PID\_DIR}/elasticsearch.pid --quiet (code=exited, status=1/FAILURE)  
Main PID: 8234 (code=exited, status=1/FAILURE)  
CPU: 38ms

May 14 08:01:24 ubuntu-elasticsearch systemd[1]: Starting elasticsearch.service - Elasticsearch...  
May 14 08:01:24 ubuntu-elasticsearch systemd-entrypoint[8234]: The current machine does not support all of the following CPU features that are required by the image: [CX8, CMOV, FXSR, MMX, \>  
May 14 08:01:24 ubuntu-elasticsearch systemd-entrypoint[8234]: Please rebuild the executable with an appropriate setting of the -march option.  
May 14 08:01:24 ubuntu-elasticsearch systemd[1]: elasticsearch.service: Main process exited, code=exited, status=1/FAILURE  
May 14 08:01:24 ubuntu-elasticsearch systemd[1]: elasticsearch.service: Failed with result 'exit-code'.  
**May 14 08:01:24 ubuntu-elasticsearch systemd[1]: Failed to start elasticsearch.service - Elasticsearch.**  
lines 1-16/16 (END)client\_loop: send disconnect: Broken pipe

---

<div class="post-metadata">

**Author:** ![amorrow](https://avatars.discourse-cdn.com/v4/letter/a/a5b964/32.png) [@amorrow](https://discuss.elastic.co/u/amorrow)\
**Post date:** [May 14, 2026, 12:52pm UTC](https://discuss.elastic.co/t/elasticseach-9-4-0-wont-start-on-nehalem-cpu-does-not-support-all-the-following-cpu-features/386216/7 "2026-05-14T12:52:43Z")

</div>

Sounds like the pull request didn't make it time for the 9.4.1 release. The workaround of removing the executable flag from server-launcher or deleting it altogether should still work.

[https://github.com/elastic/elasticsearch/issues/148326#issuecomment-4438224134](https://github.com/elastic/elasticsearch/issues/148326#issuecomment-4438224134)

> The fix should go out in the `9.4.1` patch (and is included in the `9.5.0` release): [#148542](https://github.com/elastic/elasticsearch/pull/148542)
> 
> Looks like the fix didn't make it into the 9.4.1 release. It landed after the 9.4.1 release tag: [Comparing v9.4.0...v9.4.1 · elastic/elasticsearch · GitHub](https://github.com/elastic/elasticsearch/compare/v9.4.0...v9.4.1) , [Comparing v9.4.1...9.4 · elastic/elasticsearch · GitHub](https://github.com/elastic/elasticsearch/compare/v9.4.1...9.4)

---

<div class="post-metadata">

**Author:** ![yogesh119905](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/yogesh119905/32/145298_2.png) [@yogesh119905](https://discuss.elastic.co/u/yogesh119905)\
**Post date:** [May 15, 2026, 8:40am UTC](https://discuss.elastic.co/t/elasticseach-9-4-0-wont-start-on-nehalem-cpu-does-not-support-all-the-following-cpu-features/386216/8 "2026-05-15T08:40:44Z")

</div>

Who can confirm whether this issue will be fixed in the next release?

---

<div class="post-metadata">

**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\
**Post date:** [May 15, 2026, 8:48am UTC](https://discuss.elastic.co/t/elasticseach-9-4-0-wont-start-on-nehalem-cpu-does-not-support-all-the-following-cpu-features/386216/9 "2026-05-15T08:48:36Z")

</div>

It's very likely, the patch is merged into the right branch now, but we cannot totally confirm it for definite until the release goes out. In the (unlikely) event of finding a problem with this patch it might still be reverted.

---

<div class="post-metadata">

**Author:** ![yogesh119905](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/yogesh119905/32/145298_2.png) [@yogesh119905](https://discuss.elastic.co/u/yogesh119905)\
**Post date:** [May 19, 2026, 6:03am UTC](https://discuss.elastic.co/t/elasticseach-9-4-0-wont-start-on-nehalem-cpu-does-not-support-all-the-following-cpu-features/386216/10 "2026-05-19T06:03:53Z")

</div>

Currently, our virtual environment does not support AVX/AVX2, and we have also downgraded the Elasticsearch version. Could you please confirm whether this issue will be resolved in a future release, or if all future Elasticsearch packages will require CPUs with AVX support? If the latter is the case, migrating the VM to hardware that supports AVX would be mandatory.

---

<div class="post-metadata">

**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\
**Post date:** [May 19, 2026, 7:23am UTC](https://discuss.elastic.co/t/elasticseach-9-4-0-wont-start-on-nehalem-cpu-does-not-support-all-the-following-cpu-features/386216/11 "2026-05-19T07:23:22Z")

</div>

We expect that 9.4.2 will drop the stricter requirements on CPU features that were inadvertently added in 9.4.0, but to reiterate my earlier message: we cannot totally confirm that this patch will land in 9.4.2 until the release goes out.

I also believe that we do not have any test environments running these feature-light CPUs - if we did, we would have caught the issue before release. Thus we can't guarantee that there's something else in your environment that will prevent an upgrade. You will need to re-run your upgrade tests when 9.4.2 is released to confirm its compatibility with your environment.

---

<div class="post-metadata">

**Author:** ![yogesh119905](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/yogesh119905/32/145298_2.png) [@yogesh119905](https://discuss.elastic.co/u/yogesh119905)\
**Post date:** [May 19, 2026, 7:28am UTC](https://discuss.elastic.co/t/elasticseach-9-4-0-wont-start-on-nehalem-cpu-does-not-support-all-the-following-cpu-features/386216/12 "2026-05-19T07:28:17Z")

</div>

Thanks David for clean explanations.

---

<div class="post-metadata">

**Author:** ![yogesh119905](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/yogesh119905/32/145298_2.png) [@yogesh119905](https://discuss.elastic.co/u/yogesh119905)\
**Post date:** [June 2, 2026, 4:26pm UTC](https://discuss.elastic.co/t/elasticseach-9-4-0-wont-start-on-nehalem-cpu-does-not-support-all-the-following-cpu-features/386216/13 "2026-06-02T16:26:46Z")

</div>

The issue has been resolved in the latest release, version 9.4.2.

---

<div class="post-metadata">

**Author:** ![steigr](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/steigr/32/147828_2.png) [@steigr](https://discuss.elastic.co/u/steigr)\
**Post date:** [July 8, 2026, 3:08pm UTC](https://discuss.elastic.co/t/elasticseach-9-4-0-wont-start-on-nehalem-cpu-does-not-support-all-the-following-cpu-features/386216/14 "2026-07-08T15:08:12Z")

</div>

9.4.3 re-introduced this because base-image is now UBI 10.2:

> <https://github.com/elastic/beats/pull/51377>
>
> \## Proposed commit message
> 
> 
> A previous commit changed the UBI images tag to …10.2, but the repository
> was kept to ubi9. Update the image so the latest version will be pulled.
> 
> 
> \## Checklist
> 
> 
> 
> \- \[x\] My code follows the style guidelines of this project
> \- \[\] I have commented my code, particularly in hard-to-understand areas
> \- \[\] I have made corresponding changes to the documentation
> \- \[\] I have made corresponding change to the default configuration files
> \- \[\] I have added tests that prove my fix is effective or that my feature works. Where relevant, I have used the \[\`stresstest.sh\`\](https://github.com/elastic/beats/blob/main/script/stresstest.sh) script to run them under stress conditions and race detector to verify their stability.
> \- \[\] I have added an entry in \`./changelog/fragments\` using the \[changelog tool\](https://github.com/elastic/elastic-agent-changelog-tool/blob/main/docs/usage.md).
> 
> \## Disruptive User Impact
> 
> 
> 
> \## How to test this PR locally
> 
> 
> 
> \## Related issues
> 
> 
> \- https://github.com/elastic/beats/pull/51081
> \- Based on: https://github.com/elastic/beats/pull/48661
> \- Elastic Agent migration: https://github.com/elastic/elastic-agent/pull/12573
> 
> \## Use cases
> 
> 
> 
> \## Screenshots
> 
> 
> 
> \## Logs