Kali Linux 2022 with Odroid-XU4

[hbieganowski]

Hi!
Did anyone succeed in building Kali Linux 2022 image for Odroid XU4 using original Kali Linux site build scripts?
I tried building on Core2Duo with preinstalled Kali Linux (4GB of RAM, 80GB HDD, >12hrs) and on another machine (Core i7, VirtualBox image, 16GB/512GB SSD,>2hrs) but without positive results.
Errors in stage three according to assembler saying that processor is not supported in arm mode and cleaned tmp without generating an image (even when I tried running build script with "--desktop xfce --arch armhf" parameters).
Maybe someone has already prepared image for XU4 with this version of Kali Linux?

Best regards,
Hubert

[mctom]

Cześć,

Would you link the instructions that you followed? I couldn't find any ARM build instructions on Kali site.

I suspect that cross compiler requires some CPU extensions that are not present in Core 2 Duo CPU. In case of i7, perhaps that's the limitation of virtualbox image.

[hbieganowski]

Hi!
There is everything you need there

First look at this:
https://www.kali.org/docs/arm/odroid-xu3/

And then everything explained in README.MD at kali-arm GitLab site (of course using proper name for Odroid-XU3.sh):
https://gitlab.com/kalilinux/build-scripts/kali-arm

Building
These scripts are tested on Kali Linux arm64, x64 and x86 installations only (We recommend x64)
Make sure you run the ./common.d/build_deps.sh script before trying to build an image, as this installs all required dependencies
You will need at least 8GB of RAM or use SWAP file
An example workflow to build a Raspberry Pi 4 Kali Linux image would look like:

cd ~/
git clone https://gitlab.com/kalilinux/build-scripts/kali-arm
cd ~/kali-arm/
sudo ./common.d/build_deps.sh
sudo ./raspberry-pi.sh

Depending on your system hardware & network connectivity, will depend on how long it will take to build (4 core CPU, 8GB RAM, SSD inside a VM takes using a local repo about 100 minutes per script)
On x64 systems, after the script finishes running, you will have an image files located in ~/kali-arm/images/ called kali-linux-2021.3-rpi-armhf.img.xz
On x86 systems, as they do not have enough RAM to compress the image, after the script finishes running, you will have an image file located in ~/kali-arm/images/ called kali-linux-2021.3-rpi-armhf.img
Should you want to try and shrink the file to make it easier to distribute, you will need to use your own preferred compression.

[mctom]

You are aware Odroid XU4 is not ARM64 board, right?

EDIT: Never mind, I'll read that stuff more carefully first.

[hbieganowski]

I have my XU4 almost 7 years, so .... yeah, I know exactly what architecture it is

[mctom]

So you got the same errors on both machines, right? If that is the case then most likely their build files are borked.

I guess there is no chance to post the exact error message?

[hbieganowski]

I'll try logging error messages next time as the whole process is time consuming
The one common thing for both instalations is Kali Linux distribution. Full install didn't work for me on both machines (plus virtualbox, too) - after installing GRUB there is blank screen with blinking cursor and nothing happens (no XFCE gui desktop at all). Live version works properly and installs properly on disks (vbox) but maybe something is cut from this distro (even after update/upgrade).

[mctom]

Perhaps you have to prove your worthiness and hack into this thing prior first use.

Sorry, can't help you with any of that, I'm just a hardware monkey around here.

[zaber]

tried it today on a up2date kali on xeon w2223 system. googled a bit, found one source where people said it‘s the compilers fault and one should switch from gcc11 to gcc10. gonna try tomorrow again..

source here:
https://github.com/aircrack-ng/rtl8188eus/issues/153

[rockjcs]

Any updates or possible solutions? I am running into the same issue trying to run the build-script in a virtual Kali Linux using UTM on an M1 mac. I have tried gcc11 and gcc10 with the same results.

[lobosito]

So, I ran into this same problem (in the last week or two) when I started acting on the idea to try Kali on my XU4. Since there are no longer XU4 images on the Kali web site, I discovered the build script way to do this. I set up the build environment and followed the instructions (the same ones referenced earlier in this thread) on a fresh Kali VM (2022.4 - running on the latest VirtualBox 7 hypervisor on an up-to-date Windows 11 Professional host machine). It failed in similar fashion. This morning, I was able to spend some time researching the compiler message spit out at phase 3 (kernel build) where it failed.

I found a post over on lkml.org that suggests a change was made in the default flags for ARM compiler related to the hard float FPU (Odroid-XU4 is armhf architecture). It also shows that a patch was made and approved, but not sure to what scope it would apply. Here's the link - https://lkml.org/lkml/2021/8/10/70. This seems to be at least relevant in supporting the suggestion of trying gcc 10 in lieu of gcc 11. However, a previous post in this thread reports neither gcc 10 nor gcc 11 results in a successful build.

Digging a little more into the details, that patch for gcc 11 was submitted in August of 2021, adding '-msoft-float' to the KBUILD_CFLAGS in the Makefile being used in the Kernel Build System. Otherwise, an incorrect instruction set is selected which results in gcc barfing the way that we see in our attempts to build Kali for the XU4.

So, I will make a hypothesis with two possibilities based on what (I think) I have learned so far -

• 1. - The patch suggested actually addresses the problem successfully but is not included in the packages of the kernel build system that we are using with gcc 11 in Kali 2022.4 (does not explain why gcc 10 also fails)

• 2. - The patch is included in the kernel build system that we are using with gcc 11 but does not completely fix this problem

I hope to be able to spend some more time digging into this with replicating some of the testing that was done in the lkml.org post referenced above to see if I get the same message, and look if this flag is injected some other way by the Kali build scripts. I'll report again once I get around to doing this.