podman/qemu: "podman machine start" fails with "Could not open 'edk2-aarch64-code.fd'"

[jrjsmrtn]

Hello...

I'm trying to use podman on a M1 Mac with Big Sur, and qemu is failing with a Could not open 'edk2-aarch64-code.fd': No such file or directory error message:

$ podman machine init
Downloading VM image: fedora-coreos-35.20211119.2.0-qemu.aarch64.qcow2.xz: done
Extracting compressed file

$ podman machine start
INFO[0000] waiting for clients...
INFO[0000] listening tcp://0.0.0.0:7777
INFO[0000] new connection from  to /var/folders/l0/kfvj485d0lq_0syf2b86b5rh0000gn/T/podman/qemu_podman-machine-default.sock
Waiting for VM ...
qemu-system-aarch64: -drive file=edk2-aarch64-code.fd,if=pflash,format=raw,readonly=on: Could not open 'edk2-aarch64-code.fd': No such file or directory
Error: dial unix /var/folders/l0/kfvj485d0lq_0syf2b86b5rh0000gn/T/podman/podman-machine-default_ready.sock: connect: connection refused
ERRO[0003] cannot receive packets from , disconnecting: cannot read size from socket: EOF
ERRO[0003] cannot read size from socket: EOF

I reinstalled both podman and qemu, with no changes. buildfromsource is set to always in my macports.conf.

Versions are:

• MacPorts 2.7.1
• macOS 11.6.1 20G224 on arm64
• Xcode 13.1 13A1030d
• qemu 6.1.0 (with cocoa, target_arm, target_i386, target_x86_64 and usb variants)
• podman 3.4.2

[judaew (Vadym-Valdis Yudaiev)]

I just saw that podman-machine should now work on M1. So I turned up the revision for podman to add dependencies now. For clarity issue, do you have gvisor-tap-vsock installed?

[jrjsmrtn]

For clarity issue, do you have gvisor-tap-vsock installed?

Yes, I do.

I just saw that podman-machine should now work on M1. So I turned up the revision for podman to add dependencies now.

Same result.

There is still a getEdk2CodeFd function missing a MacPorts path for QEMU:

--- pkg/machine/qemu/options_darwin_arm64.go.orig	2021-12-06 21:09:38.000000000 +0100
+++ pkg/machine/qemu/options_darwin_arm64.go	2021-12-06 21:16:09.000000000 +0100
@@ -45,6 +45,7 @@
  */
 func getEdk2CodeFd(name string) string {
 	dirs := []string{
+		"@@PREFIX@@/share/qemu",
 		"/usr/local/share/qemu",
 		"/opt/homebrew/share/qemu",
 	}

Patches are attached.

[jrjsmrtn]

That said, one problem down... found another one :-)

$ podman machine start
INFO[0000] waiting for clients...
INFO[0000] listening tcp://0.0.0.0:7777
INFO[0000] new connection from  to /var/folders/l0/kfvj485d0lq_0syf2b86b5rh0000gn/T/podman/qemu_podman-machine-default.sock
Waiting for VM ...
qemu-system-aarch64: -accel hvf: invalid accelerator hvf
qemu-system-aarch64: falling back to tcg

It freezes here.

[judaew (Vadym-Valdis Yudaiev)]

This error means that QEMU was built without hvf. The QEMU wiki mentions this feature as an accelerator that employs Hypervisor.framework.

• ​https://wiki.qemu.org/Features/HVF

As far as I understand it, it's a fork of QEMU by patchew. In this fork, I found mention of hvf in two branches of 2017 and 2020.

• ​https://github.com/patchew-project/qemu/tree/patchew/20170905035457.3753-1-Sergio.G.DelReal@gmail.com
• ​https://patchew.org/QEMU/20201130030723.78326-1-agraf@csgraf.de

I think in this code podman in this lines implies that if the first accelerator is not available, the program will use the next one. But in fact, the first one is always used.

• ​https://github.com/containers/podman/blob/7d290b3f6245d2bc68e3cb689c5b3252561ae566/pkg/machine/qemu/options_darwin_arm64.go#L16-L17

[judaew (Vadym-Valdis Yudaiev)]

jrjsmrtn thanks for the patch, I'll add it.

I added another patch that removes the hvf option from the list for arm64. QEMU in MacPorts is built without this feature anyway. I'm not even sure where it is available.

Can you check if the podman machine will work correctly with this patch?

[judaew (Vadym-Valdis Yudaiev)]

PR: ​https://github.com/macports/macports-ports/pull/13267

[Vadim-Valdis Yudaev <judaew@…>]

In 3d73dac96cd17e8787e3c62e6f748b9cc3a2af72/macports-ports (master):

podman: Update to 3.4.3 and add patch

CHANGES:

• Add patch patch-getEdk2CodeFd-for-MacPorts.diff for fix path to QEMU See #64131

[jrjsmrtn]

With the bump to 3.4.3 and both patches merged:

$ podman --version
podman version 3.4.3

$ podman --log-level info machine start
INFO[0000] podman filtering at log level info
INFO[0000] waiting for clients...
INFO[0000] listening tcp://127.0.0.1:7777
INFO[0000] new connection from  to /var/folders/l0/kfvj485d0lq_0syf2b86b5rh0000gn/T/podman/qemu_podman-machine-default.sock
Waiting for VM ...
2021/12/07 22:44:16 tcpproxy: for incoming conn [::1]:50823, error dialing "192.168.127.2:22": connect tcp 192.168.127.2:22: no route
2021/12/07 22:44:32 tcpproxy: for incoming conn [::1]:50826, error dialing "192.168.127.2:22": connect tcp 192.168.127.2:22: no route
2021/12/07 22:44:56 tcpproxy: for incoming conn [::1]:50841, error dialing "192.168.127.2:22": connect tcp 192.168.127.2:22: no route
Machine "podman-machine-default" started successfully

$ podman machine ssh
Connecting to vm podman-machine-default. To close connection, use `~.` or `exit`
Warning: Permanently added '[localhost]:50622' (ECDSA) to the list of known hosts.
Fedora CoreOS 35.20211203.2.1
Tracker: https://github.com/coreos/fedora-coreos-tracker
Discuss: https://discussion.fedoraproject.org/c/server/coreos/

Last login: Tue Dec  7 22:03:03 2021 from 192.168.127.1
[core@localhost ~]$

So far, so good...

The first podman machine start seems waaaay slower on my m1 than on my Intel Mac mini but the bios and images are of course different. I'll have a closer look.

In the meantime, this looks good to me, so: thanks ! :-)

[Vadim-Valdis Yudaev <judaew@…>]

In f871c6077c8723e051676f4a29a41a96c422f56f/macports-ports (master):

podman: Fix podman machine for M1

Closed: #64131

CHANGES:

• Add patch patch-remove-hvf-accel-option-for-qemu.diff for remove the hvf option from the list for arm64. Thus, the podman machine for M1 should work correctly.

[judaew (Vadym-Valdis Yudaiev)]

You're welcome!