Intel/AMD dependency?

[frankshad (David Earl)]

I notice that the version 7 install packages, eg elasticsearch-7.2.0-amd64.deb have amd64 on the end. Does this mean (apart from the JVM, which I understand) there is now something that is not pure Java and will not install on Raspberry Pi (ARM processor)? What would I have to do to install it on a Pi (versions up to 6.8 are fine)?

Just trying it on the off-chance predictably doesn't get beyond first base:

   dpkg: error processing archive elasticsearch-7.2.0-no-jdk-amd64.deb (--install):
   package architecture (amd64) does not match system (armhf)
   Errors were encountered while processing: elasticsearch-7.2.0-no-jdk-amd64.deb

Where can I get an armhf .deb?

[rjernst (Ryan Ernst)]

Unfortunately we do not currently support non x86-64 architectures. You would have to build your own deb file, by repackaging the existing deb file. Also note that the jna used by ES will not work on arm, nor will machine learning. Sorry!

[frankshad (David Earl)]

I was afraid you'd say that. The thing is, it has worked flawlessly on AMD since version 1 many years ago, so it's a huge blow to find myself cast adrift like this. Because it has worked so long and so straightforwardly, I wasn't even aware that it wasn't really supported.

The machine learning stuff isn't relevant to me, so if I had a way to separate that out that would be ok. I also don't use xpack currently, though I can envisage situations where I might want to use https cross-server.

JNA sounds more serious, but clearly it has all worked so far. How would I determine where this is needed, and is this something that could be straightforwardly compiled, or is it a huge environment to set up? Is this the binary dependency that was introduced to the core ES in v7? The Pi is running Raspbian, which is basically Debian with all the usual tools and compilers and so on, but just the scale of setting up a build environment is daunting.

In principle I could install or unpack on an Intel server and repackage, if I knew what dependencies I could just remove and which were critical.

My only other alternatives would be to

• abandon elasticsearch. A shame after the investment of time and effort I've put into it
• abandon RPi, but that's a shame too as it is a hugely economical way of doing things
• stick on ES6 for the foreseeable future; probably what I'll do. There's nothing in 7 I need, and some of the other breaking changes involve a lot of code change for me.
• wait for someone else to do the compilation and packaging, which I imagine will happen at some point

Incidentally for anyone who is interested, I found early on that openjs jre is about 30 times slower running ES on RPi than Oracle JRE. It makes almost no difference on a comparable Intel virtual server, dn with Oracle JRE on the Pi they are also comparable performance.

[frankshad (David Earl)]

So, I had a look at the .deb archive, and as far as I can see the only binary files in there which aren't JAR files) are the JRE. I was rather expecting to see something else.

Therefore, if I repackage it without the JRE (or ignore the fact it isn't a ARM binary), knowing I need a different JRE anyway, is there any reason to think it wouldn't continue to work as 6.8 does? (OK, there might be something in the JRE version dependency that would break it, but that's always been a risk).