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

The update-grub step…

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

Included in:

15.0.1.8.6-developers-only

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:

onion-grater

(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

Firstly, I haven’t forgotten about some items on my side. I still want to

  1. Update the wiki
  2. Work on the release script so we can have automatic UTM builds
  3. Test and integrate Tor ARM builds.

Busy with the day job right now. Hopefully calms down soon and I can contribute some more. :slight_smile:

@Sholenka, I’ve noticed this too, sporadically. It could be caused by a few things:

  1. Sometimes the rendering occurs on the efficiency cores of the M1. Option to only use performance cores when automatically determining core count · Issue #2557 · utmapp/UTM · GitHub
  2. Something related to SPICE / the video device being used. Graphics artifacts on Apple Silicon host (high screen tearing and mouse disappearing) · Issue #2569 · utmapp/UTM · GitHub
  3. Or the fact that 3D acceleration is missing because UTM is not using the patches available (although I think this is not going to really affect drawing normal windows). GitHub - knazarov/homebrew-qemu-virgl: A homebrew tap for qemu with support for 3d accelerated guests

Possibly even a mix of the above. Once I again have some more time, this is something else I want to tackle. Seeing as UTM already has those open GitHub issues, maybe someone else will solve it before me. But, I wanted to link them so you can follow the progress.

For your issue on Whonix taking up “more space” than the UTM window, if you run xrandr --output Virtual-1 --auto in the terminal once your UTM window is in an appropriate size, it should rescale correctly (sometimes you need to run this command a few times). It’s a known bug in XFCE: add support for xrandr hotplug_mode_update property / SPICE resize support (#142) · Issues · Xfce / xfce4-settings · GitLab

There are also some other workarounds proposed here: linux kvm - No Auto Resize with SPICE and virt-manager - Super User

I’ll probably incorporate something into the build and also make sure people know about these current limitations once I update the wiki. At least they are here in the forum for now.

2 Likes

Thanks. Hope that things will get sorted out. UTM makes the user experience quite a bit better. In case you want to add it to the wiki later, I found how to set up a shared directory between a VM and the host.

  • Right click VM → Edit → Sharing → Enable Directory Sharing → Save

  • Select the directory of the host on the main UTM screen

In the VM:

sudo apt install spice-vdagent spice-webdavd

sudo apt-get install davfs2

Make the directory in the VM to link with the one in the host and link them:

sudo mkdir /mnt/dav

sudo mount -t davfs -o noexec http://127.0.0.1:9843/ /mnt/dav

More on how to share a custom folder / directory on MacOS: Set up file sharing on Mac – Apple Support (UK)

edit: I’m only managing to get files from the host to VM this way, not from VM to host

2 Likes