debianhf branch make rpi-all log gives error logs at very end of build process
adam-burns opened this issue · comments
A RPI3 arm64 Devuan Beowulf jenkins build host agent running make rpi-all to build armel for rpi0w (with full ccompile dependencies installed).
see full log at https://ci.free2air.net/job/rpi-img-builder/job/devuan-beowulf-rpi0-armel-image/20/console
everything seems fine until an issue right at the end of the build log:
Installing kernel. ...
Installing new kernel.
Unpacking raspberrypi-linux-image (5.10.27-1~rpi0+1) ...
Setting up raspberrypi-linux-headers (5.10.27-1~rpi0+1) ...
Compiling headers ...
Error in reading or end of file.
Error in reading or end of file.
...
followed by
arch/arm64/Makefile:25: ld does not support --fix-cortex-a53-843419; kernel may be susceptible to erratum
arch/arm64/Makefile:33: LSE atomics not supported by binutils
arch/arm64/Makefile:25: ld does not support --fix-cortex-a53-843419; kernel may be susceptible to erratum
arch/arm64/Makefile:33: LSE atomics not supported by binutils
gcc: error: unrecognized command line option '-mgeneral-regs-only'
make[1]: *** [scripts/Makefile.build:279: scripts/mod//empty.o] Error 1
make: *** [Makefile:1813: scripts/mod/] Error 2
dpkg: error processing package raspberrypi-linux-headers (--install):
installed raspberrypi-linux-headers package post-installation script subprocess returned error exit status 2
Setting up raspberrypi-linux-image (5.10.27-1~rpi0+1) ...
update-initramfs: Generating /boot/initrd.img-5.10.27
Creating initrd.gz.
Errors were encountered while processing:
raspberrypi-linux-headers
make[1]: *** [Makefile:327: devuanos] Error 1
which is odd, as the target build is armel, not arm64 ...
Any clues as to the root cause and/or hints to look for fix appreciated.
Thanks!
I see now.
That's not going to work as a build host for building arm. The cross compiling bit in the builder is meant for x86_64 based systems. In theory creating the img its self should be fine, but when it comes to compiling the kernel its going to produce ugly code and error out as it did for you above.
This is the reason I created a custom armel img for the Pi4 and use it to bake native kernels.
Thanks for the reply. The initial cross compilation of the kernel works beautifully.
Can you clarify why, or under what circumstances a second kernel compilation is required?
I don't understand. When has this ever worked? If someone knows of a way to accomplish this, I'm all ears.
I see now.
That's not going to work as a build host for building arm. The cross compiling bit in the builder is meant for x86_64 based systems. In theory creating the img its self should be fine, but when it comes to compiling the kernel its going to produce ugly code and error out as it did for you above.
This is the reason I created a custom armel img for the Pi4 and use it to bake native kernels.
Can you expand a bit on why cross compilation is not functional and indeed not easier to achieve on a more aligned and similar build host architecture (arm64 to armel) than (x86_64 to armel)?
If less problematic, then it's possible of course to switch to x86_64 build host agent, but just curious ...
Thanks!
Hmm. Well I appear to be wrong, as I just successfully pulled this off using the master branch. :) I'm thinking there must be a depends missing? Unfortunately what I believe it to be, is not available in Debian / Devuan.
Packages in question: gcc-8-multilib-arm-linux-gnueabi gcc-9-multilib-arm-linux-gnueabi gcc-10-multilib-arm-linux-gnueabi
I'll get back to you on my findings. Just leave this open till I figure it out.
Can you expand a bit on why cross compilation is not functional and indeed not easier to achieve on a more aligned and similar build host architecture (arm64 to armel) than (x86_64 to armel)?
If less problematic, then it's possible of course to switch to x86_64 build host agent, but just curious ...
Thanks!
To be absolutely honest with you, I'm not 100% sure why it behaves the way it does inside the chroot. For example, if you install the kernel directly to the board it appears to compile the headers just fine. Inside the chroot it blows up?!
Maybe something is leaking into or out of the chroot and confusing the compilation? Could be the headers are dirty due to compiling a 32bit kernel on a 64bit host? It's a mystery so far.
Its things like this that lead me to just build native most of the time.
I will be closing this until a solution presents its self. So far all my searching and testing hasn't amounted to anything.