Run Haiku on linux using kvm/qemu

Hi. I’ve been trying, on and off, for a long time to boot a latest Haiku daily ISO using qemu on Linux.

I had a complicated reproduction done (akin to adjusting rabbit ears in olden times), then stumbled on a simple way to make booting fail or succeed

  • Start qemu.
  • Hit escape to get to its boot menu.
  • Hit 3 to boot from ISO.

This boot fails. If I hit almost any key other than 3 before the 3, the ISO boots and I can install. And this trick works for booting from the vHD.

Is this a qemu bug (qemu v3.1.0 on Debian Buster)? Does Haiku not initialize some bits of hardware? Does qemu not create some bits of virtual hardware?

The serial boot log is too long to include here.

Thanks,
Neal

Here’s the qemu command, split for readability:

qemu-system-x86_64 -nographic -machine accel=kvm -cpu host -smp 4
  -drive if=none,format=raw,file=/kvm/vdisk.d/haiku6.img,id=gvd0
    -device ide-hd,drive=gvd0,bus=ide.0,unit=0,serial=1310
  -drive if=none,format=raw,file=/kvm/iso.d/haiku-master-hrev55141-x86_64-anyboot.iso,id=gsr0,readonly
    -device ide-cd,drive=gsr0,bus=ide.1,unit=0,serial=1320
  -nic tap,ifname=tapRD0006,script=/etc/network/qemuUP,downscript=/etc/network/qemuDOWN,model=e1000,mac=52:54:00:00:06:00
  -vnc :6,share=ignore -device piix4-usb-uhci,id=uhci1 -nodefaults
  -name iso:Haiku6 -boot menu=on -m 2048 -vga std -rtc clock=vm,base=localtime
  -device usb-tablet,bus=uhci1.0
1 Like

There’s nothing in your command line arguments which jump out, but maybe try virt-manager? Should be in the Debian repo already. It’s a great GUI for managing qemu, I highly recommend it. Having used qemu a lot, I know it works fine with Haiku. Website: https://virt-manager.org/

I don’t think you can have -nographic
Here is a trimmed version of mine tested to work on Qemu 5.2 (Debian backport):

qemu-system-x86_64 -machine q35 -vga virtio -monitor stdio \
	-display gtk,grab-on-hover=on,zoom-to-fit=off \
	-nic user,model=virtio-net-pci -usb -device usb-tablet \
	-m 512M -cpu host -enable-kvm -nodefaults -smp 1,cores=1 \
	-drive file=haiku-nightly-anyboot.iso,media=cdrom

Machine q35 updates from ancient 90’s hw to mid 00’s hw. Better for UEFI, but probably always good.

2 Likes

Here is also my full version I use for UEFI boot testing, but you will need to know UEFI Shell and have UEFI fw to boot this:

qemu-system-x86_64 -cpu host -machine q35 -monitor stdio \
	-m 512M -enable-kvm -nodefaults -smp 1,cores=1 \
	-vga virtio -display gtk,grab-on-hover=on,zoom-to-fit=off \
	-nic user,model=virtio-net-pci -usb -device usb-kbd -device usb-tablet \
	-serial file:debug.log -global isa-debugcon.iobase=0x402 \
	-drive if=pflash,format=raw,unit=0,readonly,file=OVMF_CODE.fd \
	-drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd

-usb -device usb-kbd is very useful if you have problem with correct keyboard mapping like I do (Swedish keys)

Why so complicated? If it were me testing a Haiku Nightly real quick, I’d do something more like qemu-system-x86_64 --enable-kvm -m 2G -cdrom haiku-nightly-anyboot.iso -hda haiku-disk.qcow2 -vga std -soundhw ac97 -net nic,model=i82551 -boot d

Also, like @tqh mentioned too, why -nographic? Might not be starting (or starting headless) bc of that, also enable VT-x in your EFI and sudo apt install kvm && sudo reboot to get kvm working if you haven’t already; hope this helps :slight_smile:

[Replying to one response for brevity; I did read all the others to this point.]

It boots and runs the latest nightly fine, provided I type some other character before typing the number of the drive to boot from (vHD, vCD, CD, flash, etc.) And it boots Haiku fine when user interaction isn’t needed.

Oh: another data point. When I don’t type that extra character, the video console displays a few screens-worth of ‘debug’ data as Haiku boots, but doesn’t display that data otherwise.

It might be a qemu problem, but since other OSen don’t have a problem booting, I kind-of suspect Haiku doesn’t initialize something properly. It might be related to Haiku looking at the console for a ‘held’ character to see if it needs to alter its boot process.

