Whonix for arm64 / Raspberry Pi ( RPi )




non-qubes-vm-enhancements is for VMs only so should not be installed on CLI gateway anyhow.

About any packages you need which are currently included in non-qubes-vm-enhancements we can maybe later find a solution in a later revision. Let’s see.

What’s happening? Breaks build? Breaks boot? Just doesn’t enable apparmor in grub kernel command line? If it just doesn’t work I guess it’s just a tiny package we could leave it as is until we can repair the package.

Any error message? Perhaps we can fix it?


Ok so the CLI package should be for bare-metal only. The most critical package would be probably initramfs-tools. But maybe it is pulled in somewhere else, maybe even during the initial debootstrap since it is more or less an essential package.
“anon-shared-packages-dependencies” also has vbox-disable-timesync. Would not be required for a CLI gateway but would also not hurt.
“anon-apps-config” could also be removed from “anon-shared-packages-recommended” it mostly changes KDE related settings.

The rpi won’t boot with grub since grub-pc is not available for arm64 and we therefore don’t install it during the grml-debootstrap step.
I did not test it but the script would likely fail during installation of “grub-enable-apparmor” as the postinst script will try to update grub and fail. However, looking at the script again it will always exit 0 and the whole build script won’t break. So it is maybe a non-issue.


I see. That would work. However keeping packages installed at debootstrap as minimal as possible is good for the far future. All packages installed there count as “manually installed”. Imagine initramfs-tools is replaced later by a better tool. In that case it’s better if we can remove it from Whonix meta packages, add a replacement package and see initramfs-tools being autoremoveed. Otherwise distribution package management gets harder.

It has also

  • apt config (relevant to cli gw)
  • vlc config (not relevant to cli gw), d
  • systemd-resolved disabling (relevant to cli gw)
  • and more

However the readme is outdated. Will update it now.
So best kept. Also doesn’t interfere with cli gw.

Yes. Probably non-issue. grub-enable-apparmor doesn’t depend on grub. Its postinst using if command -v update-grub >/dev/null 2>&1; then so it’s not even showing an error message. That package was designed with grub not being installed in mind not causing any issues.


The package list would look like:

Package: non-qubes-whonix-gateway-cli
Architecture: all
Pre-Depends: whonix-legacy
Depends: anon-shared-packages-recommended, anon-shared-packages-dependencies, anon-gateway-packages-recommended, whonix-shared-packages-dependencies, anon-connection-wizard, whonix-gateway-packages-dependencies, whonixsetup, tor-control-panel, ${misc:Depends}
Description: Packages for a minimal Whonix gateway
 A metapackage, which installs packages for a non-gui 
 Whonix Gateway.
 Do not remove.

Package: whonix-gateway-rpi
Architecture: all
Pre-Depends: whonix-legacy
Depends: non-qubes-whonix-gateway-cli, rpi-patches, wpasupplicant, firmware-iwlwifi, firmware-atheros, firmware-brcm80211, firmware-ralink, firmware-realtek, iw, fake-hwclock, ${misc:Depends}
Description: Packages for whonix-gateway-rpi
 A metapackage, which installs packages for a non-gui 
 Raspberry Pi 3 Whonix Gateway.
 Do not remove.

The rpi gw builds fine and works. I’d create a new flavor non-qubes-whonix-gateway-cli? and test it. Is there anything missing for a non-rpi amd64 version? Maybe some driver packages, similar to the rpi could be added. Or we leave it as is (and maybe also remove the ones from the rpi meta package) and leave driver installation to the user.


That looks very clean already. Last post’s excerpt is ready for merge.

Just a few nits that I would probably fix on top. Wondering why whonixsetup needs to be referenced individually.

non-gui -> CLI

anon-connection-wizard might not be required but not sure but ACW will be merged into tor-control-panel anyhow.

tor-control-panel will not be required anymore in near future. (Once cleanly separated to anon-shaerd-helper-scripts.) Will remove then.


The only way whonixsetup would be installed is as Depends of whonix-gateway-packages-recommended. This, however, would install mostly gui packages so we can’t use it in Depends of the non-qubes-whonix-gateway-cli package.


Yes. The package split cli vs gui is not perfect yet. I will add to each package description if it is a gui or cli package.

I am also considering to abolish all the anon- packages and merge them into the whonix- packages for simplification. (No one going to use the anon- packages outside of Whonix.)

Perhaps later I will rename all anon-meta-packages to have a postfix -cli and -gui.


Cloning the Whonix repo in the ususal way currently fails with:

“error: no such remote ref c405879185429b23b00b1c1552ddf4c459ca5037
Fetched in submodule path ‘packages/sdwdate’, but it did not contain c405879185429b23b00b1c1552ddf4c459ca5037. Direct fetching of that commit failed.”

All packages from sdwdate to xchat-improved-privacy seem to be affected.



I add to travis to get e-mail notifications when it fails to git clone.


I opened some pull requests for new version of the anon-meta-packages package and general patches to enable build of the rpi and cli gw flavor.
I also tested the non-rpi cli version and it works as expected. Manual network config is still required. For testing it is probably best to not use the normal 100G image size otherwise you need to wait a while when burning to disk. It should fit in around 2G.


How do you make the image bootable?

original grml-debootstrap

[ -n "$DEBOOTSTRAP" ] || DEBOOTSTRAP='debootstrap'

vs your fork

[ -n "$DEBOOTSTRAP" ] || DEBOOTSTRAP='qemu-debootstrap'

This does not necessitate a change.

The syntax [ -n "$DEBOOTSTRAP" ] || DEBOOTSTRAP='debootstrap' in grml-debootstrap means if variable DEBOOTSTRAP is unset, set it to DEBOOTSTRAP='debootstrap'.

