Instances won't start on Apple M3 silicon

[ricab]

          Hello,

I've got a similar issue at least with the "multipass start" command hanging.

I've installed, uninstalled, reinstalled both 1.12.2+mac and 1.13.0-dev.298.ci4858+g5236ad09.mac.

The interesting thing (maybe, as not an expert!) is that in 1.13.0 you see some additional logging and after where it usually hangs we get "Cannot open dhcpd_leases file: No such file or directory".

I've tried creating dhcpd_leases and it still fails as usual after some time but no longer reports that it can't open the file.

I assume it's looking for something useful to be added to that file by the DHCP but it never is and that's what causes the issue? I have restarted the daemons several times, rebooted, anything I can try!

sudo launchctl unload /Library/LaunchDaemons/com.canonical.multipassd.plist
sudo launchctl load /Library/LaunchDaemons/com.canonical.multipassd.plist 

It's a new machine (mbp m3) with the latest os (14.1.1). One of my team got their m2 running this last week with exactly the same setup and no issues here. We have had trouble in the past with the firewall on, but its not turned on my machine.

Any thoughts? Thank you, Jeremy

[2023-11-17T12:44:06.538] [debug] [primary] process working dir ''
[2023-11-17T12:44:06.538] [info] [primary] process program 'qemu-system-aarch64'
[2023-11-17T12:44:06.538] [info] [primary] process arguments '-machine, virt,gic-version=3, -accel, hvf, -drive, file=/Library/Application Support/com.canonical.multipass/bin/../Resources/qemu/edk2-aarch64-code.fd,if=pflash,format=raw,readonly=on, -cpu, host, -nic, vmnet-shared,model=virtio-net-pci,mac=52:54:00:ef:35:6a, -device, virtio-scsi-pci,id=scsi0, -drive, file=/var/root/Library/Application Support/multipassd/qemu/vault/instances/primary/ubuntu-22.04-server-cloudimg-arm64.img,if=none,format=qcow2,discard=unmap,id=hda, -device, scsi-hd,drive=hda,bus=scsi0.0, -smp, 1, -m, 1024M, -qmp, stdio, -chardev, null,id=char0, -serial, chardev:char0, -nographic, -cdrom, /var/root/Library/Application Support/multipassd/qemu/vault/instances/primary/cloud-init-config.iso'
[2023-11-17T12:44:06.550] [debug] [qemu-system-aarch64] [936] started: qemu-system-aarch64 -machine virt,gic-version=3 -nographic -dump-vmstate /private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/multipassd.zzapSp
[2023-11-17T12:44:06.723] [info] [primary] process state changed to Starting
[2023-11-17T12:44:06.726] [info] [primary] process state changed to Running
[2023-11-17T12:44:06.726] [debug] [qemu-system-aarch64] [937] started: qemu-system-aarch64 -machine virt,gic-version=3 -accel hvf -drive file=/Library/Application Support/com.canonical.multipass/bin/../Resources/qemu/edk2-aarch64-code.fd,if=pflash,format=raw,readonly=on -cpu host -nic vmnet-shared,model=virtio-net-pci,mac=52:54:00:ef:35:6a -device virtio-scsi-pci,id=scsi0 -drive file=/var/root/Library/Application Support/multipassd/qemu/vault/instances/primary/ubuntu-22.04-server-cloudimg-arm64.img,if=none,format=qcow2,discard=unmap,id=hda -device scsi-hd,drive=hda,bus=scsi0.0 -smp 1 -m 1024M -qmp stdio -chardev null,id=char0 -serial chardev:char0 -nographic -cdrom /var/root/Library/Application Support/multipassd/qemu/vault/instances/primary/cloud-init-config.iso
[2023-11-17T12:44:06.726] [info] [primary] process started
[2023-11-17T12:44:06.726] [debug] [primary] Waiting for SSH to be up
[2023-11-17T12:44:06.726] [warning] [primary] Cannot open dhcpd_leases file: No such file or directory
[2023-11-17T12:44:07.010] [debug] [primary] QMP: {"QMP": {"version": {"qemu": {"micro": 0, "minor": 0, "major": 8}, "package": ""}, "capabilities": ["oob"]}}

[2023-11-17T12:44:07.059] [debug] [primary] QMP: {"return": {}}

