Opened 8 months ago

Last modified 3 weeks ago

#68146 new defect

qemu @8.0.4: Hangs when used by lima

Reported by: MidnightRocket Owned by:
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc:
Port: qemu, lima

Description

When using sysutils/lima qemu hangs when trying to boot a Debian based VM. This results in lima not able to successfully boot a Debian VM with qemu. Nothing is even written to the serial logs in $HOME/.lima/<INSTANCE>/serial.log . I suspect it has something to do with how Macports builds qemu, as using qemu binaries manually build from source works as intended.

Using lima binaries from github.com/lima-vm/lima/releases does not make a difference.

Steps to reproduce

  • Use limactl to create a debian vm
  • Make sure the vmType is qemu (set by default)
  • Start the vm with limactl start $name
  • Observe that limactl never reaches a successful boot

Current solutions

Current solution that I know of

  • Using qemu @7.1.0 works as intended.
  • Manually build qemu from source

My system:

macOS 13.5.1 22G90 x86_64
Xcode 14.3.1 14E300c

Change History (4)

comment:1 Changed 7 months ago by MidnightRocket

The problem persists with qemu @8.0.4 and lima @0.18.0

comment:2 Changed 7 months ago by mephaust (Paul Handly)

I think I have a handle on the problem and how to work around it - still digging into the proper fix.

Qemu VMs (and thus, lima) depend on EDK2 UEFI images, and these VMs don't boot very far at all if the UEFI image file is stored with APFS "transparent" compression. Uncompressing the file seems to work around the problem - I'm still looking into the proper fix.

To address this, I think we either need to figure out why Qemu's RAW mode mishandles APFS-compressed files (not so transparent after all, eh?) or why the image file's being transparently compressed in the first place. Or both!

Repro

 qemu-system-x86_64 -accel hvf -cpu host,-pdpe1gb -m 4096 -drive if=pflash,format=raw,readonly=on,unit=0,file=/opt/local/share/qemu/edk2-x86_64-code.fd -drive if=pflash,format=raw,readonly=on,unit=1,file=/opt/local/share/qemu/edk2-i386-vars.fd

Workaround

# install a CLI tool to inspect and modify APFS compression
> sudo port install afscompress
# check to see if UEFI image is compressed
> /opt/local/bin/afscompress -vl /opt/local/share/qemu/edk2-x86_64-code.fd 
/opt/local/share/qemu/edk2-x86_64-code.fd:
File is HFS+/APFS compressed.
Compression type: ZLIB in resource fork (4)
File content type: dyn.ah62d4rv4ge80q3a
File size (uncompressed; reported size by Mac OS 10.6+ Finder): 3653632 bytes / 3.7 MB (megabytes, base-10)
File size (compressed): 1789952 bytes / 1.7 MiB
Compression savings: 51.0%
Number of extended attributes: 0
Total size of extended attribute data: 0 bytes
Uncompressed file size reported in compressed header: 3653632 bytes

# decompress file (if compressed above)
> afscompress -vd /opt/local/share/qemu/edk2-x86_64-code.fd

For Lima specifically, I think you can also work around this by forcing VMs to use legacy BIOS mode.

comment:3 in reply to:  2 Changed 2 months ago by elventear (Pepe Barbe)

Replying to mephaust:

I think I have a handle on the problem and how to work around it - still digging into the proper fix. ...

Workaround

I was able to use this exact workaround and fix this issue that was plaguing me on macOS 14.4 / x86_64.

comment:4 Changed 3 weeks ago by elventear (Pepe Barbe)

qemu was recently updated to 9.0.0 and the issue persists. The workaround is still valid.

Note: See TracTickets for help on using tickets.