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.
2 Likes
Excellent! Thanks for the update!
1 Like
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).
2 Likes
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!
1 Like
1 Like
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?
Indeed.
Untested by me but I guess there’s a good chance it will be already functional.
Please primarily in the wiki. Forums is very much unsuitable for this as it gets outdated after a while and horrible for users having to read through 250+ posts.
When i get the chance to build it first and make it work, then i can update the wiki guide.
But am i allowed to update the wiki guide?
Anyone know how to remove the monero-package from the package system without altering the dependencies? Then i can build from source for ARM64.
Are you sure that’s even an issue?
It’s already considered in the source code (dummy-dependency-hardened-monero-gui). Untested but has a good chance that would work.
Well when i try to purge out the package it will also remove non-qubes-whonix-workstation-xfce and non-qubes-whonix-workstation-xfce.
Example:
Not sure what you ment with this? More info needed to test your idea.
Invalid test. Please don’t start with the presumption there will be an issue without an actual build issue.
That wasn’t an issue for previous builds by others in this forum thread and probably won’t be one now. This isn’t the first port of Whonix to another architecture:
This is unrelated to development. More of meta packages usability issue / user support:
In short: install package dummy-dependency-hardened-monero-gui first.
For developers to look into it, search the source code for:
dummy-dependency-hardened-monero-gui
- Search the Source Code
- But download Whonix instead of Kicksecure source code.
- Search
-
Kicksecure
-
- Replace:
-
Whonix
- Search
-
kicksecure
-
- Replace:
-
kicksecure
UTM can make use of the Apple Virtualization Framework so this would allow running the official release of the Tor Browser with relatively small overhead on Whonix on M1 Macs.
Running Intel Binaries in Linux VMs with Rosetta | Apple Developer Documentation
That’s good to know. However hopefully not needed / this being a better solution:
ARM64 Tor Browser
Needless to say that this might be very useful for all sorts of other software unavailable for ARM64.
Been trying to rebuild this project and get some errors now on the 16.0.4.2-stable build.
https://notes.anonpaste.org/?8b4a13ab328ee51b#D5n9PYMUGB4TqUd4pDhKDuuFZHW3JTHTgdsa17pZMkGF
Here is the output of the build log.
Not sure what makes the build to fail.