[2023-11-17T12:44:07.766] [warning] [primary] Cannot open dhcpd_leases file: No such file or directory
[2023-11-17T12:44:08.841] [warning] [primary] Cannot open dhcpd_leases file: No such file or directory
[2023-11-17T12:44:09.916] [warning] [primary] Cannot open dhcpd_leases file: No such file or directory
[2023-11-17T12:44:10.991] [warning] [primary] Cannot open dhcpd_leases file: No such file or directory
[2023-11-17T12:44:12.066] [warning] [primary] Cannot open dhcpd_leases file: No such file or directory

Originally posted by @jwynharris in https://github.com/canonical/multipass/issues/3303#issuecomment-1815509746

[ricab]

Hi @jwynharris, for some reason DHCP isn't working for you and instances don't get an IP address (which they need for the start procedure to complete). There could be multiple reasons for that.

One frequent cause is that the macOS firewall sometimes blocks its own bootpd process. This is extensively discussed in #2387 and unfortunately there isn't much we can do about it (other than offer workarounds). Hopefully, if enough people report this problem to Apple, they will come to fix it?

If that is not your case, there are a few other possible causes for this, mostly documented here. Please try those suggestions and let us know how it goes for you.

[jwynharris]

Hi @ricab, thank you for your help.

To Reproduce

1) Complete fresh install on a MBP (M3) running Sonoma 14.1.1. Unmanaged, defaults with firewall off, has one wifi network connection. Nothing else added. No VPN, no nothing!

2) Download and install the latest Mutlipass dmg (version 1.12.2). I did not install brew or anything as wanted to keep it as clean as possible.

Expected behaviour

To run multipass launch and it to successfully spin up a VM

Additional info

BTW I installed multipass on my older Intel mac (also running Somona 14.1.1) just before - and it working straight away. Super weird stuff Apple! This shows useful stuff in the dhcpd_leases file so pretty sure the problem is with getting dhcp to play ball on apple silicon.

Additional context

Last line of the log is: [2023-11-17T12:44:07.059] [debug] [primary] QMP: {"return": {}}

I note in most other peoples reports that the last line they see is more more step and something like: '[2022-01-04T13:31:08.663] [debug] [dbarn] QMP: {"timestamp": {"seconds": 1641321068, "microseconds": 663550}, "event": "NIC_RX_FILTER_CHANGED", "data": {"path": "/machine/unattached/device[7]/virtio-backend"}}'

I've never seen this line.

So I have also tried:

1) Rebooting (lots of times)

2) Restarting mutlipass / making sure the daemon is running:

sudo launchctl unload /Library/LaunchDaemons/com.canonical.multipassd.plist
sudo launchctl load /Library/LaunchDaemons/com.canonical.multipassd.plist

3) Reinstalling multipass (both 1.12.2 and the 1.13.0 dev version)

4) Restarting the firewall (which shows as off in the UI in any case as my machine is currently unmanaged)

/usr/libexec/ApplicationFirewall/socketfilterfw --add /usr/libexec/bootpd
/usr/libexec/ApplicationFirewall/socketfilterfw --unblock /usr/libexec/bootpd

5) On a previous not quite as clean install, I also tried installing OnyX (https://github.com/canonical/multipass/issues/2387 and https://github.com/canonical/multipass/issues/3003) and ran cleanups to see if this helped. It did not unfortunately.

6) It appears that the DCHP is not running as per https://multipass.run/docs/troubleshoot-networking#heading--troubleshooting:

