Fixed.
No, and from experience I guestimate it’s not likely to change anytime soon.
No, all as expected.
What you could do please, run the following comment
dpkg -l | grep dummy-dependency
That would show all the architecture specific packages which aren’t installed yet.
Thats okay, here are the results:
user@host:~$ dpkg -l | grep dummy-dependency
ii dummy-dependency-hardened-malloc 3:23.8-1 all dummy package to satisfy architecture specific dependency hardened-malloc
ii dummy-dependency-kloak 3:23.8-1 all dummy package to satisfy architecture specific dependency kloak
ii dummy-dependency-tirdad 3:23.8-1 all dummy package to satisfy architecture specific dependency tirdad
ii dummy-dependency-xorg-vm 3:23.8-1 all dummy dependency xserver-xorg-video-vmware
My guide to make whonix work on a mac m1 computer
For the moment then to make whonix work on macbook m1 computers you will have to follow the:
Guide and set up a debian 11.2 arm environment. Git pull the repo with this command:
git clone --depth=1 --branch 16.0.3.8-developers-only --jobs=4 --recurse-submodules --shallow-submodules https://gitlab.com/whonix/Whonix.git
Then build Whonix with these commands:
sudo ./whonix_build --target utm --flavor whonix-gateway-xfce --build --arch arm64 --tb open
sudo ./whonix_build --target utm --flavor whonix-workstation-xfce --build --arch arm64 --tb open
Then move the tar file locally on your mac, extract them and add the .utm for gateway and workstation to your UTM application. Then i go to setting on them both and add (fit to screen, retina mode, enable clipboard sharing) and enable virtio-ramfb-gl (gpu supported). I also for workstation add a bit more ram to 6gb but thats me. When i start both vm i also adjust the mouse, keyboard and theme setting on xfce.
On the gateway i use these commands on the terminal:
sudo passwd root
sudo passwd user
upgrade-nonroot
sudo apt install spice-vdagent spice-webdavd
sudo shutdown now
And start it up again, And on the workstation i use these commands:
sudo passwd root
sudo passwd user
upgrade-nonroot
sudo apt install spice-vdagent spice-webdavd
sudo shutdown now
At this point after starting up worktation again the tor browser does not work. To make it work follow this guide to manually set it up:
But instead of the link provided there use the tor browser port from Heikki Lindholm at:
This will enable Tor browser to work on the workstation OR to simplify it i have used these commands instead:
mkdir --parents /home/user/.tb
wget https://sourceforge.net/projects/tor-browser-ports/files/11.0.4-alsa/tor-browser-linux-arm64-11.0.4_en-US.tar.xz/download -P /home/user/.tb/
Then verify the download and:
open filemanager → extract download in .tb file → change filename to tor-browser
Then you get the same result. If you want a shared folder on gateway or workstation. Or even debian if that is needed. I use these commands and remember to enable shared folder on UTM setting before using these commands:
sudo apt install davfs2
sudo mkdir /mnt/dav
sudo mount -t davfs -o noexec http://127.0.0.1:9843/ /mnt/dav
And that is how i have managed to make Whonix work on macbook m1 to this date as correctly as possible. The build is broken for arm as of this moment because the build cannot download tb-browser. And the problem is kinda out of our hands as of this moment. So this is the only way i know of to make this work and have a functional whonix experience on my mac m1. Thanks for all the help so far and hope this guide will help some on their way untill the build or even just a ready UTM file for download is available.
I also hope this is the most correct way to make whonix work. If not tell me so i can change it.
I don’t know if this is the right place to ask this, but I am trying to buy a laptop and have two choices in mind, the XPS 13 or the MacBook Air M1, the XPS officially supports Whonix as it has an x86 CPU while the MacBook Air has better performance, has a much better battery, and doesn’t have a fan but does not officially support Whonix. Which one should I go with if need it to run Whonix, and what are the main issues currently with Whonix running on the M1 chip?
These would have to be ported by a developer.
Some have tickets already but certainly this would be much faster if a developer would look into this. Otherwise I am not sure upstream will ever implement arm64 support.
This one is OK. Isn’t needed. It says vmware but it’s actually used for VirtualBox since VirtualBox uses the same virtual graphics device driver. Since this ARM port doesn’t use VirtualBox, it isn’t needed.
All output as expected.
A post was split to a new topic: sdwdate loop - Conclusion: Tor already reports circuit established.
Followed the instructions in the wiki and the build failed with these errors. Sorry for the screenshot link. Couldn’t copy and paste from the VM or find the logs. No idea where to go from here, any help?
You can post links now.
The screenshot is already saying what should be done. It says:
Please have a look […]
You need to learn these skills first.
- It is recommended to set your terminal (for example xfce4-terminal) to unlimited scrollback, so you can watch the full build log.
I SSHed into the VM to get the full error. I don’t have a DE installed in the VM since the guide didn’t say one was needed.
############################################################
ERROR in ././build-steps.d/2375_build-arm64-fs detected!
dist_build_version: 16.0.4.2
whonix_build_error_counter: 1
benchmark: 00:00:09
last_failed_exit_code: 127
trap_signal_type_previous: unset
trap_signal_type_last : ERR
process_backtrace_result:
1: : init
2: : sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
3: : sshd: debian [priv]
4: : sshd: debian@pts/0
5: : -bash
6: : sudo /home/debian/Whonix/whonix_build --flavor whonix-gateway-xfce --target utm --arch arm64 --build --tb open
7: : /bin/bash /home/debian/Whonix/whonix_build --flavor whonix-gateway-xfce --target utm --arch arm64 --build --tb open
8: : /bin/bash ././build-steps.d/2375_build-arm64-fs
function_trace_result:
main (line number: 102)
main (line number: 96)
build_arm64_fs (line number: 48)
errorhandlergeneral (line number: 379)
errorhandlerprocessshared (line number: 208)
last_failed_bash_command: mkfs.vfat -n EFI "${dev}p1"
############################################################
Still not sure what to do after reading this error. Have retried with r many times with the same result.
The build succeeded after I installed xfce! (and booted into the DE but don’t know if that was necessary). I guess it needed the xfce packages, makes sense in hindsight.
Shouldn’t be needed.
For CLI builds to see the full build log, see:
(added just now)
Build Logs
You’d still need to scroll up more to that place where that command is actually run and possibly more. Easiest might be to share the full build log.
(Pasting Logs for Support)
Seems also very much unrelated to Xfce vs CLI.
Hi guys! Thought I’d just post a little update here. Sorry for leaving this after just about getting it working. I had a lot going on over the last few months.
Anyway, I’d really like to get this into a very stable state, with “official” UTM bundles for Whonix.
I’ve opened a PR in grml-debootstrap for arm64 support. This would allow us to greatly reduce any arm64 specifics in the Whonix buildscripts. Although they will require a few small changes, but with more removing of code than addition.
Once that gets merged, I’ll happily work towards a simple process for running Whonix via UTM. Eventually, my plan is to also get this working on x86_64 macOS because then we can use all FOSS to boot Whonix on macOS, for all architectures.
Excellent! Thanks for the update!
Linux is being ported to the Apple Silicon and it already works with some limitations. Apparently KVM also works so Whonix built for aarch64 should also work on Linux on Apple Silicon Macs. It is easy to set up a dual boot with Linux and MacOS so this is also an option for people who prefer Linux as a host OS
Yes, I’m also dual booting Asahi Linux and playing with it. That’s actually what prompted me to revisit this.
Once we update the Whonix buildscripts to depend on a grml-debootstrap that supports aarch64 I think we can easily make sure it works nicely on Linux with KVM too. In theory, it should already be possible but it’s just a bit messy the way we re-do the partitions in the arm specific build script (2375_build-arm64-fs).
I never used KVM and I tried to make it work on Asahi Linux but I could not manage to set up a Linux VM properly to get it to boot, but I’m pretty sure it is possible. Thanks a lot for continuing work on this!
I bumped into a challenge when building for Apple Silicon based on this well written guide from @Goldeneye128 (post 232).
The repo and build is based on monero-wallet-gui for x86/64. Removing the package after deployment alters the dummy-dependencies. I also tried to pre-build monero from source to ARM64 before building Whonix (not compliant with sanity-tests), and there are eventually missing dependencies with the precompiled monero bins after the image is compiled and booted.
Anyone found a solution for this issue?
So with direct gpg signratures on ARM64 Tor browser does that mean there is no need to manually download tor browser anymore? Or has it yet to be implemented?
Kinda interested to do another build run of this project again. Maybe update the guide.
Also @Miraculix mention something about monero-waller-gui problems?