[MacPorts] #67731: podman machine does not startup on the arm64

[MacPorts]

#67731: podman machine does not startup on the arm64
---------------------------+----------------------
  Reporter:  langerma      |      Owner:  judaew
      Type:  defect        |     Status:  assigned
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:
Resolution:                |   Keywords:  arm64
      Port:  podman, qemu  |
---------------------------+----------------------

Comment (by thestr4ng3r):

 The issue is that /opt/local/share/qemu/edk2-aarch64-code.fd has
 transparent APFS compression. Using afscompress (from the port of the same
 name), it is possible to check the status and decompress it:
 {{{
 $ afscompress -l /opt/local/share/qemu/edk2-aarch64-code.fd
 /opt/local/share/qemu/edk2-aarch64-code.fd is HFS+/APFS compressed.
 $ sudo afscompress -d /opt/local/share/qemu/edk2-aarch64-code.fd
 $ afscompress -l /opt/local/share/qemu/edk2-aarch64-code.fd
 /opt/local/share/qemu/edk2-aarch64-code.fd is not HFS+/APFS compressed.
 }}}
 after that, podman works again.

 I had started to diagnose this problem over a month ago, but then forgot
 about it, only to hit the same issue again today. Iirc the difference was
 the return value of an lseek call in block/file-posix.c of qemu used to
 determine whether to consider a range from a file as just 0s. I think this
 one, or the one directly before it: https://gitlab.com/qemu-
 project/qemu/-/blob/0d52116fd82cdd1f4a88837336af5b6290c364a4/block/file-
 posix.c#L3136.\\
 The return value that was given for the compressed file made qemu map only
 0s instead of the actual firmware contents, so it would not boot.

 This should probably be reported upstream with a small reproducer, but
 macports could also make sure the installed firmwares in
 /opt/local/share/qemu do not use compression.

-- 
Ticket URL: <https://trac.macports.org/ticket/67731#comment:14>
MacPorts <https://www.macports.org/>
Ports system for macOS