I am new to Kali. I came to it for a current Linux distro for my old Cubieboards.
From the Gitlab kali-arm Build-scripts I ran build_deps.sh, only to find out that only Debian is supported to build an image.
I have NEVER had a Debian system. I am CentOS/Fedora with one production Ubuntu system. Sigh.
Can anyone point me to a Cubieboard2 and/or Cubietruck image to use? Or help me build them?
I really want to continue to use my Cubieboards for a number more years.
Thanks!
I just had a thought…
Could I boot up one of my Lenovo x140 notebooks with a Debian Live CD and do the build on that?
Worth a shot.
Let us know how you get on.
Some headway. Built a Debian 12 live USB and booted up. Mounted my notebook harddrive to put all the data there.
The git clone worked fine onto a dir on the harddrive. After I fixed some permissions.
but sudo ./common.d/build_deps.sh failed with the following:
Unpacking uuid-dev:amd64 (2.38.1-5+deb12u3) …
Selecting previously unselected package vboot-kernel-utils.
Preparing to unpack …/161-vboot-kernel-utils_0~R106-15054.B-1_amd64.deb …
Unpacking vboot-kernel-utils (0~R106-15054.B-1) …
Selecting previously unselected package vboot-utils.
Preparing to unpack …/162-vboot-utils_0~R106-15054.B-1_amd64.deb …
Unpacking vboot-utils (0~R106-15054.B-1) …
Errors were encountered while processing:
/tmp/apt-dpkg-install-IUBoah/137-libstdc+±arm-none-eabi-newlib_15%3a12.2.rel1-1+23_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
I decided to try to continue:
sudo ./cubieboard2.sh
Error: missing kali-archive-keyring
Please download the latest version from
Index of /kali/pool/main/k/kali-archive-keyring/
and install it manually.
Cleaning up
Un-mount anything that may be mounted
Cleaning up the temporary build files: /mnt/disk/kali/kali-arm/base/cubieboard2-xfce-armhf/working
Cleaning up the temporary build files: /mnt/disk/kali/kali-arm/base/cubieboard2-xfce-armhf
Done
Huh? Maybe because of that earlier failure? I did go to
and there are 7 files there. Which to install?
I did shutdown Debian Live, so I HOPE what I installed is still there.
Please let me know how to recover from the above error.
This is the most recent key;
OK. I will try that tomorrow. It is a bit of a process to get that live image running. I am hoping that since I have it on a USB stick, changes like this stay between boots.
But what about that first item running build_deps.sh with error code (1)?
There is a guide here;
I am very familiar with what that page says. I worked on Fedora27 for the Cubieboard, and the Redhat developer and I worked out the uboot and how to get the whole file system on the HD; back early '14. I have been running Centos6 on 6 of them since and well past EOL.
No, my problem is the step BEFORE the cubieboard build. That of creating the KaliLinux enviroment the build_deps.sh that ended prematurely with an error.
Oops. We started CentOS6, but my “tower” of 6 Cubieboar2 are running:
CentOS Linux release 7.6.1810 (AltArch)
Still EOL by quite some time.
And finally for this evening…
If someone can point me to an already built:
kali-linux-2025.1-cubieboard2-armhf.img.xz
I would really like that; save me a bit of grief. Or even/also for the cubietruck…
Still errors.
On booting Live Ubuntu, I first installed the keyring.
then tried the building of cubieboard2. And quickly learned that the deps I installed the other day did not survive across reboots of the Live CD. So I redid the build_deps.sh and it ended at the same point, but it was step 161, rather 162:
Preparing to unpack …/161-vboot-utils_0~R106-15054.B-1_amd64.deb …
Unpacking vboot-utils (0~R106-15054.B-1) …
Errors were encountered while processing:
/tmp/apt-dpkg-install-sVDAqz/136-libstdc+±arm-none-eabi-newlib_15%3a12.2.rel1-1+23_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
OK. Now that I had the keyring I tried the cubieboard build and it failed:
sudo ./cubieboard2.sh
Compilation info
Hardware model: CubieBoard2 (32-bit)
Architecture: armhf
OS build: kali-rolling 2025.1c
Desktop manager: xfce
The base_dir thinks it is: /mnt/stick/kali/kali-arm/base/cubieboard2-xfce-armhf
Load common file: packages
Selecting packages…
1/18: debootstrap kali-rolling Index of /
I: automatically chosen mode: root
W: cannot find update-binfmts
E: armhf can neither be executed natively nor via qemu user emulation with binfmt_misc
Cleaning up
Un-mount anything that may be mounted
Cleaning up the temporary build files: /mnt/stick/kali/kali-arm/base/cubieboard2-xfce-armhf/working
Cleaning up the temporary build files: /mnt/stick/kali/kali-arm/base/cubieboard2-xfce-armhf
Done
=============
So I suspect that that dep failure is important and I am stuck.
I MIGHT be able to find an old x120e to install Debian on instead of trying from the Live CD. But perhaps this is a bigger problem with the deps?
Can someone please look at this and I might think there are people here that have build other board images and could build a Cubieboard image?
thanks for any help.
I shall have a new ARM based laptop in a few days and I’ll see if I have more success on that platform at building an image from an installed Kali on ARM
I know from experience that it is usually more successful building an image from the same platform type as the intended target, cross compilation can be error prone.
It sounds like you’ve had some experience with building images yourself, and had to work through any occurring problems, so you know how maddening it can be.
I find hacking on any system the same, once you’ve ironed out any kinks you can repeat it easily, but getting there the first time definitely requires patience and test ones sanity!
reading the docs, these are the dependencies;
compilers=“crossbuild-essential-arm64 crossbuild-essential-armhf crossbuild-essential-armel gcc-arm-none-eabi”
dependencies=“arch-test autoconf automake bc bison build-essential cgpt cgroup-tools cmake curl dbus
debootstrap device-tree-compiler dosfstools e2fsprogs eatmydata flex gawk git gnupg kpartx
libncurses-dev lsb-release libssl-dev lsof lzma lzop m4 make mmdebstrap parted pixz pkg-config
python3-dev qemu-user-static rsync swig systemd-container u-boot-tools vboot-kernel-utils vboot-utils
libgnutls28-dev uuid-dev”
deps=“${dependencies} ${compilers}”
Back when armv7 was new and all the distros were trying it out… I chose the Cubieboards and worked with the Fedora developers. They did most of the builds, but there was plenty for me to do and contribute. Somewhere around Fedora32 we all stopped working on armv7 and I just ran with what I had and lost contact with a number of people.
But yes, it was frustrating figuring out what the boards could and could not do. And how to get the OS builds to, well, build!
So now I have 6 Cubieboard2, 1 Cubietruck, 1 Odroid-HC4, and some others sitting around. Well 3 C2 are still running and really need a new OS!
Thus I am here, kind of hoping that KaliLinux will give these things more life and I don’t have to go eat the RPi koolaid. And spend the $$$.
Thanks for any help you can send my way!
I had some spare time earlier, so I had a first go at creating an image from the Kali Arm repo listed earlier in the post, I did proceed farther than yourself with it, but still have some issues to iron out.
Installing dependencies using the shell script, there were still some that had to be manully added, could just have been my platform of course, but that part went OK
Creating the image proceeded until it needed to create the chroot environment to build the image in, and then it threw an error about qemu-arm not being a valid binfmt type for qemu to use.
I tried adding the magic bytes for the arm7 and arm8 chips manually which killed my system (It just hung it, even on reboot) and led to a reinstall of Kali 
Suffice to say that for now, I need a working Kali, and I shall have another go at it next week when I have some spare time. Note to self, create a snapshot and use another VM to build in..
I might even try a Debian ARM image as the base.
Anyway, in the meantime, this method using Docker looks interesting, and has some good info in there;
Never easy. Always some flavor not exactly like the original developer did. Partly because the OS code has moved forward since “they” did their work!
I appreciate your efforts and look forward to your success. I will be away until Wednesday.
Again, thank you.
I am curious to have a go myself but I dont have a cubieboard to test on. I went looking to buy one and everywhere seems out of stock.
I don’t see a way here for private messaging. I am in Oak Park, MI and maybe we could work something out. I have 7 c2. Three running Centos 7. It is easy to find me through my IETF work.
I will message you tomorrow. I’ll start trying to build an image on Debian and see if I come up with anything.
My build deps has completed successfully. Will let you know what further progress I make…
Update: Still building. When I ran ./cubieboard2.sh I should have used the --slim switch. Good to know for next time.
Update2:
┌──(kali㉿kali)-[~/kali-arm/images]
└─$ ls -lh
total 13G
-rw-r–r-- 1 root root 13G May 31 17:02 kali-linux-2025.2-cubieboard2-xfce-armhf.img
Update3:
Shhhhugar! I only read this now. OK, I will save the image I created somewhere, and we can talk about it on Wednesday. Enjoy your trip.
Here are my build notes for anyone planning to do the same thing:
cubieboard notes
Steps taken:
Step 1: Cloned existing VM
Step 2: Boot cloned VM
Step 3: Clear some space. I removed Discord and my custom scripts. Regained .5GB(may not be necessary. Edit: Clearing space is absolutely necessary. During the creation of the img file, I got down to 3gigs spare and nuked the downloads folder, getting 9 back. Phew!
Step 4: clone repo
Step 5: Run: sudo ./common.d/build_deps.sh
Note: build_deps completed successfully
Step6: Run: sudo ./cubieboard2.sh # Next time I will use the --slim switch. Which would shorten the build time and create a smaller img.
W: Download is performed unsandboxed as root as file /home/kali/kali-arm/base/cubieboard2-xfce-armhf/working/var/lib/apt/lists/partial couldn’t be accessed by user _apt
Note: The system wide cache is empty, so run sudo apt-file update once started
Total build time was about 2 hours including downloading all necessary packages.
@rgmhtt I sent you a private message.