Use x86_64 Docker containers in Linux VMs on Apple silicon

Never mind. I don't have "pro."

 

Can you please confirm the version of the Parallels Desktop you have installed? this is only available on 19.0 and above

 

still broken in kernel 6.5.3

 

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).

 

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.

 

Hi Mikhail,
I just restarted Parallels Desktop, and now the "Download Ubuntu with x86_64 emulation" options appears.

 

I followed Parallels' requirements and downloaded an Ubuntu system with x86_64 emulation capability, but I still receive an architecture mismatch error when running an x86 Docker image.

 

Greetings!
Can I run x86 applications via Parallels Desktop? Correctly, I set up everything, as said in this article, but I get error "cannot execute binary file: Exec format error".

 

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.

 

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!

 

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.

 

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:

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?

 

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.

 

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...

​

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.