Haiku on an Optiplex 745

Greetings, i do hope that posts like these are allowed as being part of the general feedback or status of
Haiku when running it on actual hardware.

I have been monitoring haiku for a few years now, and never truly ran it in actual hardware out of safety concerns in terms of data loss or the possibility of having damaged partitions. A few days ago I installed Haiku on actual hardware as i am trusting it just enough to do so. And i do fully understand that Haiku is highly unfinished and is not ready for day to day, safe, desktop use.

The host hardware is a Dell Optiplex 745, with an MSI Geforce GT 710, 3 gigabytes of ram, and an old Intel Core 2 6400 CPU running at 2.13GHz. The screen is a generic full HD screen connected trough HDMI.

1: Installation

I downloaded a 64bit Nightly build and used DD on linux to write it to an USB 2.0 stick. Afterwards i booted Haiku from that USB stick to end up on a fully functional Haiku using the Vesa driver. I ran the installer and installed Haiku to the third partition of the second Sata HDD in my machine.

2: Chainbooting haiku trough grub

I use grub as my bootloader because i have many systems installed on this machine. Making grub chainload the haiku bootloader can be done by manually editing your grub.cfg which does not safeguard it from removing the haiku entry once grub gets updated, or by creating an extra grub configuration file which gets loaded into the main grub file.

#haiku OS
menuentry “Haiku” {
set root=(hd1,3)
chainloader +1

The root HDD in this case was hd1 (which is the second HDD) with partition 3.

3: Running haiku

For the past few days i was able to enjoy Haiku without many issues. Though being forced to use the Vesa driver for the graphical side has been a bit of a bother. The systems runs smoothly at a Full HD resolution, and tests show that haiku is even capable of running 720P video at a nice and smooth rate for as long as i set the display colors to 16 bits per pixel - to save some processing power.

The system is highly responsive and at first sight one wouldn’t even be able to notice that Haiku was running in Vesa mode. I have full audio support and can listen to movies or music. My MSI USB mouse works flawlessly, as does my Logitech USB keyboard.

The following is a screenshot of the running system:

General notes:

Haiku truly is on its way to reaching a better and more usable state. it is now at a point where it is becoming usable as compared to the crashing and freezing system which i ran in VM’s during the years .

The main issues i experience are purely based upon some missing drivers. the ones i miss the most are:

USB wifi dongles (on linux it works and is known as a: r8188eu), and Basic 2D acceleration on graphics cards starting with the Kepler architecture. If i remmeber correctly (i could be horribly wrong) one needs to not only activate the 2D acceleration but also need to initialise / push some data to the 3D acceleration before modern nvidia cards allow you to use the 2D accel.

The few crashes i experienced were not related to any hardware at all:

  • Writing to a read only filesystem: crashes the kernel
  • Deleting a file which was in use: crashed the kernel
  • The Qemu package which comes from the official repositories always crashes and complains about bitmap sizes being incorrect.

The following is not adviced by me and could be problematic, but for now it works:

Currently i am working myself around the lack of any network connection on haiku by running it in KVM, using a raw disk image as its HDD, installing the packages i want, and shutting down the VM. Afterwards i mount the raw disk image in a haiku running from USB, replace the system folder of the Haiku install on the HDD partition, and boot into it on real hardware. This works (up to now) as haiku seems to be self- configuring and does not seem to rely on fixed hardware driver loading.

About this post:

I fully know that this is a very basic and rather empty report about running haiku on real hardware, but at least i hope that it could be of some use, or would be a moral boost to the developers. Note that my edits of this post are purely to fix some mistakes. I always notice them too late.


Thanks for your report.
If you file tickets for your experienced kernel crashes, even more so when reproducible on the devs’ machines, they might be fixed.

The Qemu crashes should be reported at the Haikuports bug tracker, but maybe it’s a configuration issue. You may want to look thru the forum to see if you find a working qemu command line there, or post your own and have another qemu user comment on it.

1 Like

What filesystem are you using? Please do report these.

USB WiFi dongles are a work in progress, I need to go back to that.

“2D acceleration” does not really exist on modern GPUs; it’s really the 3D pipeline without perspective buffering. And nouveau is especially slow even on Linux and not even ported to the *BSDs, so I doubt we’ll wind up porting it to Haiku anytime soon, even if I do manage to get 3D acceleration working for Intel and Radeon cards.

1 Like

I might make an extra bug-reporting account, the one i used to have has not been used in years so i dont even know the nickname anymore (or even if i use the same email addresses anymore).

I did not save nor check any logs so this purely comes from ‘human’ memory, and only related to the crash after writing to a read only disk:

I mounted a western digital external HDD which has a NTFS partition (NT filesystem) and is connected trough USB. Then i mounted a RAW disk image straight from the external HDD. The raw disk image was one containing a BE filesystem. I then by accident first, and to test it later on, tried to “move” files instead of “copy” them from of the mounted raw disk. meaning that the system would want to delete files from, and write to a read only mounted diskimage. The destination for the illegal “move” would have been the Home folder.

note: mount /external_hdd/rawdiskimage.img /mountpoint

Related to the NTFS issues, I found this (open) ticket: