Haiku qemu boot failure(s)

Development OS
1

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
  • boot

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…

2

Your qemu command is long. Have you tried to start with a minimal qemu config and then extending it step-by-step to find out which part causes the issue?

4 Likes
3

OK, minor progress with hrev 57078. Both ISO and installed HD will boot, but only if I use IDE and connect to the VM’s serial console.

Perhaps part of the problem is that if I use SCSI or VIRTIO, Haiku finds an AHCI device and immediately forgets that it was using SCSI or VIRTIO. It may be that the problem is partly with qemu (and qemu’s miserable documentation). Except that only Haiku has this problem. I’ll keep futzing with the syntax; maybe I’ll get lucky and stumble upon a combination that works (and doesn’t mess up my other VMs).

One question remains: why does Haiku boot only when the serial console is active/available? … Oh. If I let qemu ‘autoboot’, the ISO boots up OK. But if I hit and choose the ISO, it hangs after ‘done trampolining’ unless the serial console is active. Curiouser, when qemu ‘autoboots’ the ISO, the Haiku boot loader doesn’t appear. But when I and choose either HD or ISO, the boot loader appears. Might there be something odd with how qemu sends boot info to Haiku, or how Haiku interprets that info? ‘Autoboot’ to HD doesn’t work; SeaBIOS sees no bootable drive and it falls through to PXE. Is there a difference between Haiku’s boot loader on ISO and HD ?

Other minor problem: if there isn’t much RAM (like 128MiB) in the VM, Haiku will loop (seemingly forever) trying to allocate memory. It probably should give up sooner, or know that available RAM is too small for Haiku to run and go on strike.

1 Like
4

Did you try booting without the -machine type=q35 option? this
is known to cause boot issues on haiku, at least for me, not specifying any machine type solved my boot issues in the past, worth a shot.

5

I use UEFI but here is my “test in qemu” script:

#!/bin/bash

qemu-system-x86_64 -cpu host -machine q35 -monitor stdio \
	-m 4G -enable-kvm -nodefaults -smp 2,cores=2 \
	-device virtio-vga,xres=1920,yres=1080,edid=on \
	-display gtk,grab-on-hover=on,zoom-to-fit=off \
	-netdev user,id=n1 -device virtio-net-pci,netdev=n1 \
	-usb -device usb-kbd -device usb-tablet \
	-debugcon file:debug.log -global isa-debugcon.iobase=0x402 \
	-drive if=pflash,format=raw,unit=0,readonly=on,file=OVMF_CODE.fd \
	-drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd \
	-drive file=haiku-nightly-anyboot.iso,media=cdrom,aio=native,cache.direct=on #\
#	-drive file=hd.2GB,media=disk,if=virtio,format=raw

pflash lines is to use UEFI instead of seabios
I commented out a drive image, and havn’t used it in a while. (Also added media=disk to make it more proper).

6

On nightlies there is serial logging enabled oy default and that may not work if the serial port is partially present or completely missing.

Scsi and virtio disks are not well supported. Usind ahci will have less problems.

The boot process is nothing special, there is a master boot record in the partition table that behaves as in most other os: find the active partition and run its partition boot loader. There is no info to pass from qemu to haiku here. For this to work the partition table must be set up properly, so you should check that (I think it is documented in the installation guide)

The iso additionally is set up for “el torrito” booting, so it can be booted from a cdrom. Probably not useful in qemu.

7

I don’t know if this is actually true anymore? I think the package build VMs are entirely virtio disks.

8

And there is also a EFI system partition and app, if you boot with UEFI firmware.

1 Like