Whonix for arm64 / Raspberry Pi (RPi)

I guess it should not be too much of a difference except for maybe disk space usage.
I also tried the alternative with --vmsize 3500M. It works the same, expanding the disk size to fill the whole device is maybe a little bit easier with this approach.

I can take a look, but I’m not sure how well it would integrate with my build infrastructure. I guess in particular the upload will be very slow.


I guess it should not be too much of a difference except for maybe disk space usage.

Alright, so if it doesn’t offend you, it can be left as is.



grml-debootstrap RPi patches need to be re-applied.

https://github.com/Whonix/Whonix/blob/master/build_sources/rpi-preferences is still required?

Still maintained?

Any buster build successful?

No. Due to some rather persistent “technical issues” around here I can’t do any builds currently. Probably won’t change in the near future.


Is there anything we can change about this for you to be able to build it?

1 Like

No, I don’t have any older images. You could try to build a (stretch) version with some 14.* git tag around the beginning of the year. I don’t know if it will buil though and it would be outdated obviously.

Doubtful. I already asked someone for help, nothing came out of this. At the least I’d need some new hardware for my security wellbeing /dedicated buildmachine and for testing (like rpi 3+) and maybe (maybe) some other “infrastructural” changes. Until then I’m limited mostly to theoretical “work”

1 Like


1 Like

Does not build due to grml-debootstrap missing feature and RPi building was never upstreamed.

Back then (Whonix 14, stretch based) https://github.com/Whonix/Whonix/commit/f2a474c1340bb9d57f82ca85171cbc77ec148cf0#diff-6cfb42832786e629f939f5c45178c774 created a fork of grml-debootstrap.

This might be the grml-deboostrap which worked in Debian stretch: https://github.com/Whonix/Whonix/blob/f2a474c1340bb9d57f82ca85171cbc77ec148cf0/help-steps/grml-debootstrap


So what is to do now:

Re-apply the modifications required to grml-debootstrap

In other words “rebase the grml-deboostrap modifications from stretch to buster so it can build RPi”.

Ideally implement Rasberry PI (RPI) support · Issue #114 · grml/grml-debootstrap · GitHub

1 Like

Diff of the Debian stretch based grml-debootstrap fork looks easy.

diff grml-debootstrap-stretch grml-debootstrap-fork

< [ -n "$DEBOOTSTRAP" ] || DEBOOTSTRAP='debootstrap'
> [ -n "$DEBOOTSTRAP" ] || DEBOOTSTRAP='qemu-debootstrap'
<          remove_configs umount_chroot finalize_vm fscktool ; do
>          remove_configs umount_chroot; do

In other words. Only three things.

  • DEBOOTSTRAP=‘qemu-debootstrap’ → done it git master
  • skip finalize_vm (this should just be grub install) → skip grub install done in git master
  • skip fscktool → dunno if required to disable or can be disabled without forking grml-debootstrap

Quote @Algernon Rasberry PI (RPI) support · Issue #114 · grml/grml-debootstrap · GitHub

The fsck step was not required. But I guess it can be put in again.

1 Like




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