Whonix git tag
18.104.22.168.0-developers-only might fix the build issues.
Build still broken.
E: Cross building is possible only with the APT dependency resolver
That very issue is fixed. But more to do.
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
Guide for cross compiling and verifying that the binaries are really compatible for the other platform:
We don’t have any packages supporting cross compilation.
 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.
 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:
I was assuming they were not using assembly level optimization or arch specific features of the kernel
distro-morphing/ Installation from Repository broken (or outdated) and require build from source code. [This is the case at time of writing.]
kicksecure-dependencies-cli-genericmight not be build as often and outdated.
amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc ppc64el s390x sparc)
distro-morphing/ Installation from Repository.
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?
Always a good question to ask.
we is “
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
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
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
It’s a dpkg / debhelper / debian policy limitation:
Might have found an OK solution.
Need to test a new build.
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-22.214.171.124.7.raw + losetup --all + sync + wait 9640 + sleep 2 + local kpartx_output a b device ++ kpartx -a -s -v /home/user/whonix_binary/Whonix-Gateway-RPi-126.96.36.199.7.raw + 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: :7610049 (/home/user/whonix_binary/Whonix-Gateway-RPi-188.8.131.52.7.raw) + 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.
I tried to build it by:
git clone --jobs=4 --recursive https://github.com/Whonix/Whonix cd Whonix git checkout 184.108.40.206.0-developers-only sudo ./whonix_build --target raw --flavor whonix-gateway-rpi --build --arch arm64 --kernel linux-image-arm64 --headers linux-headers-arm64
############################################################ ERROR in ././build-steps.d/1100_sanity-tests detected! anon_dist_build_version: 220.127.116.11.0 (whonix_build_error_counter: 1) (benchmark: 00:00:01) trap_signal_type_previous: unset trap_signal_type_last : ERR process_backtrace_result: 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 function_trace_result: 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 (#).)”