Whonix for arm64 / Raspberry Pi (RPi)




1 Like

Whonix git tag might fix the build issues.

1 Like


1 Like

Build still broken.

E: Cross building is possible only with the APT dependency resolver

1 Like

That very issue is fixed. But more to do.

1 Like

I think I know where previous build issues are coming from. Some architecture specific packages. Trying to find a solution.

sent to debian-mentros mailing list:
‘Architecture: all’ with architecture specific dependencies - the Depends field contains an arch-specific dependency but the package is architecture all

1 Like

Guide for cross compiling and verifying that the binaries are really compatible for the other platform:


1 Like

We don’t have any packages supporting cross compilation. [1] These “special” packages are amd64 only (Intel and AMD) at the source code level. For example LKRG is linux, amd64 only. It’s non-trivial to port them to other architectures.

A guide on “how to cross compile” won’t cut it. A guide “how to cross compile” would work if these were simple packages similar to the hello package which does not have any architecture specific source code.

But this isn’t a compilation issue. This is only a packaging issue. The issue is described here:

Got an answer here and it looks like there isn’t any solution without proverbially biting any bullet:

This is currently breaking distro-morphing / Installation from Repository.

[1] At least none where that’s worth it. For packages that support cross compilation, that is already supported. kloak can be cross compiled on amd64 for “i386” (more “i686”). Not interesting/worth it though due to this. What would be interesting / worth it though would be to cross compile to arm64 which however has issues which probably only upstream can solve.

Cross compiling hardened malloc to arm64 would be interesting / worth it but upstream already said it’s not possible:

1 Like

I was assuming they were not using assembly level optimization or arch specific features of the kernel

1 Like


  • A) We find a solution for above issue. Not sure possible.
  • B) We no longer depend on architecture specific packages, no longer install these by default (soon: lkrg, kloak, tirdad, …) Seems pretty bad.
  • C) Leave distro-morphing / Installation from Repository broken (or outdated) and require build from source code. [This is the case at time of writing.]
  • D) Split kicksecure-dependencies-cli into
    • kicksecure-dependencies-cli
    • kicksecure-dependencies-cli-amd64
    • kicksecure-dependencies-cli-generic
    • or so. kicksecure-dependencies-cli-generic might not be build as often and outdated.
    • Sounds also somewhat non-ideal.
  • E) Don’t add binary packages for all Debian supported platforms to Whonix repository.
  • F) Build for all architectures. Takes tons of my CPU/disk time, disk space, disk wear.

I think this is the best option. The benefit of having some form of Whonix for these architectures, even without many of these great features still outweighs the drawbacks. At least we can be sure distro-morphing is still functioning and it may be useful in case someone sponsors hardware for building all packages in the future.

However will this mean we can’t apt-get install these select packages? Perhaps you can put all distro morphing approved dependencies in their own package?

“Who’s we?” :wink:
Always a good question to ask.
Assuming we is “amd64”.
Either way. Both, apt-get install select packages and even distro-morphing will be possible for the amd64 (Intel and AMD) architecture.

Currently for example arm64 users cannot install affected meta packages since these depend on amd64-limited packages.
As a follow up issue, that is a/the reason for broken arm64 build process.
arm64 however currently can apt install most “non-meta” packages such as security-misc or sdwdate.

All packages are compatible with disto-morphing. Just not all packages are available for all architectures.
Meta packages are caught up “in between”. (No issue for amd64.)
It’s a dpkg / debhelper / debian policy limitation:

Might have found an OK solution.





Need to test a new build.

1 Like


1 Like

https://github.com/Whonix/Whonix/blob/master/build-steps.d/2375_build_rpi_fs issue. Interactive question.

