Did you recognise the boards in our ARMed post? Do you wonder what happened with them? This post is about the whole story.
The problems with the ARM packages
Occasionally we had customers and opsi users asking for ARM support of opsi. Most packages are compatible as they use Python code which doesn't depend on CPU architectures. Some however need to be compiled on the desired platform. The opsi-atftpd is one of the packages that have to be compiled and it didn't compile for ARM. The other one is the opsi-linux-bootimage. Since we use the Open Build Service to build packages on a desired distribution we also wanted the Build Service to build these packages. Unluckily the only supported ARM platform is the current stable openSUSE and the rolling release openSUSE. Other distributions like Debian or Ubuntu aren't supported at all. Therefore the only way to install opsi on an ARM powered device is to install the opsi-depotserver-expert package. This package made it possible to have an opsi depot on the ARM device, but the PXE boot wasn't available.
We'll make our own builds
At this years CeBit one of our customers encouraged us to use his support time to work on ARM support of opsi, including PXE boot of clients.
As said earlier the official Open Build Service can't build ARM packages for non openSUSE derivats. Luckily we have an own local instance. This local Build Service is also able to build ARM packages with some tweaks. However it needs an ARM based build bot. This is where the ARMed post comes in. One of the boards is an Odroid-XU4 whereby the other one is the more known Banana-Pi. These boards are also the ones our customer pushing the development uses as opsi depots. At first openSUSE was installed on the Odroid-XU4. Afterwards the Odroid-XU4 got the Build Service packages and was connected to the local instance. The new build bot was recognized and ready to build. At first the provied ARM distribution, openSUSE, was selected. It indeed did build fine. Unfortunately other distributions required more work
Right after the openSUSE ARM package success Ubuntu16.04 and Debian8 were selected to also build ARM packages.
The build didn't even start.
Our local Open Build Service instance proclaimed missing packages.
Those packages started from the very bottom.
This means that even basic system packages weren't available at all.
But one of the new fetaures of the Build Service is the download on demand of packages.
Easily spoken the repository needs to be expanded by a source of ARM packages for the desired distribution.
After finding official repositories for ARM packages they were added as download on demand repositories.
The logs indicated that these repositories are used but aren't working.
The solution for this problem was to remove the dists directory in the repository URL.
For example the ARM ubuntu repository URL is
http://ports.ubuntu.com/ubuntu-ports/dists/xenial/main/ but has to be
http://ports.ubuntu.com/ubuntu-ports/xenial/main/ for the download on demand feature.
Adding this simple change made the local Open Build Service start building the first ARM based packages.
Results of the hard work
The BananaPi was already prepared to become an opsi server. After the first Ubuntu 16.04 packages were build the BananaPi was opsified. A full opsi server was installed on the device. opsi on ARM works! Intial tests with Linux and Windows netboot installations were successfull. Our customer also confirmed it. opsi4ARM is real.