I see that since version 14 (https://github.com/canonical/multipass/issues/3209) you can't enable it usingsudo launchctl load -w /System/Library/LaunchDaemons/bootps.plist - it just returns "Load failed: 5: Input/output error Try running launchctl bootstrap as root for richer errors." and also suspect this has been changed for security reasons.

---

Generally looks like /var/db/dhcpd_leases is never touched or ever exists on my machine. So I think you are right in that no IP address can be assigned (by dhcp) and then picked up by the VM. Since the dhcp daemon is not running as abive, maybe the default setup needs me to do something like turn on Internet Sharing to allow the dhcp service to run?

Ok, so I've just triedsudo /bin/launchctl kickstart -kp system/com.apple.bootpd and now I have this:

Let me post this, reinstall multipass, reboot, maybe kickstart bootpd and see what happens... UPDATE - it did not help :(

After reboot, I kickstarted com.apple.bootpd, ran multipass launch, and still no luck.

---

I will report this problem to apple as you suggest.

[jwynharris]

I've also just updated to Sonoma 14.2 Beta (23C5047e), in the hope this would fix. No luck unfortunately..

[hefan]

Same Problem here with Sonoma 14.1.1, multipass 1.12.2. no firewall, no VPN.

[jwynharris]

Also.. my managed 2019 Intel MBP with Sonoma 14.0 works well. It's even got the firewall turned on. I just updated this 2019 machine to 14.1.1 to see if it was the OS version - and it still works.

So in summary I have two machines, and others in my team have other machines: 1) Managed 2019 Intel MBP which has run both Sonoma 14.0 and 14.1.1. WORKED! Screen shots below are from the networking config. 2) 2023 M3 MBP which has run (clean install, default setup) which has run both Sonoma 14.1.1 and now 14.2 beta 3. DOES NOT WORK :( 3) ... also a developer in my team installed Multipass on their 2023 M2 MBP last week on a fresh install and this WORKED.

Could it be the m3? Makes no sense!

[jwynharris]

Given that on my small sample of working on m2 and intel but not on m3, I wondering if maybe some difference in hardware was causing the issue?

So I setup a ethernet network to see if it would work on the intel and m3 machine.

