Mikhail Ushakov
Problem solver
This thread is created to share feedback regarding the feature to run x86_64 binaries in Linux VMs on Apple silicon.
Use x86_64 Docker containers in Linux VMs on Apple silicon
- Thread starter Mikhail Ushakov
- Start date
Carlos Lapao
Parallels Team
Can you please confirm the version of the Parallels Desktop you have installed? this is only available on 19.0 and above
The article https://kb.parallels.com/en/129871#section5 says the following under the section Setting up automatically:
To install it, open Control Center in Parallels Desktop > create a new virtual machine from the list of Free Systems and select Download Ubuntu with x86_64 emulation > click Continue to create and start the virtual machine.
But there is no "Download Ubuntu with x86_64 emulation" system in the "Create New" window, only "Download Ubuntu Linux". I'm running Parallels version 19.1.0 (54729) on a 2021 M1 Max MacBook Pro, macOS version 13.6.1 (22G313).
Mikhail Ushakov
Problem solver
Hello!
Would you share a screenshot and collect a technical report while the issue is being reproduced (click Parallels icon > Help > Send technical data > check "Attach screenshots..." > press Send Report)? Send the 9-digit ID of the report in your reply to this email, please.
I would like to second this. I tried Parallels for this specific reason. I can do most of what I need in docker, but there are a few things where I need to use a GUI and they require Linux (x86). I got docker with x11 forwarding to work, but that is a bit flakey. Also, I can get them to work in UTM with emulation, but the performance is painfully slow. If this worked well in Parallels, I would be a loyal customer. Unfortunately, without this, I don't have enough of a need for Parallels to justify paying for it.
FrancescoA12
Bit poster
Hello. I am using Ubuntu 22.04.2 (x86_64 emulation) and trying to install Ansys Mechanical. I have downloaded and unpacked the .tar and then tried to install via: sudo ./INSTALL as the installation bash file is INSTALL. I though get the error:
Rosetta error: failed to open elf at /lib64/ld-linux-x86-64.so.2
Trace/breakpoint trap (core dumped)
Trying to look that up online I could only find references to the same issue using docker but I wouldn't know how to port their solution to my problem. Any idea on how to solve this? Thanks in advance!
Rosetta error: failed to open elf at /lib64/ld-linux-x86-64.so.2
Trace/breakpoint trap (core dumped)
Trying to look that up online I could only find references to the same issue using docker but I wouldn't know how to port their solution to my problem. Any idea on how to solve this? Thanks in advance!
Hello,
I have the same issue as FransecoA12 with Ubuntu 22.04.2 (x86_64 emulation), the default provided version.
I have the kernel 5.15.0-91-generic
I needed to install efinity, Vivado but always have the same issue:
rosetta error: failed to open elf at /lib64/ld-linux-x86-64.so.2
How can we solve this to be able to use the Rosetta feature? It is really blocking to use many software, no chance other colleagues will use a Mac with M1-2 and pay a Parallel license if nothing changes.
I hope someone from Parallel support will answer as this seems to be a general issue, not related to a single software.
I have the same issue as FransecoA12 with Ubuntu 22.04.2 (x86_64 emulation), the default provided version.
I have the kernel 5.15.0-91-generic
I needed to install efinity, Vivado but always have the same issue:
rosetta error: failed to open elf at /lib64/ld-linux-x86-64.so.2
How can we solve this to be able to use the Rosetta feature? It is really blocking to use many software, no chance other colleagues will use a Mac with M1-2 and pay a Parallel license if nothing changes.
I hope someone from Parallel support will answer as this seems to be a general issue, not related to a single software.
Hi, I am running a NixOS guest on Parallels Desktop 19. All works fine (including guest tools); however, I am unable to use the Rosetta feature.
Here's my NixOS hardware-configuration.nix:
Here's my NixOS hardware-configuration.nix:
Code:
{ config, lib, pkgs, modulesPath, ... }:
{
imports = [
(modulesPath + "/profiles/qemu-guest.nix")
];
boot.initrd.availableKernelModules = [ "xhci_pci" "usbhid" "sr_mod" ];
boot.initrd.kernelModules = [ ];
boot.kernelModules = [ ];
boot.extraModulePackages = [ ];
fileSystems."/" =
{ device = "/dev/disk/by-uuid/52fe158d-0fe6-4c45-b1ea-bb60acff5115";
fsType = "ext4";
};
fileSystems."/boot/efi" =
{ device = "/dev/disk/by-uuid/A303-FF33";
fsType = "vfat";
};
swapDevices = [ ];
# Enables DHCP on each ethernet and wireless interface. In case of scripted networking
# (the default) this is the recommended approach. When using systemd-networkd it's
# still possible to use this option, but it's recommended to use it in conjunction
# with explicit per-interface declarations with `networking.interfaces.<interface>.useDHCP`.
networking.useDHCP = lib.mkDefault true;
# networking.interfaces.eth0.useDHCP = lib.mkDefault true;
nixpkgs.hostPlatform = lib.mkDefault "aarch64-linux";
hardware.parallels.enable = true;
nixpkgs.config.allowUnfreePredicate = pkg: builtins.elem (lib.getName pkg) [ "prl-tools" ];
# doesn't currently work with Parallels
# virtualisation.rosetta.enable = true;
}I am trying to execute FlywayDesktop in an ARM64 linux VM using the provided VM with x86_64 emulation. However, whenever I try and run the executable I get the error:
./'Flyway Desktop'
rosetta error: failed to open elf at /lib64/ld-linux-x86-64.so.2
Trace/breakpoint trap (core dumped)
I get similar style errors when trying to run PgAdmin4 (although this can be got round by running the containerized version). Is there any fix for this?
./'Flyway Desktop'
rosetta error: failed to open elf at /lib64/ld-linux-x86-64.so.2
Trace/breakpoint trap (core dumped)
I get similar style errors when trying to run PgAdmin4 (although this can be got round by running the containerized version). Is there any fix for this?
DaveTheWave
Bit poster
For those having issues with libs, get a statically compiled version and if you can't then do something like so.
mkdir /home/parallels/amd64
docker pull --platform linux/amd64 ubuntu:22.04
docker run --platform linux/amd64 -it -v /home/parallels/amd64:/mnt ubuntu:22.04
tar cf - /lib /lib32 /lib64 /usr/include /usr/lib /usr/local/lib /usr/lib64 /usr/lib32 /usr/local/include | tar xvf - -C /mnt/
You will need to fix the symbolic links since they point to the root and the root should be the location of where they are.
You can than link /lib64 to /home/parallels/amd64/lib64 (after fixing the links)
You will probably have to set your LD_LIBRARY_PATH as well to include any libraries from the amd64 path.
To parallels support it would be nice if somehow Rosetta could be configured so that it used an alternative library path that was rooted to another location e.g. /home/parallels/amd64 so apps could seamlessly deal with this mess.
mkdir /home/parallels/amd64
docker pull --platform linux/amd64 ubuntu:22.04
docker run --platform linux/amd64 -it -v /home/parallels/amd64:/mnt ubuntu:22.04
tar cf - /lib /lib32 /lib64 /usr/include /usr/lib /usr/local/lib /usr/lib64 /usr/lib32 /usr/local/include | tar xvf - -C /mnt/
You will need to fix the symbolic links since they point to the root and the root should be the location of where they are.
You can than link /lib64 to /home/parallels/amd64/lib64 (after fixing the links)
You will probably have to set your LD_LIBRARY_PATH as well to include any libraries from the amd64 path.
To parallels support it would be nice if somehow Rosetta could be configured so that it used an alternative library path that was rooted to another location e.g. /home/parallels/amd64 so apps could seamlessly deal with this mess.
I can get Docker to work most of the time. The main issue I'm having with Linux binaries is the AppImage format. An app I REALLY need to work on Parallels only has AppImage support. I tried to build a Docker image instead but couldn't get that to work either due to their ancient Docker docs. If I had any idea that giving away my still-powerful 2018 Intel MBPro would have been such a mistake I would have never done it...
Admittedly trying the above is a huge time sink, so it depends on how important your project is to you. But I'm nearing the point where I either need to run this stuff via a cloud instance, or buy another system, which is incredibly frustrating given that Apple's now releasing the M3 chip line.
Assuming anyone is interested in case I succeed, please let me know, and I'll update.
My next step to troubleshoot this packaged Linux binary issue - which I guess indicates that the AppImage format has the same issue as Snap - is a long-shot way to cross-compile the incompatible dependencies using the updated pkgs mentioned in this blog post. ARM support has improved enough that I've been able to manually build at least one app using gcc and make on the first attempt. Admittedly trying the above is a huge time sink, so it depends on how important your project is to you. But I'm nearing the point where I either need to run this stuff via a cloud instance, or buy another system, which is incredibly frustrating given that Apple's now releasing the M3 chip line.
Assuming anyone is interested in case I succeed, please let me know, and I'll update.
Rosetta support is implemented by mounting needed binaries to the VM guest. For Parallel tools, `prlfsmountd.service` is responsible for mounting Rosetta binaries to `/media/psf/RosettaLinux`.
I am also a NixOS user. Just did a quick look and found following error
Yet another NixOS user here
Rosetta support is implemented by mounting needed binaries to the VM guest. For Parallel tools, `prlfsmountd.service` is responsible for mounting Rosetta binaries to `/media/psf/RosettaLinux`. The rosetta module from nixpkgs is only designed for UTM.
A quick look on journal logs of `prlfsmountd.service` show:
```
Jul 27 23:16:03 focalors systemd[1]: Starting Parallels Guest File System Sharing Tool...
Jul 27 23:16:03 focalors systemd[1]: Started Parallels Guest File System Sharing Tool.
Jul 27 23:16:03 focalors prlfsmountd[909]: Successfully executed: 'do_mount RosettaLinux /media/psf/RosettaLinux' Output:
Jul 27 23:16:03 focalors prlfsmountd[909]: Failed to execute:'prlbinfmtconfig register RosettaLinux /media/psf/RosettaLinux/rosetta'. Retcode=127 Output: /nix/store/q2a7zbgwq90rqkr66f>
Jul 27 23:16:03 focalors prlfsmountd[909]: Successfully executed: 'do_mount Home /media/psf/Home' Output:
Jul 27 23:16:03 focalors prlfsmountd[909]: Successfully executed: 'do_mount iCloud /media/psf/iCloud' Output:
```
And I checked further that the binaries are correctly mounted at `/media/psf/RosettaLinux'`. The failure of `prlbinfmtconfig` caused the binary not "recognized" by the OS. But I guess that could be easily resolved slightly modifying the rosetta module: https://github.com/NixOS/nixpkgs/blob/nixos-24.05/nixos/modules/virtualisation/rosetta.nix, and use above mount point instead. I will further try out when I get more spare time.
Hi Adam, are you interested in testing this PR out if you are still on macOS 14? https://github.com/NixOS/nixpkgs/pull/334661
Seems like I am able to get rosetta binaries correctly registered in binfmt. But I am unable to verify it actually works due to I am currently running macOS 15.1 Beta. There seems to be some issue on this build as I am not even able to get Rosetta in the official Ubuntu image to work.