https://github.com/Whonix/Whonix/commit/cfe2d9ee0d9617f8fae3f777427a971184140007
https://github.com/Whonix/Whonix/commit/4fc1d064107358a259cdbe17522ea8722759d3f1
https://github.com/Whonix/Whonix/commit/2e5b11eeda78b24a3ddc40792b8548135e94bc51
https://github.com/Whonix/Whonix/commit/cfe2d9ee0d9617f8fae3f777427a971184140007
https://github.com/Whonix/Whonix/commit/4fc1d064107358a259cdbe17522ea8722759d3f1
https://github.com/Whonix/Whonix/commit/2e5b11eeda78b24a3ddc40792b8548135e94bc51
Whonix git tag 15.0.0.6.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:
http://jensd.be/800/linux/cross-compiling-for-arm-with-ubuntu-16-04-lts
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:
https://lists.debian.org/debian-mentors/2019/11/msg00149.html
Got an answer here and it looks like there isn’t any solution without proverbially biting any bullet:
https://lists.debian.org/debian-mentors/2019/11/msg00156.html
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:
I was assuming they were not using assembly level optimization or arch specific features of the kernel
Options:
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
into
kicksecure-dependencies-cli
kicksecure-dependencies-cli-amd64
kicksecure-dependencies-cli-generic
kicksecure-dependencies-cli-generic
might 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?
“Who’s we?”
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:
https://lists.debian.org/debian-mentors/2019/11/msg00156.html
Might have found an OK solution.
https://github.com/Whonix/anon-meta-packages/commit/14561c5daa34c4d95fb1ba49ef6b0c0c6d9c5dec
https://github.com/Whonix/anon-meta-packages/commit/8d4b55e0e835989e4f6ccf15edc638e9c1189145
https://github.com/Whonix/anon-meta-packages/commit/1d46ddaa83788b160bc92c8252578d02a0eefb8b
https://github.com/Whonix/anon-meta-packages/commit/4c440cbda3a8f54710811c70295566ed96d73815
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-15.0.1.1.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-15.0.1.1.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: [65025]:7610049 (/home/user/whonix_binary/Whonix-Gateway-RPi-15.0.1.1.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 15.0.1.2.0-developers-only
.
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 15.0.1.2.0-developers-only
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!
anon_dist_build_version: 15.0.1.2.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 (#).)”
This.