Whonix for arm64 / Raspberry Pi (RPi)

Another non-perfection not easy to perfect.

non-qubes-whonix-(gateway|workstation)-(cli|kde|xfce) is neither by name a VM specific or VM unspecific package. Due to majority Whonix use case it defaults to VM specific.

Not easy to perfect without a lot code duplication / more package maintenance.

For now non-qubes-vm-enhancements-cli gets installed by default even for physically isolated (RPi) builds since it’s a dependency of non-qubes-whonix-gateway-cli.

Maybe non-qubes-vm-enhancements-cli should become a weak recommended package? Similar to how build-steps.d/1700_install-packages handles virtualbox-guest-x11 / spice-vdagent? To keep it installed for users who already have it whonix-legacy/debian/whonix-legacy.preinst could use

apt-mark auto non-qubes-vm-enhancements-cli || true

Thank you for still having “dual build” (or how would we coin it) i.e. KVM and VirtualBox images at the same time in mind. This was always hacky having spice-vdaagent in VirtualBox. The above described weak recommended package is hacky.

In future, KVM builds will be created, signed an uploaded by HulaHoop. No more dual builds by me. (Due to increases build workload - Qubes-Whonix, Whonix CLI, Whonix XFCE, hardened debian, custom workstation, what not.) Therefore we might no longer need the dual build support since that wasn’t a clean way to start with. (Otherwise using dual builds these raw images would have both, VirtualBox guest addition as well as spice-vdagent, even though neither is needed there - could cause issues in some point in future.)

Would you like to build, sign and upload these raw images?

1 Like

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