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

Yeah the --target UTM works… but apperently its wrong. Anyways i do not get the Tor browser to work on it.

Well maybe GavinPacini the contributer from summer for this project might have added UTM support? I have not seen his commit yet on github. But who knows, maybe i am wrong again.

Broken links.

There is no strict rule to add all pastes to a paste website. For smaller things, this can certainly be posted to the forums directly. Appreciated when using quotation or code tag.

Only the full build log does not fit into the forums due to size restrictions.

If nobody is here who understands the UTM that was contributed to the source code, knows the state of what is done, what is missing, can make it good enough then that for all practical purposes means for users “there is no UTM support”.

As for these changes:
MacOS: Difference between revisions - Whonix

Please add some more changes…

The --repo true has to be suggested with care. It depends on the perspective of the one running instructions.

  • View point “I really want to build from source code as much as possible and avoid binary repositories”: Those building from source code get offended if the binary Whonix repository gets unexpected enabled.
  • View point: “I just want UTM because there is no downloadable image and otherwise as simple as possible” then --repo true is OK.

It’s confusing anyhow to have the “main” build documentation and then separate build instructions for UTM on a different page. If MacOS page mentions utm then at minimum it also needs to be mentioned on Whonix ™ VM Build Documentation.

Previously network configuration was changed on the wiki. This was then not reflected in the utm config files. What about this change MacOS: Difference between revisions - Whonix

Sorry about that, i edited the post with new links now and remembered to uncheck burn after read.
Link should work now on the same post.

For me personally i want to have a UTM build that work as correctly as possible. Meaning it should work from just building it from source and it works. But as of this moment the web browser does not work so i need to repo to do some debugging and troubleshooting. The reason for be being so persistent with UTM and not just using qemu is that UTM is way more accesible and easier to use than qemu. Parallels and vmware are closed source and does not meet what i seek to use for whonix and qemu is to complex for everyday use. Thats why i want to do my best to make it work correctly on UTM so its not just accessed by me but many more.

Also is there a way too update the UTM config file? Or make a guide so that UTM can be used for building this project?

1 Like

I have removed --repo true from the edit. I will look at the build documentation and see what I can change. I think the only change is the --target utm and for M1 --arch arm64.

The utm files generated for me by --target utm had the updated command before the edit was posted in this thread earlier.

I am confused. Are you saying that the change to networking on the wiki was the edit you linked to? If not, where in the wiki do I look?

1 Like

MacOS: Difference between revisions - Whonix was a wiki edit by someone who only did that wiki edit and isn’t around anymore apparently. It was an edit of the qemu command line parameters which were previously part of the wiki.

The edit MacOS: Difference between revisions - Whonix to the qemu command line in the wiki is not part of the utm files. The wiki was previously edited but the utm files have not been updated with the same change.

Posts where I include links often probably only make sense when visiting the link.

Does that answer your question?

Probably makes a lot sense. Copying super long qemu commands is really bad usability.

For sure. Original files were contributed earlier. Can be edited / please send a pull request.

This depends all on contributions.

Will check.

ERROR: Failed to download: Tor Browser Ports - Browse Files at SourceForge.net

Btw this is expected. The file does not exist. Nobody providing it. This is issue: ARM64 Tor Browser - #8 by Patrick

As for why not all packages are installed and why dummy-dependency is installed after build (it should not be), I don’t know yet.

More to try.

sudo apt purge dummy-dependency
sudo apt-get install tb-updater tb-starter tb-default-browser
sudo apt purge dummy-dependency
sudo apt-get install tb-updater tb-starter tb-default-browser electrum
sudo apt-get install tb-updater tb-starter tb-default-browser electrum monero-gui
sudo apt-get install non-qubes-whonix-workstation-xfce
sudo apt-get install non-qubes-whonix-workstation-cli
sudo apt-get install uwt
sudo apt-get install bindp
sudo apt-get install kloak
sudo apt-get install tirdad

More background information:

Now I think I am onto something, what might be happening. Some architecture specific package (list in above link) isn’t available for arm64. This results in the dummy-dependency package being pulled as dependency instead. That however then prevents other “optional dependencies” from getting pulled as dependency.

I looked at the settings in utm for the workstation, and it does have the corrected QEMU setting in it from that edit. I built from

Also, the plist for workstation that you linked to seems to have been updated as well? This is why I was confused.

If I am missing something, let me know. I will get it eventually. :slightly_smiling_face:

Here is the output on a clean workstation: https://anonpaste.org/?51d67ff9474b12fd#CLWaPgj9ap2fr2wfkUUsdjs6WkVueVWPJRarj1r7F15T

So you updated the wiki? just wondering. How do i know that the debian bullseye UTM file is safe? wouldnt it be better to direct people to debian download page and how to set it up? again idk. I am just paranoid when someone gives me a file and idk where it is from.

Also on the build command are we still gonna use --tb open on workstation? so that the commands are like this:

sudo ./whonix_build --target utm --flavor whonix-gateway-xfce --build --arch arm64
sudo ./whonix_build --target utm --flavor whonix-workstation-xfce --build --arch arm64 --tb open

If i remember correctly from a earlier guide that was given here?

