Whonix on Mac M1 (ARM) - User Support (still unsupported at time of writing)

Awesome, thanks for pulling those changes in!

For now, I think it’s fine. Maybe it could be renamed to whonix-qemu or something? As that’s what all the files in there have in common. I do actually think a whole new package for two XML files (i.e. the UTM plist files) is overkill anyway.

I’ve never used it, does it have the same concept of a Gateway and Workstation? I can take a look at it a bit later, but for now I’ll prioritise getting the Mac UTM setup working well and updated on the relevant wikis. :slight_smile:

Yes, as far as I can tell there is no way to currently package them together. I know it’s not as simple as Virtualbox then, but for anyone using UTM that’s what they would be used to. I don’t think it’s too bad.

It looks relatively fine. One question on it: is this run as part of the overall build script or something which is run manually when you want to package a new release?

Thanks for all the feedback as always!

Thank you! Hm, on my existing Intel Mac with Whonix clipboard sharing works. Maybe I enabled that afterwards? I know it’s a possible leak, so I will default it to disabled for our repo then (will issue a PR for that). Will also do the other cleanups you mentioned, thanks for the review!


Clipboard sharing: Whonix VirtualBox has it (usability). Whonix KVM doesn’t have it (security). We had a lengthy forum discussion about it, I swear, but I cannot find it anymore. Maintainer specific call.

It’s separately wrong. (With same parameters as whonix_build.)

Cannot be run during whonix_build since it requires all VMs to be already build.
(Unless some assumption was added such as “if workstation was build, consider we’re done and start prepare_release”. Or if there was some whonix_build_multi script which existed before but just made the build process / script look more complex than it is.) Best design I could think off. Unless someone has a better idea how to structure things. :slight_smile:

Right. I ever considered having the UTM files in Whonix/Whonix (same as build script) but that also seemed non-ideal.


Worth combining both folders into one archive (KVM uses .xz to support sparse images) in prepare_release script? (Similar to Whonix KVM.) Then also the usual download table could be shared among VBox, KVM, UTM.

No. Actually simpler.

The update-grub step…

taking a very long time and above warnings has been resolved with the following commit:

Included in:

1 Like

Thanks for all the hard work that’s gone into this. I can confirm that I’ve got Whonix working on M1 locally after following these instructions, great work from all involved!

1 Like
1 Like

I’m trying it now. Tor Browser Downloader does not seem to be installed or present in the Start Menu.

1 Like

It’s not automatic / pre-installed yet. Perhaps in the next build.

  1. Need the updated tb-updater package.
  2. Run update-torbrowser. (As per in link in previous post.)

For any issues, logs would be needed to diagnose.

1 Like

Got the downloader installed. When I launch it I get an error that tor is not fully bootstrapped possibly due to having no internet connection.

When I boot up the Gateway VM for the first time I get an error that greater onion service is not running, but if I relaunch everything I can just browse and install packages like normal. Maybe this has something to do with it.

1 Like

These are general issues. Unrelated to tb-updater. These issues might be fixed in the testers repository if you enable that and upgrade all packages in gateway and workstation, the issues might be gone. Are they? If not, we have to debug because I thought these are resolved. These issues however will break tb-updater “as a side effect”.

Meanwhile to work around and isolate testing tb-updater, the --no-tor-con-check parameter which will Skip Tor bootstrap connectivity check. might be helpful.

update-torbrowser --no-tor-con-check
1 Like

I upgraded all packages in both VM’s, the issues persist. I downloaded TBB with your workaround and installed tb-starter, but it seems that it downloaded the normal TBB. When I try to launch it I get “Tor browser requires a CPU with SSE2 support”

I need the output of update-torbrowser.

If architecture auto detection fails, that can surely be fixed. Please report. Workaround if that was to happen:

ARCH=arm64 update-torbrowser

In that case please run in debug mode and share the output here.

bash -x update-torbrowser

In case of download / verification failures, please also run in debug mode.

ARCH=arm64 bash -x update-torbrowser

For onion-grater I also need from the gateway:
Daemon Log View for:


(If repetitive, I don’t need to see too much of the same.)

1 Like

I was a bit confused by your block so here is the output for different commands:

Output " update-torbrowser": Output update-torbrowser - JustPaste.it

Ouput “update-torbrowser --no-tor-con-check”: Ouput update-torbrowser --no-tor-con-check - JustPaste.it

Output " ARCH=arm64 update-torbrowser --no-tor-con-check": Output "ARCH=arm64 update-torbrowser" - JustPaste.it (still can’t run TBB)

Output “bash -x update-torbrowser”: Output "bash -x update-torbrowser" - JustPaste.it

Daemon log view of gateway gives: – No entries –

Version too old. You need tb-updater 3:19.9-1 (or above).

Did you enable the testers repository as per Whonix APT Repository?

And you always need --no-tor-con-check until the onion-grater issue is fixed.

Daemon log view of gateway gives: – No entries –

Did you run

sudo journalctl -b --no-pager -u onion-grater


1 Like

That was it, I didn’t enable it. Tor Browser is installed and launches! Can’t wait for the UTM port so it will have the full user experience.

I might have made a typo earlier when trying to get the Daemon Log View, so maybe that’s why it didn’t work. Here is the output when I use sudo journalctl -b --no-pager -u onion-grater :

1 Like

onion-grater does not show any issues.

Is this still happening after testers upgrades?

great onion service = onion-grater?

When you re-run systemcheck after a while does it pass all good?

1 Like

I don’t get an error anymore when starting tb-updater from the GUI. Everything seems to be fine now, will make a post here if I encounter any issues

1 Like

I have Whonix running with UTM with the build commands of @GavinPacini. I just used the UTM build commands, unpacked the tar files and opened the .utm files. Didn’t touch any other files. Copy and paste with the host works out of the box. A couple of issues I notice rightaway:

  • Moving windows has terrible graphics issues. This sometimes is resolved by making the VM another fullscreen window. Videos also don’t play smoothly.

  • When entering mission control and back out of it when the VM is another fullscreen window, two black bars occur above and under the desktop

  • The Whonix desktop takes up more horizontal space than the “borders” of the VM for some reason. As a result, when I try to make a window fullscreen in the VM it goes beyond the right side of the VM screen.

1 Like

I have the graphics issues less when using Whonix on non-UTM QEMU. Could it be due to UTM not having the patch for accelerated graphics like normal QEMU has after installing these packages linked in the Whonix wiki for M1? GitHub - knazarov/homebrew-qemu-virgl: A homebrew tap for qemu with support for 3d accelerated guests

1 Like