+ local img=/home/user/whonix_binary/Whonix-Gateway-RPi-
+ losetup --all
+ sync
+ wait 9640
+ sleep 2
+ local kpartx_output a b device
++ kpartx -a -s -v /home/user/whonix_binary/Whonix-Gateway-RPi-
+ kpartx_output='add map loop0p1 (254:3): 0 209709056 linear 7:0 4096'
+ sync
+ '[' 'add map loop0p1 (254:3): 0 209709056 linear 7:0 4096' = '' ']'
+ losetup --all
/dev/loop0: [65025]:7610049 (/home/user/whonix_binary/Whonix-Gateway-RPi-
+ sync
+ read a b device _
+ dev_mapper_device=/dev/mapper/loop0p1
+ '[' '' = true ']'
+ sudo --non-interactive -u user mkdir --parents /home/user/whonix_binary/Whonix-Gateway-RPi_image
+ sync
+ mount /dev/mapper/loop0p1 /home/user/whonix_binary/Whonix-Gateway-RPi_image
+ sync
+ sudo --non-interactive -u user truncate -s 2048M /home/user/whonix_binary/whonix_gw_rpi.img
+ sudo --non-interactive -u user mkdir --parents /home/user/whonix_binary/whonix_gw_rpi.img_mpoint
++ losetup -f
+ dev=/dev/loop1
+ losetup /dev/loop1 /home/user/whonix_binary/whonix_gw_rpi.img
+ parted -s /dev/loop1 mklabel msdos
+ parted -s /dev/loop1 unit s mkpart primary fat32 -- 1 524280
Warning: The resulting partition is not properly aligned for best performance.
+ parted -s /dev/loop1 set 1 boot on
+ parted -s /dev/loop1 unit s mkpart primary ext4 -- 524281 -1
Warning: The resulting partition is not properly aligned for best performance.
+ parted -s /dev/loop1 print
Model: Loopback device (loopback)
Disk /dev/loop1: 2147MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start  End     Size    Type     File system  Flags
 1      512B   268MB   268MB   primary               boot, lba
 2      268MB  2147MB  1879MB  primary  ext4

+ mkfs.fat /dev/loop1p1
mkfs.fat 4.1 (2017-01-24)
+ mkfs.ext4 /dev/loop1p2
mke2fs 1.44.5 (15-Dec-2018)
/dev/loop1p2 contains a ext4 file system
	last mounted on /home/user/whonix_binary/whonix_gw_rpi.img_mpoint on Sat Apr  4 19:55:14 2020
Proceed anyway? (y,N)

I can add force (-F) to mkfs but that might just silence the symptom. The question is why /dev/loop1p2 contains a ext4 file system and if that is expected.



Good news. Due to recent development efforts, arm64 / Raspberry Pi (RPi) builds were fixed in Whonix git tag

sudo ./whonix_build --target raw --flavor whonix-gateway-rpi --build --arch arm64 --kernel linux-image-arm64 --headers linux-headers-arm64

There might still be minor build issues or unrelated issues due to the recent development efforts. Therefore this is likely to work better when the next stable release of Whonix gets released.

Will edit to add link to recent development efforts.

Note: only the build was fixed. I didn’t try to boot the image let alone try it on real hardware. You could help the development if you could create instructions how to boot that image using virtualization such as libvirt configuration files and/or qemu command line to boot the image from a amd64 host.

It would be good if we had a Debian based CI (continuous integration) server with full support to use mount etc. Then Whonix build script could continue to build RPi builds on that server to make sure that new changes don’t break again RPi builds.

1 Like

I tried to build it by:

git clone --jobs=4 --recursive https://github.com/Whonix/Whonix
cd Whonix
git checkout
sudo ./whonix_build --target raw --flavor whonix-gateway-rpi --build --arch arm64 --kernel linux-image-arm64 --headers linux-headers-arm64

but got:

ERROR in ././build-steps.d/1100_sanity-tests detected!
(whonix_build_error_counter: 1)
(benchmark: 00:00:01)
trap_signal_type_previous: unset
trap_signal_type_last    : ERR
1: : init
2: : /usr/sbin/lightdm 
3: : lightdm --session-child 13 20 
4: : cinnamon-session --session cinnamon 
5: : /usr/bin/python3 /usr/bin/guake 
6: : /usr/bin/zsh 
7: : sudo ./whonix_build --target raw --flavor whonix-gateway-rpi --build --arch arm64 --kernel linux-image-arm64 --headers linux-headers-arm64 
8: : /bin/bash ./whonix_build --target raw --flavor whonix-gateway-rpi --build --arch arm64 --kernel linux-image-arm64 --headers linux-headers-arm64 
9: : /bin/bash ././build-steps.d/1100_sanity-tests 
main (line number: 122)
main (line number: 119)
git_sanity_test_main (line number: 145)
git_sanity_test_check_for_uncommitted_changes (line number: 136)
error (line number: 30)
errorhandlergeneral (line number: 357)
errorhandlerprocessshared (line number: 192)
last_failed_bash_command: error_ "See above! (There should be a bold, red message surrounded by blue hashtags (#).)"
last_failed_exit_code: 127
ERROR in ././build-steps.d/1100_sanity-tests detected!

I’m not developing btw. Just trying to get an image I can run.

Trioxin via Whonix Forum:

last_failed_bash_command: error_ “See above! (There should be a bold, red message surrounded by blue hashtags (#).)”


1 Like