DietPi-Software | Cuberite: "Illegal instruction" on ARMv6 RPi

[CactiChameleon9]

ADMIN EDIT

Workaround

cd /tmp
wget https://dietpi.com/downloads/binaries/buster/cuberite_armv6l.7z
7zr -y x cuberite_armv6l.7z -o/mnt/dietpi_userdata/cuberite/
chmod +x /mnt/dietpi_userdata/cuberite/Cuberite

---

Creating a bug report/issue

Installing cuberite fails.
There is an error in the terminal:
mv: cannot stat '/mnt/dietpi_userdata/cubrite/Server/*': No such file or directory
rm: cannot remove '/mnt/dietpi_userdata/cubrite/Server': No such file or directory - this does not happen if created before starting

Required Information

G_DIETPI_VERSION_CORE=6
G_DIETPI_VERSION_SUB=31
G_DIETPI_VERSION_RC=2
G_GITBRANCH='master'
G_GITOWNER='MichaIng'

buster

Linux DietPiZero 4.19.118+ #1311 Mon Apr 27 14:16:15 BST 2020 armv6l GNU/Linux

RPi Zero W (armv6l)

Just a USB cable plugged into a laptop

Kingston CANVAS Select Plus 32GB

Additional Information (if applicable)

Software: cuberite minecraft server
This was done on a fresh install

Steps to reproduce

dietpi-software install 52

(to confirm failure)
systemctl start cuberic

Expected behaviour

The install should work and the server should work

Actual behaviour

The error mention appears in the terminal, but is ignored and dietpi thinks it is installed correctly
The systemctl service also fails (probably due to error)

Extra details

May be solved by making there Server folder before install starts (does not work manually as I think it is removed) - /mnt/dietpi_userdata/cubrite/ is there but the Server folder is not

[Joulinar]

Hi,

many thanks for your report. Indeed these 2 lines are there during installation. However the whole installation is working and cuberite is up and running after reboot

root@DietPi3:~# systemctl status cuberite.service
● cuberite.service - Cuberite Server (DietPi)
   Loaded: loaded (/etc/systemd/system/cuberite.service; disabled; vendor preset: enabled)
   Active: active (running) since Fri 2020-07-10 23:35:35 CEST; 1min 29s ago
  Process: 429 ExecStart=/mnt/dietpi_userdata/cubrite/Cuberite --service (code=exited, status=0/SUCCESS)
 Main PID: 430 (Cuberite)
    Tasks: 23 (limit: 2319)
   Memory: 275.0M
   CGroup: /system.slice/cuberite.service
           └─430 /mnt/dietpi_userdata/cubrite/Cuberite --service

Jul 10 23:35:35 DietPi3 systemd[1]: Starting Cuberite Server (DietPi)...
Jul 10 23:35:35 DietPi3 system

Purpose of these 2 lines is to move everything from Server folder into cubrite base directory. And to remove Server folder afterwards. I checked the *tar.gz file we are downloading from cuberite and it looks this step is not needed anymore as everything is already present within base directory.

[MichaIng]

Many thanks for your report.

This install step was required since in the past the Cuberite download archive contained a "Server" directory which contained the actual binaries. So when extracting the archive, we need to move the contained data where we want it any remove the obsolete dir. However now this is not the case anymore, the archive does not contain a parent directory anymore, so this install step is now obsolete in I hence just removed it: https://github.com/MichaIng/DietPi/commit/c68af7280856e6682ec31949400b778b376c8a16

I tested it as well, obviously concurrently to @Joulinar and also here it works fine. If the service fails in your case, it is not related to the two error messages. Please paste the following output for investigation:

journalctl -u cuberite

[Joulinar]

haha, I just was going to adjust dietpi-software. But you are faster than light 😉

[CactiChameleon9]

Here is the result of the command:

-- Logs begin at Sat 2020-07-11 06:17:01 BST, end at Sat 2020-07-11 07:14:36 BST
. --
Jul 11 07:13:43 DietPiZero systemd[1]: Starting Cuberite Server (DietPi)...
Jul 11 07:13:43 DietPiZero systemd[1]: cuberite.service:
 Control process exited, code=killed, status=4/ILL
Jul 11 07:13:43 DietPiZero systemd[1]: cuberite.service:
 Failed with result 'signal'.
Jul 11 07:13:43 DietPiZero systemd[1]: Failed to start C
uberite Server (DietPi).

[MichaIng]

Ah it logs to file, can you please paste the output of:

tail -20 /mnt/dietpi_userdata/cubrite/logs/*

[CactiChameleon9]

Does not exist

[CactiChameleon9]

There is no logs folder

[CactiChameleon9]

Running the executable give "Illegal instruction"

[MichaIng]

Okay, hmm you're on ARMv6. I can only hope that they did not accidentally build the "raspi-armhf" binary for ARMv7 only... Last builds failed: https://builds.cuberite.org/

Could you try it with a much older binary:

cd /tmp
wget https://builds.cuberite.org/job/Cuberite%20Linux%20raspi-armhf%20Master/1000/artifact/Cuberite.tar.gz
rm -R /mnt/dietpi_userdata/cuberite/{,.[^.],.??}*
tar xf Cuberite.tar.gz -C /mnt/dietpi_userdata/cuberite/

[CactiChameleon9]

I'm self compiling now... ill see if that works

[MichaIng]

I was just testing the armhf build on ARMv8, but /lib/ld-linux-armhf.so.3 is linked. If compiling works fine actually we could do that in general to provide Cuberite for ARMv8. Or we can convince the devs to provide them from now on with upcoming Raspberry Pi OS 64-bit as argument.

However lets get it running on your ARMv6 first of all.

---

Testing on my RPi2 now, not sure if I did that tomorrow already... was late... ... works fine, so indeed ARMv6-specific, or board-specific but based on the error I doubt that.

[CactiChameleon9]

Cuberite does run self compiled.. even if you just replace the binary Cuberite, the rest of the files are fine

[MichaIng]

I reported the issue here: https://github.com/cuberite/cuberite/issues/4774
Would be great if you could involve, if required, however based on error message and you solution the underlying issue looks pretty clear to me and it might be related to their latest raspi-armhf builds fail.

---

Would you mind to provide your binary so that we can use it as workaround until the official build has been fixed? In theory you could give it an jpg file ending or such and upload here into GitHub chat 😄.

[CactiChameleon9]

Here is the binary: (not actually a zip... just renamed)
Cuberite.zip

Hope this helps

[MichaIng]

Many thanks, I uploaded it already and, given there is no fixed official build until next DietPi release, will add it as workaround for ARMv6+Buster installs: https://dietpi.com/downloads/binaries/buster/cuberite_armv6l.7z

cd /tmp
wget https://dietpi.com/downloads/binaries/buster/cuberite_armv6l.7z
7zr -y x cuberite_armv6l.7z -o/mnt/dietpi_userdata/cubrite/
chmod +x /mnt/dietpi_userdata/cubrite/Cuberite

[MichaIng]

Indeed we can switch to the compiling script as well, assure that all build tools/deps are installed first. Its just good to inform users in the first place, that it'll take a while then. @CactiChameleon9 how long did it take on your RPi Zero?

[CactiChameleon9]

Oh gosh... I cannot remember.. over 2 hours I think. May be closer to 3

[MichaIng]

Okay that is indeed very long 😄. Probably first we go with the compiled binary and when there is no fixed build from Cuberite side until a DietPi release later, we switch to self-compiling. At least this allows install on ARMv8 (currently not supported) then as well with the same method.

In theory we could provide own builds, but for cross-compiling we have the same issues as Cuberite guys and otherwise I need to compile on RPi, which has the same time-cost issue, and due to their regular release schedule it is time-consuming to keep up.

[CactiChameleon9]

Yeah... I started with my slightly modified fork (no version check) at 5-5:30 and it is currently 7:30 and I am at 70%.. I did not know ARMv8 is not currently supported, it will be good to support that.

It cannot be that hard to make compiling Pi(s), balenaOS may make it easy if anyone is good with docker, and would allow easy reinstalling since the code is on another machine (normal x86 computer) and then deployed to the Pi. You could set up a git repo for it directly (or some other upload method) and just let the Pi(s) download the source code, make, upload, and repeat (with a massive sleep inbetween).

[MichaIng]

and just let the Pi(s) download the source code, make, upload, and repeat (with a massive sleep inbetween).

Yes that is what I would do, with a script but manually executed currently, also as I want/need to review each time to assure there was no change required. It is a bid easier to do automated builds for the creators, since they know when the build system or dependencies or such change, but when we do it, we still need to assure that all is still working as expected. Still, some automation, easy online trigger for build refreshes, without manual login + online viewable build logs is something I already did for our new WIP documentation and I aim to implement this for our software builds as well, which will make things definitely easier.

[MichaIng]

Just to mention, raspi-armhf builds are successfully updated again, however that does not mean that armv6l support is included.

[CactiChameleon9]

Just wanted to let you know that I built cuberite on the pi zero again, so this should be a more modern version: https://transfer.sh/a5ARY/Cuberite

also shouldn't
7zr -y x cuberite_armv6l.7z -o/mnt/dietpi_userdata/cuberite/
be
7zr -y x cuberite_armv6l.7z -o /mnt/dietpi_userdata/cuberite/

[MichaIng]

also shouldn't
7zr -y x cuberite_armv6l.7z -o/mnt/dietpi_userdata/cuberite/
be
7zr -y x cuberite_armv6l.7z -o /mnt/dietpi_userdata/cuberite/

The free space is optional here, when skipping it it's easier when the output directory is fully optional, the -o must be skipped then together with the path string.

[CactiChameleon9]

Okay

[MichaIng]

Workaround added: https://github.com/MichaIng/DietPi/commit/1dfaf52f655ac7cbde018b7694f1163d37f4d886
Changelog: https://github.com/MichaIng/DietPi/commit/81890f3ef20c35d586ae861ec48fb770f51f4c94

Lol, I recognised a typo in our install directory, cubrite instead of cuberite. I'll leave it like that for this release but add a change for next release to rename this directory. Simply not nice to have it misspelled 😄.

[MichaIng]

Rename is done with next update: https://github.com/MichaIng/DietPi/pull/3795
Since official ARMv6 binaries will likely not come back, we'll probably compile own binaries, and add ARMv8 binaries then as well, but this is a different topic, so I'll mark this here as closed.