Universalmediaserver: UMS 9.1.0 fails to start up on linux with arm processor

[felsen2011]

The startup script fails to check for arm devices.
It tries to start with the provided x86 binaries and aborts due to the incompatible java version.

[SubJunk]

@felsen2011 I'm not sure what you mean by "incompatible java version", can you explain?

[Nadahar]

@SubJunk All native code needs to be compiled for the target CPU architecture, which means that things are compiled either for x86, ARM, MIPS, PPC etc. These days most people use x86/x86-64 binaries, but hardware using other CPU types do exist, like for example the RPi.

When you bundle Java, you probably only bundle x86 versions, which aren't runnable on other architectures.

[felsen2011]

From the startup script:

if [ "$(uname -m | grep '64')" != "" ]; then
    if [ -f linux/jre-x64/bin/java ]; then
        JAVA="linux/jre-x64/bin/java"
    fi
else
    if [ -f linux/jre-x86/bin/java ]; then
        JAVA="linux/jre-x86/bin/java"
    fi
fi

it tries to run the shipped java just by distinguishing if the system type contains the string "64" or not and falling back to x86 if "64" is not present.
As it isn't checking for non x86 systems it tries to run the x86 java binary on an arm system which is of course failing.

[SubJunk]

I see. Do you have a suggestion for what to change it to? Maybe something like:

if [ "$(uname -m | grep '64')" != "" ]; then
    if [ -f linux/jre-x64/bin/java ]; then
        JAVA="linux/jre-x64/bin/java"
    fi
elif [ "$(uname -m | grep '86')" != "" ]; then
    if [ -f linux/jre-x86/bin/java ]; then
        JAVA="linux/jre-x86/bin/java"
    fi
fi

[felsen2011]

That would resolve my problem, but I don't think that these architecture strings are standardized.
Therefore it would be possible that a 64bit capable arm system also has a string containing "64" and would still fail.

You could grep for the whole arch string but afaik there are different strings for 64bit capable x86 systems so it might be that as a result some of these would not use the shipped binaries.

In principle I don't think that the uname arch string can be used safely to distinguish binary paths.

[SubJunk]

@felsen2011 can you let us know your uname?

[felsen2011]

It is now: armv7l
it used to be: armhf

[SubJunk]

There's a list of unames at https://en.wikipedia.org/wiki/Uname that suggests to me that change above would be safe. I'm happy for more robust options to be submitted but I'll go with this for now as it is better than what we currently have.

[SubJunk]

@felsen2011 would you please try running getconf LONG_BIT and let me know the output? I got that from https://askubuntu.com/questions/41332/how-do-i-check-if-i-have-a-32-bit-or-a-64-bit-os (though it should be noted the top-voted answer is for uname)

[felsen2011]

I don't have a script named getconf in my linux distro.

Here is the list for debian releases:

https://www.debian.org/releases/stretch/i386/ch02s01.html.en

The troubling thing is that everyone seems to define their uname response differently.
You might get lucky for some time by sorting "non x86" with a system fallback + "x86" and "x86-64/amd64" with provided binaries but the more linux users there are the more problems will appear.

Luckily most linux users nowadays are still proficient enough to fix this themselves ;)

[felsen2011]

Your current fix will fail for "arm64", "mips64" and "ppc64" though

[SubJunk]

Thanks for checking. Do you have any ideas for a more robust method?

[felsen2011]

Not really.
Thats the thing with the linux world.
All dependency issues are usually taken care of on the distribution level.
So you don't ship your preferred version of a dependency but the distribution ships a fitting version and takes care that all installed software is up to date and secure (most of the time).

Of course one could produce a *.deb or *.rpm package that has some jre version as minimum dependency to solve that on package level.

Usually if your distribution doesn't offer a specific software and there are no packages available then you as the user have to take care of everything yourself.

[SubJunk]

Maybe we can make the uname method more robust by checking for x64 instead of just 64

[felsen2011]

When you have a look into the Debian architecture list, they're naming it "amd64"

[Nadahar]

You'll probably find amd64 other places as well, it has historical reasons for who came up with what, and I think x64 is a later "collective name" often used but not entirely accurate.

In short, it's probably not possible to make something that works properly in all circumstances, maybe it would be better to document where to find this logic so that users can alter it themselves in "tricky cases".

[SubJunk]

Maybe it would be better to take a different approach on Linux and prefer to use the Java they have installed, and only attempt to use the bundled one if they don't have Java

Thoughts?

[felsen2011]

100% Pro
Is there a method to check for high enough java version?

Maybe also a third step that if the bundled java version isn't working to ask the user to install a working java version? Or even take this as second step?

[felsen2011]

java -showversion
openjdk version "1.8.0_232"

is JRE working the same way?