1) intel - works on ethernet (as it did with wifi). 2) m3 - NO luck on ethernet :(

However I did notice something interesting between these two setups. On the m3 I see this in the logs:

However on the intel:

Note that there is no mention of multipass or multipassd in the Intel launchd.log file (remember the intel version works).

Maybe something to do with how the processes run or something and this is causing the issue??

[nktpro]

Just wanted to add one more data point here: I could also confirm exactly what @jwynharris was seeing.

I just transitioned from a M2 (Max) MBP to the new M3 (Max), both with Firewall disabled. multipass has been working perfectly on the M2 machine for a long time, but could not launch/start instances on the M3. My observations of multipassd logs matched what @jwynharris reported.

[jwynharris]

Hi @ricab,

I suspect this is a new / different issue. Do you or someone else familiar with the code base have access to an M3 that can debug this specific issue?

Then if it is something weird with Apple's networking / drivers / hardware then I can submit another bug request with more detail, as can others.

Happy to help as I can as I am keen to solve this for me and anyone else with an M3.

Also I would be interested to hear if there is anyone reading this who has an M3 and is NOT experiencing this issue (as currently assuming everyone will).

Thank you, Jeremy

[hefan]

To also be more precise: Same Problem here with new iMac M3 Sonoma 14.1.1, multipass 1.12.2. no firewall, no VPN. No Problem with Macbook Air M1 Sonoma 14.1.1, multipass 1.12.2. no firewall, no VPN.

[townsend2010]

Hello All,

I'm convinced this is not the dreaded Apple Firewall issue and is appearing more likely to be a lack of M3 support in this version of QEMU that is in our latest package. Unfortunately, no one on the Multipass Team has an M3-based Mac yet. That said, I would like to see what is happening in the boot process.

@jwynharris, since you've been investigating this quite a bit, could I please ask you to do the following?

First, make sure all qemu-system-aarch64 processes are not running. The easy way is to issue:

$ sudo killall -9 qemu-system-aarch64

Then run the following command in the terminal:

$ sudo /Library/Application\ Support/com.canonical.multipass/bin/qemu-system-aarch64 -machine virt,gic-version=3 -accel hvf -drive file=/Library/Application\ Support/com.canonical.multipass/bin/../Resources/qemu/edk2-aarch64-code.fd,if=pflash,format=raw,readonly=on -cpu host -nic vmnet-shared,model=virtio-net-pci,mac=52:54:00:ef:35:6a -device virtio-scsi-pci,id=scsi0 -drive file=/var/root/Library/Application\ Support/multipassd/qemu/vault/instances/primary/ubuntu-22.04-server-cloudimg-arm64.img,if=none,format=qcow2,discard=unmap,id=hda -device scsi-hd,drive=hda,bus=scsi0.0 -smp 1 -m 1024M -qmp stdio -cdrom /var/root/Library/Application\ Support/multipassd/qemu/vault/instances/primary/cloud-init-config.iso

The preceding assumes an instance named primary already exists. Also could you please get a screen grab of the QEMU window and attach it to this bug?

In the meantime, I will work on updating our version of QEMU and get a test package built that can be tried.

Thank you!

[townsend2010]

From all indications, looks like the same issue afflicting lima-vm: https://github.com/lima-vm/lima/issues/1996

[jwynharris]

Hi @townsend2010

Thanks. Had to create an instance called primary with multipass set client.primary-name=primary. Which naturally didn't complete. After a while I rebooted and then ran your commands:

Here is the QEMU window:

It showed this straight away and didn't proceed or update after that.

Hope this helps!

[townsend2010]

Hi @jwynharris!

Thanks for this. It confirms the UEFI firmware that ships with at least the version of qemu in our released package has some incompatibility with the M3 hardware. I'm working on making a test package to see if there is an update to qemu that fixes this.

[townsend2010]

Hello again,

I have a test package here: https://multipass-ci.s3.amazonaws.com/pr568/multipass-1.13.0-dev.1245.pr568%2Bgf87e344db.mac-Darwin.pkg

I will say, that I'm not real hopeful that this will fix it because the EDK2 firmware in upstream QEMU is the same as in our release package and I believe the problem is with that. That said, perhaps there is a change in qemu itself that does indeed fix it, so :crossed_fingers:

Please let us know your results. Thanks!

[stevenschlansker]

I filed a seemingly-related issue here: https://gitlab.com/qemu-project/qemu/-/issues/1990

[townsend2010]

@stevenschlansker Thank you filing that upstream qemu issue! It is the same issue.

[jwynharris]

Hi @townsend2010

No luck unfortunately :(

Installed via the package, rebooted. Then ran. Log here:

[2023-11-22T09:27:55.493] [info] [daemon] Starting Multipass 1.13.0-dev.1245.pr568+gf87e344db.mac [2023-11-22T09:27:55.493] [info] [daemon] Daemon arguments: /Library/Application Support/com.canonical.multipass/bin/multipassd --verbosity debug [2023-11-22T09:28:04.239] [info] [daemon] Received signal 15 (Terminated: 15) [2023-11-22T09:28:04.271] [info] [daemon] Goodbye! [2023-11-22T09:29:07.904] [debug] [blueprint provider] Loading "anbox-cloud-appliance" v1 [2023-11-22T09:29:07.929] [debug] [blueprint provider] Loading "charm-dev" v1 [2023-11-22T09:29:07.932] [debug] [blueprint provider] Loading "docker" v1 [2023-11-22T09:29:07.934] [debug] [blueprint provider] Loading "jellyfin" v1 [2023-11-22T09:29:07.937] [debug] [blueprint provider] Loading "minikube" v1 [2023-11-22T09:29:07.938] [debug] [blueprint provider] Loading "ros-noetic" v1 [2023-11-22T09:29:07.942] [debug] [blueprint provider] Loading "ros2-humble" v1 [2023-11-22T09:29:07.958] [info] [rpc] gRPC listening on unix:/var/run/multipass_socket [2023-11-22T09:29:07.958] [debug] [async task] fetch manifest periodically [2023-11-22T09:29:07.968] [info] [VMImageHost] Did not find any supported products in "appliance" [2023-11-22T09:29:07.971] [debug] [qemu-img] [893] started: qemu-img snapshot -l /var/root/Library/Application Support/multipassd/qemu/vault/instances/primary/ubuntu-22.04-server-cloudimg-arm64.img [2023-11-22T09:29:08.016] [debug] [qemu-img] [895] started: qemu-img amend -o compat=1.1 /var/root/Library/Application Support/multipassd/qemu/vault/instances/primary/ubuntu-22.04-server-cloudimg-arm64.img [2023-11-22T09:29:08.032] [info] [daemon] Starting Multipass 1.13.0-dev.1245.pr568+gf87e344db.mac [2023-11-22T09:29:08.032] [info] [daemon] Daemon arguments: /Library/Application Support/com.canonical.multipass/bin/multipassd --verbosity debug [2023-11-22T09:29:08.900] [debug] [update] Latest Multipass release available is version 1.12.2 [2023-11-22T09:30:42.612] [debug] [qemu-system-aarch64] [3573] started: qemu-system-aarch64 --version [2023-11-22T09:30:44.097] [debug] [qemu-img] [3577] started: qemu-img info /var/root/Library/Caches/multipassd/qemu/vault/images/jammy-20231026/ubuntu-22.04-server-cloudimg-arm64.img [2023-11-22T09:30:44.111] [debug] [qemu-img] [3578] started: qemu-img resize /var/root/Library/Application Support/multipassd/qemu/vault/instances/warm-mantis/ubuntu-22.04-server-cloudimg-arm64.img 5368709120 [2023-11-22T09:30:44.124] [debug] [qemu-img] [3579] started: qemu-img snapshot -l /var/root/Library/Application Support/multipassd/qemu/vault/instances/warm-mantis/ubuntu-22.04-server-cloudimg-arm64.img [2023-11-22T09:30:44.130] [debug] [qemu-img] [3580] started: qemu-img amend -o compat=1.1 /var/root/Library/Application Support/multipassd/qemu/vault/instances/warm-mantis/ubuntu-22.04-server-cloudimg-arm64.img [2023-11-22T09:30:44.135] [debug] [warm-mantis] process working dir '' [2023-11-22T09:30:44.135] [info] [warm-mantis] process program 'qemu-system-aarch64' [2023-11-22T09:30:44.135] [info] [warm-mantis] process arguments '-machine, virt,gic-version=3, -accel, hvf, -drive, file=/Library/Application Support/com.canonical.multipass/bin/../Resources/qemu/edk2-aarch64-code.fd,if=pflash,format=raw,readonly=on, -cpu, host, -nic, vmnet-shared,model=virtio-net-pci,mac=52:54:00:94:56:5f, -device, virtio-scsi-pci,id=scsi0, -drive, file=/var/root/Library/Application Support/multipassd/qemu/vault/instances/warm-mantis/ubuntu-22.04-server-cloudimg-arm64.img,if=none,format=qcow2,discard=unmap,id=hda, -device, scsi-hd,drive=hda,bus=scsi0.0, -smp, 1, -m, 1024M, -qmp, stdio, -chardev, null,id=char0, -serial, chardev:char0, -nographic, -cdrom, /var/root/Library/Application Support/multipassd/qemu/vault/instances/warm-mantis/cloud-init-config.iso' [2023-11-22T09:30:44.137] [debug] [qemu-system-aarch64] [3581] started: qemu-system-aarch64 -machine virt,gic-version=3 -nographic -dump-vmstate /private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/multipassd.yoGQyp [2023-11-22T09:30:44.167] [info] [warm-mantis] process state changed to Starting [2023-11-22T09:30:44.170] [info] [warm-mantis] process state changed to Running [2023-11-22T09:30:44.170] [debug] [qemu-system-aarch64] [3582] started: qemu-system-aarch64 -machine virt,gic-version=3 -accel hvf -drive file=/Library/Application Support/com.canonical.multipass/bin/../Resources/qemu/edk2-aarch64-code.fd,if=pflash,format=raw,readonly=on -cpu host -nic vmnet-shared,model=virtio-net-pci,mac=52:54:00:94:56:5f -device virtio-scsi-pci,id=scsi0 -drive file=/var/root/Library/Application Support/multipassd/qemu/vault/instances/warm-mantis/ubuntu-22.04-server-cloudimg-arm64.img,if=none,format=qcow2,discard=unmap,id=hda -device scsi-hd,drive=hda,bus=scsi0.0 -smp 1 -m 1024M -qmp stdio -chardev null,id=char0 -serial chardev:char0 -nographic -cdrom /var/root/Library/Application Support/multipassd/qemu/vault/instances/warm-mantis/cloud-init-config.iso [2023-11-22T09:30:44.170] [info] [warm-mantis] process started [2023-11-22T09:30:44.171] [debug] [warm-mantis] Waiting for SSH to be up [2023-11-22T09:30:44.472] [debug] [warm-mantis] QMP: {"QMP": {"version": {"qemu": {"micro": 2, "minor": 1, "major": 8}, "package": ""}, "capabilities": ["oob"]}}

[2023-11-22T09:30:44.535] [debug] [warm-mantis] QMP: {"return": {}}

[townsend2010]

Hi @jwynharris,

Ok, I was afraid of that and is not unexpected. Thanks for trying and unfortunately, we'll just have to wait for upstream to figure out what the problem is.

[jwynharris]

Thanks for all your efforts so far @townsend2010. I assume they know there is an issue and working on a fix? I'll watch this thread so if any update please post here. Happy to test anything :)

[townsend2010]

I assume they know there is an issue and working on a fix?

Well, M3's have been out less than a month and the upstream bug was entered less than 24 hours ago (at the time of this writing), so they might be aware, but probably haven't started working on a fix I would say. I will monitor upstream and report here on any activity.

[upngo]

https://github.com/rancher-sandbox/rancher-desktop/issues/6006

Found this issue where someone alludes to M3 being incompatible with QEMU currently

[jwynharris]

Looks like some progress at https://gitlab.com/qemu-project/qemu/-/issues/1990 reported by @stevenschlansker?

[townsend2010]

Hello,

Here is a quick update to what is happening upstream regarding this issue. It appears there is already a fix in upstream EDK2 (the virtual UEFI firmware) and seems to fix it for M3 users. However, it looks like this same fix is not working reliably on M1 based machines. A developer seems to understand what is going on with this and has made a recommendation on how upstream QEMU should handle this, but there has been no activity after that. :slightly_smiling_face:

[Fred78290]

Probably it will better to use Apple Virtualization Framework rather than qemu. Rancher Desktop dit it and it works perfectly on my M3 Pro.

The x86_64 emulation is done via Rosetta2 thru the Virtualization Framework. Regards

[lunderhage]

@Fred78290 : I agree, but let's get what we have working first. I am sad I can't really put my shiny new M3 Max Macbook to business yet without a proper virtualization solution.

[jwynharris]

@lunderhage - yes, and I think multipass will perform better as not going through Rosetta2?

[lunderhage]

@jwynharris : Multipass instances through Rosetta2 is very useful as well, but the virtualization is a bliss in performance so I rather have that first.

[townsend2010]

Here is an update:

Seems upstream is having a difficult time trying to figure out the best way to handle this. You can follow their discussion on a proposed solution here: https://edk2.groups.io/g/devel/topic/102967690#112027

[jwynharris]

Looks like some discussion of a temp fork until proper solution at https://gitlab.com/qemu-project/qemu/-/issues/1990#note_1688592217?

[townsend2010]

Yep, but that's a pretty Big Hammer approach though. I will say, we are in the middle of preparing a Multipass release, but it won't be released until after the New Year. It's possible the final solution will be available by the time we release or shortly thereafter for a "bug fix" release.

[townsend2010]

Also, the upstream EDK2 discussion on how to handle this has gone quite silent- the last post was on Dec. 7.

[abach]

I found a workaround which apparently works on M3 with multipass 1.11.1: setting -cpu cortex-a72 makes it run. Whenever cpu is set as "host" it never starts.

[jwynharris]

Interesting, just looking now to see if I can run multipass 1.11.1 with setting -cpu cortex-a72. However I can't see in the documentation where to set the cpu? Can someone please point me to the documentation on how to set this? For example multipass launch --cpu cortex-a7 didnt work. Thanks in advance!

[jwynharris]

So figured out that this is a qemu setting. A collegue (m2 so it works for him) has his qemu settings in /var/root/Library/Application\ Support/multipassd/qemu/multipassd-vm-instances.json. However I dont have multipassd as a directory. Wonder if this is because its never run sucessfully before? Any thoughts welome!

[jklaff]

Just mentioning it here again as well, as it took me quite some time to find that info in a different issue:

v.1.11.1 seems to be working on an M3 so far https://github.com/canonical/multipass/releases/download/v1.11.1/multipass-1.11.1+mac-Darwin.pkg

[bdahan]

Just mentioning it here again as well, as it took me quite some time to find that info in a different issue:

v.1.11.1 seems to be working on an M3 so far https://github.com/canonical/multipass/releases/download/v1.11.1/multipass-1.11.1+mac-Darwin.pkg

Thank you, confirmed working on M3

[Fred78290]

Just mentioning it here again as well, as it took me quite some time to find that info in a different issue:

v.1.11.1 seems to be working on an M3 so far https://github.com/canonical/multipass/releases/download/v1.11.1/multipass-1.11.1+mac-Darwin.pkg

Thx confirmed works on macbook m3 pro.

[townsend2010]

Hi @jwynharris,

Sorry for the late reply, the whole team was away during the Holidays. Regarding the -cpu cortex-a72, version 1.11.x (and older) already has this coded in- nothing is needed on your end to use that parameter. If 1.11.1 is still not working for you, then I wonder if something else is going on.

[lunderhage]

Just mentioning it here again as well, as it took me quite some time to find that info in a different issue: v.1.11.1 seems to be working on an M3 so far https://github.com/canonical/multipass/releases/download/v1.11.1/multipass-1.11.1+mac-Darwin.pkg

Thx confirmed works on macbook m3 pro.

Yes, works!

[apiening]

multipass-1.11.1+mac-Darwin.pkg is working fine for me as well. Will 1.13.0 (which is currently an RC) include a fix so that this version works when it is released as stable? Or is this not yet clear?

[townsend2010]

Will 1.13.0 (which is currently an RC) include a fix so that this version works when it is released as stable?

No, it will not. The reason 1.11.x works is that we used -cpu cortex-a72 in that and previous versions, but per the advice of QEMU developers, -cpu host is recommended since the cortex-a72 CPU type is missing some macOS host virtualization features.

We are moving forward with the 1.13.0 release and when upstream QEMU has a proper fix in place, we will incorporate that as soon as possible and release a bug fix release.

[Fred78290]

Hi guys, After many hours to find a workaround to run multipass on apple silicon M3, I got it!

The problem is the default /Library/Application Support/com.canonical.multipass/Resources/qemu/edk2-aarch64-code.fd bios shipped with qemu is not compatible with apple silicon M3. The solution is to replace with the EFI bios used to build arm64 ubuntu image that we can found on running ARM64 ubuntu instance (raspi, multipass 1.11.x....) at this location /usr/share/qemu-efi-aarch64/QEMU_EFI.fd

Now how to install workaround

• Run an ARM64 ubuntu instance on raspi, aws, multipass, qemu on x86...
• Install qemu-efi sudo apt install qemu-efi
• Copy the file /usr/share/qemu-efi-aarch64/QEMU_EFI.fd to your Mac Apple Silicon
• list bytes of the file /Library/Application Support/com.canonical.multipass/Resources/qemu/edk2-aarch64-code.fd, mine is exactly 67108864 bytes. ls -l "/Library/Application Support/com.canonical.multipass/Resources/qemu/edk2-aarch64-code.fd"
• Set the size of the QEMU_EFI.fd to the size of edk2-aarch64-code.fd truncate -s 67108864 QEMU_EFI.fd
• Now copy to the final destination sudo cp QEMU_EFI.fd "/Library/Application Support/com.canonical.multipass/Resources/qemu/edk2-aarch64-code.fd"
• Restart multipassd service: Reboot :)

Voila

[jwynharris]

Woohoo! I think I've just got mine to work using 1.11.1 - but I needed to completely remove the old (aka newer) version which meant running 'brew uninstall --zap multipass' even though I installed via the package. In case anyone has the same issue! I'll see if I can actually use it now in a development environment.

[ricab]

@Fred78290, you should be able to download the package without a ubuntu instance here.

[jwynharris]

Can confirm that it's all working in a development environment using 1.11.1 for now. Thank you all.

[townsend2010]

Update:

Upstream edk2 has in place the fix for this. Upstream qemu very recently committed the change to pull in the upstream edk2 with the fix. I hope upstream qemu will shortly branch for the 8.2.1 bug fix and we can pick that up in our 1.13.1 bug fix release.

[jwynharris]

Nice!

[ssg3d]

@jwynharris thanks for the tip, I have a MacBookPro 16" with Apple M3 Pro chip running Sonoma 41.2.1 and Multipass 1.11.1 works. @townsend2010 I hope this will be fixed in 1.13.1 as I don't know if its good to be depending on an older version.

[townsend2010]

It appears upstream QEMU has now tagged v8.2.1, so I will begin incorporating that into the Multipass 1.13.1 release.

[townsend2010]

Hey all!

Here is a test package that hopefully works on all of the Apple silicon types: https://multipass-ci.s3.amazonaws.com/pr583/multipass-1.14.0-dev.1487.pr583%2Bgc432665bc.mac-Darwin.pkg

Please try it out and let us know. Thanks!