So just set

export DEBOOTSTRAP='qemu-debootstrap'

in build-steps.d/1300_create-raw-image above [ -n "$DEBOOTSTRAP" ] || DEBOOTSTRAP='debootstrap' add

if [ "$WHONIX_BUILD_FLAVOR" = "whonix-gateway-rpi" ]; then
   [ -n "$DEBOOTSTRAP" ] || DEBOOTSTRAP='qemu-debootstrap'

What’s the rationale for skipping fscktool?

Anyhow. Disabling it does not require a grml-debootstrap change. If skipping is required, grml-debootstrap gives us the chance to skip it since it is using if [ "$FSCK" = 'yes' ] ; then.

Whonix sets [ -n "$FSCK" ] || export FSCK='yes' but then again that gives you the freedom to set export FSCK='no'

in build-steps.d/1300_create-raw-image above [ -n "$FSCK" ] || export FSCK='yes'

if [ "$WHONIX_BUILD_FLAVOR" = "whonix-gateway-rpi" ]; then
   ## comment why
   [ -n "$FSCK" ] || export FSCK='no'

finalize_vm you’re skipping because of grub. Unfortunately grml-debootstrap currently does not seem a way to skip grub.

I’ve created a fully untested grml-debootstrap skip-grub branch. Please jump in.

Also created an RPI feature request against grml-debootstrap.

whonixsetup python imports from tor-control-panel now. So you might be able to remove the dependency on anon-connection-wizard. Very minor. You could also wait until we fix the bug and move that code to anon-shared-helper-scripts so whonixsetup does not have the undeclared dependency on tor-control-panel.


How do you mean? The main magic is the 2375_build_rpi_fs_script which creates a bootable fat partition and moves kernel/initrd/firmware over there and the rpi-patches package which installs the firmware files. Images are tested on an RPI 3 B.


But what bootmanager is being used if its not grub? What’s the bootloader?


It does not have one in the general sense, the boot rom and firmware files are used during early boot. All rpi images boot in this way. A boot menu is maybe possible via uboot or via grub-efi for arm64, though the latter one is rather new. You can change boot options via the config.txt and cmdline.txt on the fat partition.


Merged. Some commits on top. Please check.


Looks good the cli gateway is building and working fine. Could you please also merge the rpi-patches package?


I.e. add https://github.com/Algernon-01/rpi-patches to https://github.com/Whonix/Whonix/tree/master/packages?

https://github.com/Algernon-01/rpi-patches has unaddressed bugs related to copyright and others. Will try to find my comment.


Don’t add to package:

What’s the copyright of…:

This file is wrong then https://github.com/Algernon-01/rpi-patches/blob/master/debian/copyright

Files created by you: please add copyright on top

Files not created by you: let’s see but https://github.com/Algernon-01/rpi-patches/blob/master/debian/copyright needs to be very correct. Cannot break any copyright laws.

License: Proprietary is a problem. For now there are no non-free packages in Whonix repository. Nothing comparable.

License really is Proprietary? It looks like a BSD-style license. The same license text (except for copyright holder) should already be a Debian accepted license in available from Debian.

Comment: downloaded from https://github.com/RPi-Distro/firmware-nonfree/blob/master/brcm80211/brcm/brcmfmac43430-sdio.txt

That links is broken.

I need to be able to check the file from the origin with the copy even if binary file. Any changes made to any of these files (firmware files) not originally created by you?

Why aren’t these binary files available from Debian repository? Is there at least a RFP (request for packaging) already?

https://github.com/RPi-Distro/firmware-nonfree/blob/master/debian/copyright.meta mentions Ben Hutchings who’s a Debian Developer so I wonder what the state of this package in Debian is.


All files including the binary ones were taken from this package (arm64 version): https://packages.debian.org/buster/raspi3-firmware

I did not do any modifications to the binary files.

Good question. In the original files there is none.

What about modified ones?

Some were adapted to the Whonix build process. Like

Would this be an exclusion criteria? I think the official Debian images would also include these?
We can maybe also wait for buster and then try to include the official Debian package into the build process.

  1. Commit the unmodified file fist. Or revert to unmodified version.
  2. Then make sure it’s properly listed here: https://github.com/Algernon-01/rpi-patches/blob/master/debian/copyright
  3. If the format of the file allows:
  • add copyright on top
  • submit pull request to upstream so they fix their copyright
  1. Commit the modifications on top. (So it can be seen what was the original, compared with upstream for verification, and seen/tracked in which file the file was modified.

What’s the copyright of…:
In the original files there is none.

Undefined copyright (probably not the case here since the package is in Debian) would be an exclusion criteria. This is because undefined copyright leads to the legal defaults which is fully copyrighted which is forbidden to redistribute.

Not necessarily. If licensing is sorted out, even if nonfree, if legal could be uploaded to Whonix nonfree. But we can do much easier here, I think. More at the very bottom of my post.

Just would have to make sure we’ll have Whonix nonfree repository. That’s currently not the case. /etc/apt/sources.list.d/whonix.list. This needs a fix in package whonix-repository (to fix new /etc/apt/sources.list.d/whonix.list creations, as well as whonix-legacy (to fix existing users /etc/apt/sources.list.d/whonix.list). Do you think you could work on that?

We can also do it in stretch if you like and if that works. Why don’t we download the whole https://packages.debian.org/buster/raspi3-firmware package from Debian buster and upload to Whonix stretch as is? It has very few dependencies and might just work?

(The download -> upload has no licensing issues since Debian is already strict about it so I am very comfortable from a licensing point of view.)

build-steps.d/1200_create-debian-packages has code for tor from TPO project repository already, for virtualbox guest addition… So why not add it for:

Do you think you could work on that?