The command is complicated because it is generated by my 500-odd line shell script I wrote to fire up VMs. It works for other OSen (various flavors of Linux, Windows (XP through Win10), and lets me connect to the virtual console remotely. I wrote the script mostly to test Smoothwall Express (up to four NICs). I code the NIC number and the VM number into the MAC address so I know which NIC and which VM the MAC addr belongs to. It also sets the SERIAL_ID of each drive I configure so I know which drive I’m working with. Yes, there may be some cruft in it still. I wrote the script some 10 years ago and’ve’d to greatly modify it over time to deal with changes to qemu’s options. Each VM’s config file is very short, less than 5 lines usually. Given an ISO image and an empty QCOW vHD, I can configure and start a VM in about a minute, connected to any combination of the four bridges on the host. (The bridges exist to facilitate testing IPsec VPNs on Smoothwall Express. Haiku is good for this because it boots quickly; I’ve had 10-20 Haiku VMs copying data back and forth through up to 10 or so Smoothwall Express VMs.)

N

Let’s break it up and see what each of these things do!

This sets qemu to emulate a more modern hardware chipset (the default is some 486 or early pentium machine). Haiku works a little bit better this way.

This uses a virtio display instead of emulating a video card and then going through its VESA BIOS. Slight simplification, but it can give some performance improvement.

This is more for developers: it allows to get qemu “monitor” into the terminal where you run it. The monitor allows to send debug commands and get some information about crashes and things like that.

This sets qemu to use GTK for showing its window. In gtk mode you can get a menu at the top of qemu with some useful options.

This sets a virtio network interface. Like for display, this is simpler than emulating a real network card, and so it is a bit better in terms of performance

This configures a tablet as the pointing device instead of a mouse. It allows to avoid qemu “grabbing” the mouse and you can easily move your mouse in and out of qemu

Sets the memory size, as the default is too small to boot Haiku

Lets all the features of your real CPU (AVX, SSE, …) be usable by the virtual machine

Enable virtualization which is a lot faster than the default emulation mode

7 Likes

Sorry it’s been so long. Been busy.

I’ve tried several ISOs since, including beta5 to little avail. However, I just tried HREV 58449. It boots much more reliably and more consistently in qemu. My observations:

  1. Booting the HD using VIRTIO, it pauses ‘a while’ after initing virtio_pci and publishing SCSI disk and SCSI CD, but it does finish booting. Without a serial port defined, it dumps all the boot msgs to (I presume) STDOUT or STDERR (the window where I run qemu). With a serial port defined, it dumps boot messages to that port with and without a connected telnet session.
  2. Booting the HD using emulated devices (with AHCI) with no serial or monitor ports, it behaves much the same as above but with a much shorter pause after initing the disks.
  3. Booting the HD using emulated devices (with either lsi53c895a or megasas-gen2 SCSI), booting fails, dropping into KDL and, oddly, ‘taking over’ the terminal where I ran qemu (I have to ‘kill -9’ the qemu process from another window, and ‘stty sane’ restores the shell). I suspect when KDL switches the console to text, it somehow emits something that affects the host’s shell. Re: switching the console to text: does it emit something, such as CTRL/E, that causes the terminal to transmit a report to the host? Haiku’s trying to initialize AHCI (which doesn’t exist) but doesn’t find the device. It may always try to init AHCI whether or not it exists. (I suspect Haiku doesn’t have drivers for the LSI or MEGASAS chips.)
  4. On the other hand, when booting the ISO (VIRTIO or AHCI) without a serial port, it hangs after printing some ‘kernel args’ ranges and a ‘kernel entry at …’ msg. With a serial port, it usually presents the Haiku Boot Loader; but sometimes it seems to interfere with (cancels?) qemu’s boot menu and jumps right into booting from HD. (And this cancellation supports my theory that something in Haiku emits ‘CTRL/E’. The response sent in is sometimes ‘1’ which will ‘cancel’ qemu’s boot menu and go right into booting the HD.)
  5. And OTOH, when booting the ISO with the LSI or MEGASAS, it drops into KDL, but does not affect the host’s shell.
  6. In all cases, there is no longer a race among starting qemu, telnetting to the serial port, and typing a character.
  7. Unrelated to booting, Network preferences is more stable (ISTR something about this in one of the monthly reports).

So, while there are still some oddities to figure out, Haiku (hrev 58449) now boots far better for me in qemu than it has for quite a while. I can actually use it again as endhosts to test Smoothwall Express.

Neal