The instructions were clear and everything works like a charm EXCEPT the Monero GUI.
When I click on it from the menu, nothing happens.
When I try to run it from the shell, I get:
bash: /usr/bin/monero-wallet-gui: cannot execute binary file: Exec format error
I tried:
updating the package from the default repo
purging, then installing the package from the kicksecure tor repo
building the package from the kicksecure source code
Nothing works.
FYI the command file returns:
/usr/bin/monero-wallet-gui: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=e0b2320c6a54c6780ee7c5121a7d12c6be6a6dbd, with debug_info, not stripped
While it should be ARM… and that’s for every test.
Did you achieve to make it work on your M1 machine? What can I try to do?
I believe the issue was with copying the tar.gz over. It didn’t copy the image over as well so I just copied the uncompressed folder and it worked just fine. Thank you.
I built mine from the stable version about a year ago. It worked great, except for crashes when using the GPU-accelerated drivers with gl in the name. I stopped using those and have been updating with upgrade-nonroot. UTM just released a version that is supposed to fix most of those crashes 4.1.5. Now when I try to use the GPU-accelerated drivers it will show the background, but will not load the desktop or taskbar.
Is anyone successfully using the new UTM and the GPU-accelerated drivers?
As a note, the new UTM and GPU-accelerated drivers work fine with a Debian buster guest machine.
run xfwm4-tweaks-settings in the VM, select the “Compositor” tab, and uncheck “Enable display compositing”. Then shut down the VM and re-enable
Apparently the compositor does not play nice with virgl drivers. There is a bug report filed, but it doesn’t seem to be going anywhere. Performing the above steps allows you to use the GPU-accelerated drivers (at least tested with the ramfb gl driver).
Seem to have an issue cloning any repo because “packages/kicksecure/monero-gui” requires gitlab access approval. I don’t remember this ever being an issue.
fatal: Authentication failed for 'https://gitlab.com/kicksecure/monero-gui.git/'
fatal: clone of 'https://gitlab.com/kicksecure/monero-gui.git' into submodule path '/home/snip/derivative-maker/packages/kicksecure/monero-gui' failed
Failed to clone 'packages/kicksecure/monero-gui' a second time, aborting
Yeah seems like i cannot build the project anymore either. Any hope that this could be fixed so we who build the project for macos silicon can still use this?
Thanks to @b4sh, the whole process was clear and simple. I used this to fetch the source: git clone --depth=1 --jobs=4 --recurse-submodules --shallow-submodules https://github.com/Whonix/derivative-maker.git
And executed the two commands from wiki/MacOS#M1:
~/derivative-maker/derivative-maker --flavor whonix-gateway-xfce --target utm --arch arm64 --build --tb open
~/derivative-maker/derivative-maker --flavor whonix-workstation-xfce --target utm --arch arm64 --build --tb open
I’ve been facing this problem for several days now. Has anyone had this? I tried to reinstall the dependencies, but it doesn’t work.
The most interesting thing is that I managed to build a working Gateway without errors, but I don’t know how. After Gateway, I tried to build a Workstation, but it didn’t because of an error. Now the Gateway does not want to be built again. Hell…
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
libgtk2.0-dev : Depends: libpango1.0-dev (>= 1.20) but it is not going to be installed
Depends: libcairo2-dev (>= 1.6.4-6.1) but it is not going to be installed
libreoffice-common : Breaks: libreoffice-core (< 4:7.4~) but 1:7.0.4-4+deb11u7 is to be installed
libsemanage1 : Depends: libsemanage-common (= 3.1-1) but 3.4-1 is to be installed
python3-uno : Depends: libreoffice-core-nogui (= 4:7.4.5-3) but it is not going to be installed or
libreoffice-core (= 4:7.4.5-3) but 1:7.0.4-4+deb11u7 is to be installed
ure : Breaks: libreoffice-core (< 1:7.4.0~) but 1:7.0.4-4+deb11u7 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
++ exception_handler_general ERR
++ last_failed_exit_code=100
++ last_failed_bash_command='$SUDO_TO_ROOT apt-get ${APTGETOPT[@]} -o Dir::Etc::sourcelist="$dist_build_sources_list_primary" -o Dir::Etc::sourceparts="-" $apt_unattended_opts --no-install-recommends --yes install $packages_to_be_installed'
derivative-builder doesn’t contain textual strings such as libgtk, libcairo2 or libreoffice. It looks like you’re having general system configuration issues.
For debugging, try running this command:
sudo dpkg --audit
It is expected that there is no output.
But if dpkg shows something, this means that dpkg found a system configuration issue.
modified quote of the dpkg man page:
--audit
Performs database sanity and consistency checks for […] all packages. For example, searches for packages that have been installed only partially on your system or that have missing, wrong or obsolete control data or files. dpkg will suggest what to do with them to get them fixed.
The user must fix this issue before proceeding. These issue is most likely not caused by derivative-issue. This is most likely a general system configuration issue.
No, I’m trying to build 16.1.1.5-stable on the latest Bullseye Debian.
Yes, there is a problem with configuring fp-compiler-3.2.0:arm64 because of «Invalid floating point operation». I didn’t find any solutions, unfortunately. Yet.
Having the same issue with fp-compiler-3.2.0:arm64. Unable to complete build at this moment and have yet to find any solutions.
sudo dpkg --audit
The following packages are only half configured, probably due to problems
configuring them the first time. The configuration should be retried using
dpkg --configure <package> or the configure menu option in dselect:
fp-compiler-3.2.0:arm64 Free Pascal - compiler
sudo dpkg --configure fp-compiler-3.2.0:arm64
Setting up fp-compiler-3.2.0:arm64 (3.2.0+dfsg-12) ...
An unhandled exception occurred at $0000000000470960:
EInvalidOp: Invalid floating point operation
$0000000000470960
$0000000000472FC0
$0000000000472F04
$0000000000470FA8
$0000000000400EEC
$0000000000402ACC
$0000FFFF99446E18
$0000000000400668
dpkg: error processing package fp-compiler-3.2.0:arm64 (--configure):
installed fp-compiler-3.2.0:arm64 package post-installation script subprocess returned error exit status 217
Errors were encountered while processing:
fp-compiler-3.2.0:arm64
Hello! I found an issue in pascal’s source repository (idk if it’s you or not). I joined the discussion, tried to build from source. See:
3.2.0 can’t be built and as of now, I haven’t found any solution. If you use emulated arm64 in utm, then 3.2.0 builds, but the system is very slow (building of whonix-gateway took 6+ hours versus ~1h on native m1 pro).
3.2.2 builds like a charm from source, but I haven’t managed to install it from backports (for some reason apt still picks 3.2.0 AND 3.2.2 despite the priorities in preferences).
Seems that maintainer of fpc suggests just to install fpc 3.2.2.