Been having this problem for a long time. Currently on Debian bookworm. I suspect it’s a bug (Haiku/qemu/me), but figured I’d check here first to see if it’s been seen before.
Presently hrev56578+59 installed to virtual drive does boot with the work-around below. I can’t test hrev57078 ISO because it doesn’t boot, but that’ll be a different thread. I do have a console log of this failure.)
Hard drive booting gets to ‘done trampolining’ (on the VGA console) and hangs there with the CPU usage pegged out. I can work around it by performing a specific dance:
- start the VM
- hit to choose how to boot
- telnet to the virtual serial console
- select boot device
- continue booting
- choose HD device in Haiku’s chooser
Haiku used to boot on qemu for me. But at least several years back, it started doing this. It happens with emulated chipset Q35 and with the ancient PIIx4, whether I use virtio, IDE or SCSI, any Haiku ISO I use. Almost any other OS I try boots fine. I’ve been using my script for over 10 years to fire up VMs; only times I’ve had problems was when qemu options changed and I had to figure out the new syntax via trial & error.
This is the qemu command my script generates (I added the line breaks for readability):
qemu-system-x86_64 \ -nographic \ -machine type=q35,accel=kvm,smm=on \ -cpu host \ -smp 8 \ -device virtio-scsi-pci \ -drive if=none,file=haiku8.qcow2,index=0,id=gvd0 \ -device scsi-hd,serial=1110,drive=gvd0 \ -drive if=none,format=raw,file=haiku-r1beta4-x86_64-anyboot.iso,index=5,id=gsr0,readonly=on \ -device scsi-cd,drive=gsr0,serial=1120 \ -nic tap,ifname=tapRD0008,script=qemuUP,downscript=qemuDOWN,model=virtio-net-pci,mac=52:54:00:00:08:00 \ -serial tcp:127.1.8.1:23,server=on,wait=off,nodelay \ -chardev socket,id=mon_8,port=23,host=127.1.8.2,ipv4=on,server=on,wait=off,telnet=on \ -mon chardev=mon_8 \ -display vnc=:8,share=ignore \ -device qemu-xhci,id=xhci1 \ -nodefaults \ -name iso:Haiku8 \ -boot menu=on \ -m 4096 \ -vga std \ -rtc clock=vm,base=localtime \ -device usb-tablet,bus=xhci1.0
I don’t think I can provide a log of the VM’s serial console; connecting to it works around the problem. Unless y’all know of another way to get a console log.
Of course, if anyone has a working qemu command, I can adjust my script accordingly…