I use a lot of Raspberry Pi infrastructure with my homelab-centric GitLab CE installation. I have noticed that GitLab Runners have not worked on the oldest Raspberry Pis since version 16.8.0 (I have the error below along with system information). I have noticed that these runners seem to work on newer Raspberry Pi hardware (e.g., the issue is not present on my Raspberry Pi 3 Model B Rev 1.2 node which is “armv7l”). Is the illegal instruction error below just GitLab optimizing for newer Raspberry Pi hardware or is it something else? Thank you for your help with this. I did not find any other answers after a search, so I apologize if I missed anything.
$ sudo apt install gitlab-runner
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
docker-engine
The following NEW packages will be installed:
gitlab-runner
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 490 MB of archives.
After this operation, 532 MB of additional disk space will be used.
Get:1 https://packages.gitlab.com/runner/gitlab-runner/raspbian bullseye/main armhf gitlab-runner armhf 16.9.0-1 [490 MB]
Fetched 490 MB in 5min 56s (1,378 kB/s)
Selecting previously unselected package gitlab-runner.
(Reading database ... 51562 files and directories currently installed.)
Preparing to unpack .../gitlab-runner_16.9.0-1_armhf.deb ...
Unpacking gitlab-runner (16.9.0-1) ...
Setting up gitlab-runner (16.9.0-1) ...
GitLab Runner: detected user gitlab-runner
Illegal instruction
Illegal instruction
Illegal instruction
dpkg: error processing package gitlab-runner (--configure):
installed gitlab-runner package post-installation script subprocess returned error exit status 132
Errors were encountered while processing:
gitlab-runner
E: Sub-process /usr/bin/dpkg returned an error code (1)
$ uname -a
Linux pi1brev2a 6.1.21+ #1642 Mon Apr 3 17:19:14 BST 2023 armv6l GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye
$ cat /proc/device-tree/model
Raspberry Pi Model B Rev 2
I don’t have access to a Raspberry Pi in the first generation, but from research it seems to be the only generation, next Zero, supporting armv6, while 2 and newer support armv7.
Host architecture. Go runs on a variety of ARM systems and can emit code using a software library for floating-point math (SWFP) or using hardware floating-point instructions (HWFP). Toolchains defaulting to one mode or the other will necessarily differ. Like we saw with the dynamic linker earlier, the Go bootstrap process inspected the build system to make sure that the resulting toolchain worked on that system. For historical reasons, the rule was “assume SWFP unless the build is running on an ARM system with floating-point hardware”, with cross-compiled toolchains assuming SWFP. The vast majority of ARM systems today do have floating-point hardware, so this introduced an unnecessary difference between natively compiled and cross-compiled toolchains, and as a further wrinkle, Windows ARM builds always assumed HWFP, making the decision operating system-dependent. We changed the rule to be “assume HWFP unless the build is running on an ARM system without floating-point hardware”. This way, cross-compilation and builds on modern ARM systems produce identical toolchains.
These changes likely have an influence, while gox assumes the Go detected defaults.
Open an issue in the runner project to replace the gox build tool with something else that supports different target platforms (GOARM=armv6,armv7, etc), and build different packages to distinguish between armv6 and armv7. Also, mention the Go 1.21 changes, and link back to this forumtopic, and tag me there. Thanks!
@dnsmichi , this was an excellent response! Thank you for your guidance. I opted for Option 2. and have created GitLab Runner Issue 37383 per your specifications. If you need me to do anything further, then please let me know.