MacOS: Difference between revisions - Whonix

If not needed then forget this part.

But as i have understood from this so far. There is most likely a dependency crash bug on the arm builds that makes tb-browser not get installed correctly. And there is for the moment no way to download the Tor Browser because the file does not exist on the repo at the moment.

So for the moment, we have to find the bug, fix it and rebuild the project to make it work correctly?

Ya, the vm was me being lazy. It took me less time to make the image and upload it then to explain how to do it (I mean literally 5 minutes). I will have to get around to that I suppose.

I have never used --tb open. I am not sure what it does. The builder of the arm64 packages of TBB needs to update his packages to use the new GPG method. Earlier in the thread Patrick posted a link to instructions for manually installing TBB (not packages from the repo I guess, didn’t read it yet).

I think the whole point with manually getting it to work is meaningless. The point should be to make it work when building and possibility to update it with just the upgrade-nonroot command. This should not be just a project for developers and IT experts like us. But for anyone who wants to use Tor safe.

Would be amazing if we one day could publish finished utm files of the workstation and gateway for Apple silicon.

I documented --tb open in a past version Whonix for macOS: Download and Installation but then it was edited and removed.

  • set build parameter --tb open will result in tb-updater (Tor Browser Downloader by Whonix ™ developers) attempting to download Tor Browser during the build process but fail open (continue the build without error) should the download fail. At time of writing, Tor Browser download will fail but that is OK as far as the build process is concerned.


Seems outdated.

It wasn’t updated.

https://github.com/Whonix/whonix-libvirt/blob/master/usr/share/whonix-utm/Whonix-Gateway.plist is still using

-device virtio-net-pci,netdev=external
-netdev socket,id=internal,listen=:8010 \

No further commits were made since initial version:

This forum post is valid until 15 January 2022. Do not apply these instructions after that date.

Nothing special happening on this date but this isn’t something useful to to try to fix arbitrary different issues in 1 year from now.

These instructions are for an already built image.

The updated meta packages (see my preview forum post) should make it much less likely of falsely getting the dummy-dependency package installed or even fix this issue alredy.

  1. enable Whonix developers repository as per Whonix APT Repository

The goal must be to not have the now “catch-all” dummy-dependency package as well as having as few dummy-dependency-... packages as possible. Not all packages by Whonix are available (yet) for the arm64 platform.

sudo apt purge dummy-dependency
sudo apt-get install tb-updater tb-starter tb-default-browser

sudo apt purge dummy-dependency
sudo apt-get install tb-updater tb-starter tb-default-browser electrum

sudo apt-get install tb-updater tb-starter tb-default-browser electrum monero-gui
sudo apt purge dummy-dependency

sudo apt-get install non-qubes-whonix-workstation-cli
sudo apt purge dummy-dependency

sudo apt-get install non-qubes-whonix-workstation-xfce
sudo apt purge dummy-dependency

sudo apt-get install uwt
sudo apt purge dummy-dependency

sudo apt-get install bindp
sudo apt purge dummy-dependency

sudo apt-get install kloak
sudo apt purge dummy-dependency

sudo apt-get install tirdad
sudo apt purge dummy-dependency

sudo apt-get install hardened-malloc
sudo apt purge dummy-dependency

sudo apt-get install non-qubes-whonix-workstation-cli
sudo apt purge dummy-dependency

sudo apt-get install non-qubes-whonix-workstation-xfce
sudo apt purge dummy-dependency

  1. downgrade Whonix repository to something other than developers repository

background information:
kicksecure-meta-packages/debian/control at master · Kicksecure/kicksecure-meta-packages · GitHub

This is included in git tag:

Another idea if dummy-dependency still get installed during the build process would be to simply remove that package from the source code.



Look for:

Package: dummy-dependency
Architecture: all
Depends: ${misc:Depends}
Provides: tb-updater, tb-starter, tb-default-browser,
Description: dummy package to satisfy architecture specific dependencies
 A metapackage, which satisfies the dependency on:
  - tb-updater
  - tb-starter
  - tb-default-browser
  - qubes-core-agent-passwordless-root
  - firefox-esr
 This package cannot provide a real implementation of that package. It is only
 a dummy to satisfy the dependency.
 Safe to remove if its removal does not remove another metapackage, which is
 not safe to remove.

And delete that text or out comment.

In that case, it would probably be easiest to add to build command line:

–allow-untagged true --allow-uncommitted true

That might actually break the build but it could be progress in finding out which package isn’t available for arm64, if still any.

Aha! Gateway. The edit seemed to apply to just the workstation, and that does have what the edit suggests.
As for the gateway, I am unsure what to change. I see that it has networking disabled, so I assumed the netdev=external bit was for the gateway to access the internet. I guess I will discuss it with the utm developer to see if enabling networking on the Gateway and removing external would be better?

You can try that but I don’t see much chance there. utm is just a wrapper around qemu as far as I understand and neither qemu nor utm developers might have all the context of what Whonix is doing in mind.

So tried building whonix on the new “” git tag. And workstation crashed when i build it.

Also still kinda unsure what need to be changed on the .plist for workstation and gateway for UTM builds.

Is something gonna happen 15 of January 2022?