/usr/share/kibana/bin/kibana-keystore: line 29: 374498 Illegal instruction (core dumped) NODE_OPTIONS="$KBN_NODE_OPTS $NODE_OPTIONS" NODE_ENV=production "${NODE}" "${DIR}/src/cli_keystore/dist" "$@"
chown: cannot access '/etc/kibana/kibana.keystore': No such file or directory
chmod: cannot access '/etc/kibana/kibana.keystore': No such file or directory
warning: %posttrans(kibana-8.14.3-1.aarch64) scriptlet failed, exit status 1
Kibana service status shows:
kibana.service: Failed with result 'core-dump'.
The same error is seen when using kibana 8.17 too. Has anyone else seen the same issue ?
Yes this is a completely fresh EC2 instance and the AMI is an in-house image with 2023.6.20250114 being the base. We won't be able to use the latest image.
Seems like everything except the image version is same from both the setup. Package name kibana-8.14.3-1.aarch64
Seems like everything except the image version is same
Not quire, I'm on docker, you're on EC2. I'm using M1 Mac, who-knows-what hardware is being used by AWS, but I dont think its a M1 Mac mini, ...
I dunno if it's a possibility, but could you test with a non-in-house image? If it works there, then ... something not right in the image would be my guess.
Also, just curious really, what does "cat /proc/cpuinfo | sort -u" get you?
# cat /proc/cpuinfo | sort -u
BogoMIPS : 2000.00
CPU architecture: 8
CPU implementer : 0x41
CPU part : 0xd4f
CPU revision : 1
CPU variant : 0x0
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 flagm2 frint svei8mm svebf16 i8mm bf16 dgh rng bti
processor : 0
processor : 1
Tried docker in my mac with amazon linux 2023 and was able to come past the kibana.keystore error. So it might be something with the in-house image.
I am using a c8g instance type, Arm-based AWS Graviton4 processor, that seems to satisfy AL2023 ARM requirements.
So, if you spin up a random c8g EC2 instance type on EC2, you can try just installing kibana there. If that works, it's something in the prep of your own ami. If not, then I'd open a case with AWS. Also perhaps your in-house image has some hardening or optimizing that, er, is not ideal here.
Just in passing, I'm sure the c8g instance type is great, but it's certainly not required for kibana. AWS market as:
"Amazon EC2 C8g instances are ideal for compute-intensive workloads, such as high performance computing (HPC), batch processing, gaming, video encoding, scientific modeling, distributed analytics, CPU-based machine learning (ML) inference, and ad serving"
I'm not sure that kibana is taking most advantage of that arch, though I'm happy to be corrected.
so I tried with the latest kibana release (8.17.2) and node there works OK, as does kibana in my very brief testing.
Maybe you were just unlucky with 8.14.3 build, in 8.17.3 its moved around a bit and is now at
# /usr/share/kibana/node/glibc-217/bin/node
Welcome to Node.js v20.18.2.
Type ".help" for more information.
# uname -a
Linux ip-172-31-10-19.eu-central-1.compute.internal 6.1.127-135.201.amzn2023.aarch64 #1 SMP Tue Jan 28 23:19:27 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux
I guess if you have Elastic support contract you might be able to get them to release a patch/fix for 8.14.3 ? Otherwise, an upgrade should resolve it.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.