My fourth day with Haiku —Installation and boot woes

13 min readJul 14, 2019

TL;DR: After a couple of days experimenting with Haiku, I have decided that it is now time to install it on a dedicated SSD. If only this was as easy as it sounds…

Some serious Haiku boot testing is going on

Three days ago, I discovered Haiku, a “shockingly good” desktop operating system. It’s the fourth day now. I realize that I want to do more “real work” with the system, and the partition the Anyboot image gave me by default is just getting too small. Hence, I head over to my factory-new 120 GB SSD and prepare myself for a smooth ride with the Haiku installer. Oh boy was I wrong!

As installation and booting are crucial first impressions for any operating system, they should be given highest attention and love imho. So I hope that documenting my “new user” experiences here may prove helpful to the Haiku developers in their ongoing effort to make a polished operating system that “just works”. Any mistakes are clearly mine!

I think that especially the USB booting situation is important, since most users will not be ready to commit a built-in SATA (let alone NVMe) drive for the first experiments with an entirely new operating system. So while USB booting may seem a corner case to developers, it is probably the most realistic scenario most users will encounter when trying out Haiku for the first time on bare metal hardware.

I hear from a developer,

We are still super early on the EFI support. We quickly hacked up something so we could ship a beta1 that boots on EFI machines. It is far from the level of integration we want to get and as a result, I don’t know if we should document all the jump and hops around our current work, or just focus on finishing the work and then document it once it works as it should.

Makes sense to me, and makes me hopeful that things will end up much more polished in the end than they currently are. But I can only test what is there today, so off we go…

Anyboot image is too small

While the Anyboot image is awesome in that you can write it to a USB drive very easily, it does not leave enough space on the Haiku partition to install significant additional software.

Writing the Haiku Anyboot image to a USB drive is fast and easy, but the result does not have enough space to do real work

Quick Fix: Increase the default size of the Haiku partition

So, to do any real work with Haiku, one needs to install Haiku using the Installer app.

Installer does not do everything in one place

Remember the gorgeous Mac OS X installer?

Initializes the disk (writes a GUID parition table, also known as GPT)
Partitions the disk (EFI partition, main partition) using a “common sense” partitioning scheme (making best use of the disk)
Blesses the boot volume (sets the bootable flag)
Copies the files

In other words, it does “everything” without the user having to fiddle around.

Contrast this with the Haiku installer. It just copies files and leaves the user alone with the rest. And this rest is too cumbersome for even a slightly more advanced user to get everything right the first time, especially when you want a system that is bootable on both BIOS and EFI systems.

What do I need to do?

I don’t really know. Anyhow, here is what I would assume:

Open DriveSetup
Select the raw device onto which I want to install
Disk-> Initialize -> GUID Partition Map… -> Continue -> Write changes -> OK
Right-click on “<empty>” on the raw device onto which I want to install
Create… -> Enter “256” as the size -> EFI system data (I am really not sure about this) -> Create -> Write changes
Right-click on “<EFI system data>” on the raw device onto which I want to install
Format -> FAT 32 File System… -> Continue -> Name: Enter “EFI” -> FAT bits: 32 -> Format -> Write changes
Again, right-click on “<empty>” on the raw device onto which I want to install
Create… -> Partition name: Enter “Haiku” -> Parition type: Be File System -> Create -> Write changes
Right-click efi -> Mount
Open the Installer app -> Be confused by the technobabble text -> Continue -> Onto: Haiku (make sure it is the partition we just created before) -> Begin
In the file manager, manually copy the EFI folder from the system that is currently booted to the efi partition (I assume this is needed for EFI booting)
This one I am not sure about (it may be totally wrong!): Open the BootManager application, select the device (mine shows up as “ASMT 2115 0”) -> Install -> Next -> Next -> Check “Haiku” and uncheck “efi” -> Next -> After one second -> Next -> Next -> Write boot menu -> Done (I assume this is needed for BIOS booting, although I might be wrong). It looks like this actually destroys things because inspecting the disk with DriveSetup now only shows one “(GPT)” partition and the ones made above are gone! So I am going to repeat all the steps but without this last one. A developer says that “if you’re using GPT you don’t need to use BootManager. This is only for BIOS booting”. I think BootManager should refuse to run on GPT partitioned disks then. (Update: Before I had finished writing this article, a patch that does just that was submitted.) Also, it is unclear to me how to make a disk that can boot on both BIOS and EFI systems (as I do in the Linux world)
Shut down
Attach the newly made disk to a port that I know the system can boot from
Power on

I think it is easy to see that a tool should be made that would do all of this at the click of one button, and the confirmation once(!) that it is OK to wipe that device.

“Quick” fix: Installer that does everything autmagically

OK, maybe not that “quick”, but clearly worthwhile after all. This is the first impression users get from the new system. If they fail at installing (as I did a couple of times), many will just silently quit and will never be seen again.

Technical explanation regarding DriveSetup: according to @PulkoMandy,

BootManager writes a complete boot menu allowing to boot multiple systems from the disk, and for that it needs about 2KB at the start of the disk .That fits for old fashioned partition schemes, but not when you use GPT, which uses these same sectors for the partition table. On the other hand, writembr writes a much simpler code to the disk, that will just locate the first active partition and boot that. The code fits in the 400-ish first bytes of the disk, so it does not conflict with the GPT. It has only limited support for GPT disks (it will still get it right in easy cases)

Quick fix: Let the BootManager GUI tool install whatever writembr installs if it detects a GPT disk. Never let the BootManager GUI tool install the 2KB code to GPT disks. Don’t set the boot flag on the EFI partition but on the Haiku partition

First try: Kernel panic

My setup

Acer TravelMate B117 N16Q9 (originally sold with Endless OS)
lspci information: https://paste.debian.net/plain/1091516
lsusb information: https://paste.debian.net/plain/1091515
Existing Haiku system running from a 16 GB Kingston DataTraveler 100 USB stick made with Etcher on Linux using the Anyboot image, attached to the USB 2 port of the TravelMate B117 (because it does not boot when attached to the USB 3 port on this system)
Factory- new 120 GB Kingston A400 SSD attached to a ASMedia ASM2115 SATA to USB 3 adapter, attached to the USB 3 port of the TravelMate B117

Results

Installer starts to copy files but then throws an IO error, followed by a kernel panic.

Second try: Unbootable disk

My setup

As above, but:

Factory-new 120 GB Kingston A400 SSD attached to a ASMedia ASM2115 SATA to USB 3 adapter, attached to a USB 2 hub, attached to the USB 3 port of the TravelMate B117
I have verified with a bootable Windows USB stick that the machine can boot from the USB 3 port

Results

Unbootable system. It looks like BootManager has destroyed the partitions on the disk.

BootManager. “Write boot menu” seems to destroy the partitioning on the disk?!

Third try: Yay, we can boot! But not from USB 3 on this machine

My setup

As in the second try. But this time without using BootManager at all.

When inspected from Linux, the partitions (without having run BootManager) look like this:

The FAT32 “efi” partition has the boot flag set without having run BootManager. Will this boot on a non-EFI system?

Results

EFI mode, USB 2 port: Boots straight into Haiku
EFI mode, USB 2 hub attached to USB 3 port: “no boot path found, scan for all partitions…”. After a while, boot screen with “Select boot volume (Current: haiku)”. “Continue booting” is greyed out and cannot be selected. Selecting “Select Boot Volume” -> Haiku (Current: Latest state) -> Latest state -> Return to main menu -> Continue booting: Boots into Haiku. I wonder why it can’t “just boot” but requires me to fiddle around, especially since the boot screen clearly shows that it has found the boot partition automatically. Bug?
EFI mode, USB 3 port: Boots straight into Haiku. Yay, makes me happy — or so I think. The blue desktop appears but then nothing happens for a looooong time. The “finger” mouse cursor is stuck to the middle of the screen, cannot be moved. The ASMT SATA to USB 3 adapter blinks. Finally, a kernel panic occurs. The anyboot image on a USB 3 stick is not even recognized as bootable in this configuration. What gives? I open https://dev.haiku-os.org/ticket/15162 regarding this.

Kernel panic when booting from USB 3 port

Amazingly, you can still type commands in a kernel panic, although you need to use the English keyboard now. So I do as advised in https://dev.haiku-os.org/ticket/14964:

syslog | tail 15 — while the kernel has panicked

Typing reboot does not work, unfortunately.

Fourth try: Second machine

I move this exact (known working) drive to a second machine, where I test it on different ports. Here are the results:

My setup

As in the third try, but on an Acer Revo One RL 85.

Result

EFI mode, USB 2 port: “no boot path found, scan for all partitions…”. After a while, boot screen with “Select boot volume (Current: haiku)”. “Continue booting” is greyed out and cannot be selected. Selecting “Select Boot Volume” -> Haiku (Current: Latest state) -> Latest state -> Return to main menu -> Continue booting: Boots into Haiku. Shutdown hangs on “Shutting down…”.
EFI mode, USB 2 hub attached to USB 3 port: tbd
EFI mode, USB 3 port: “no boot path found, scan for all partitions…”. After a while, boot screen with “Select boot volume (Current: haiku)”. “Continue booting” is greyed out and cannot be selected. Selecting “Select Boot Volume” -> Haiku (Current: Latest state) -> Latest state -> Return to main menu -> Continue booting: Boots into Haiku. Note that unlike with the first system, I can boot into the desktop on a USB 3 port here without a kernel panic. Shutdown hangs on “Shutting down…”.
EFI mode, SATA: Boots straight into Haiku. Shutdown hangs on “Shutting down…”.
CSM BIOS mode, USB 2 port: tbd
CSM BIOS mode, USB 2 hub attached to USB 3 port: tbd
CSM BIOS mode, USB 3 port: tbd
CSM BIOS mode, SATA: Black screen with white font “Reboot and Select proper Boot Device or Insert Boot Media in selected device and press a key”. Coming from the Acer CSM BIOS?

Fifth try: Third machine

I move this exact drive to a third machine, where I test it on different ports. Here are the results:

My setup

As in the third try, but on a Dell Optiplex 780. This machine has an early EFI which apparently always runs in CSM BIOS mode, at least if I am not mistaken.

Result

USB 2 port: Boots into Haiku.
USB 3 port (PCIe card, Renesas Technology Corp. uPD720202 USB 3.0 Host Controller): tbd
SATA: tbd

Sixth try: Fourth machine, MacBook Pro

My setup

As in the third try, but on a MacBookPro7,1.

Result

CSM mode (“Windows”): Black screen with No bootable drive -- insert boot disk and press any key . Is this message coming from the Apple (Insyde) CSM? (Acer devices seem to use the same message, possibly because they are also using Insyde based firmware.)
UEFI mode (“EFI Boot”): Just stalls in the Apple boot selector GUI

Seventh try: Lenovo 32-bit Atom netbook

My setup

16 GB Kingston DataTraveler 100 USB stick made with Etcher on Linux using the 32-bit Anyboot image from https://cdn.haiku-os.org/haiku-nightly/x86_gcc2_hybrid/haiku-master-hrev53247-x86_gcc2_hybrid-anyboot.zip
Lenovo ideapad S10 Atom netbook with no hard disk installed
lspci info from Linux on this machine: https://paste.debian.net/plain/1091494

00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI])
	Subsystem: Lenovo NM10/ICH7 Family USB2 EHCI Controller
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 23
	Region 0: Memory at f0844000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Debug port: BAR=1 offset=00a0
	Kernel driver in use: ehci-pci

Result

Starts to boot, then kernel panic. syslog | tail 15 shows kDiskDeviceManager::InitialDeviceScan() failed: No such file or directory after a couple of ATA errors. Note that I am trying to boot from USB, not from ATA

Kernel panic on Lenovo ideapad S10 Atom netbook booting from USB with no hard disk installed

Just for fun, I put in a SATA disk but it did not make a difference for the USB booting, although I got different messages when using syslog | tail 15 (showing that it had found /dev/disk/ata/0/master/1 ).

mr. waddlesplash asks me to provide syslog | grep usb in this situation, so here we go. I am still super thrilled that you can run such commands in a kernel panic screen:

According to mr. waddlesplash, this EHCI error appears to be same as this ticket: https://dev.haiku-os.org/ticket/11040

Eighth try: MSI 32-bit Atom netbook

My setup

As above
Medion Akoya E1210 Atom netbook (rebadged MSI Wind U100)with a hard disk installed (but we are not using it for Haiku)
lspci info from Linux on this machine: https://paste.debian.net/plain/1091490

00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI])
	Subsystem: Micro-Star International Co., Ltd. [MSI] NM10/ICH7 Family USB2 EHCI Controller
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 23
	Region 0: Memory at dff40400 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Debug port: BAR=1 offset=00a0
	Kernel driver in use: ehci-pci

Result

Boots into Haiku installer. Touchpad works! (e.g., scrolling). Graphics is recognized as “Intel GMA (i945GME)”.

Ninth try: 32-bit USB drive on MacBook Pro

My setup

As above
MacBook7,1

Result

Black screen with No bootable drive -- insert boot disk and press any key .

Side note: Apple keyboard

These are the four keys on the left bottom of keyboards:

Non-Apple keyboads have: Ctrl-Fn-Windows-Alt-Spacebar
Apple keyboards have: Fn-Ctrl-Option/Alt-Command-Spacebar

Wouldn’t it be cool if all keyboards behaved the same in Haiku, so that you could operate them the same way regardless of what is printed physically on the keys?

On an Apple keyboard, the Alt key is not the key left to the spacebar (the Command key is). In this case, I would find it more than neat of Haiku would automatically use the Command key in place of the Alt key, so that the “feeling” of a non-Apple keybord would be replicated to Apple keyboards.

There are apparently ways to get this to work in the settings, but it would be nice if this was recognized automatically (it’s USB, after all

Side note: writembr to the rescue?

I hear that the writembr command line tool can be used to make the system (which boots via EFI) bootable on BIOS and CSM.

/> writembr /dev/disk/.../.../.../.../raw 
About to overwrite the MBR boot code on /dev/disk/scsi/0/2/0/raw
This may disable any partition managers you have installed.
Are you sure you want to continue?
yes/[no]: yes
Rewriting MBR for /dev/disk/.../.../.../.../raw
MBR was written OK

Looks good, but the result is still as unbootable on BIOS and CSM as it was before. So maybe BIOS and CSM booting currently only works for traditionally partitioned, not GPT partitioned, devices. Who knows.

Conclusion

Haiku is awesome, but the whole installation experience needs love. Also, the boot experience is hit-and-miss, with a success rate of about roughly a third under different hardware configurations. USB 2 (EHCI, see: Atom netbook) and USB 3 (XHCI, see: Acer TravelMate B117) seem to be equally shaky. But at least one developer is on it.

I hope that documenting my “noob” experience can help the developers understand what “mere mortals” are struggling with, and help them make a product as polished as the Mac OS X Installer.

Remember, it’s not even 1.0 yet. And for that, it’s already pretty darn good.

Try it out for yourself today! The Haiku project provides nightly images that can be booted from DVD or USB. Installation consists of downloading the nightly 64-bit image and writing it to a USB stick using Etcher.

This article is part of a series:

probono is the founder and lead developer of the AppImage project, the founder of the PureDarwin project, and a contributor to various open source projects. Screenshots were made on a Haiku system booted from USB stick. Grateful acknowledgment is made to the developers in #haiku on irc.freenode.net, particularly mr. waddlesplash, @PulkoMandy, @diver, and @KapiX.

My fourth day with Haiku —Installation and boot woes

Anyboot image is too small

Installer does not do everything in one place

What do I need to do?

First try: Kernel panic

My setup

Results

Second try: Unbootable disk

My setup

Results

Third try: Yay, we can boot! But not from USB 3 on this machine

My setup

Results

Fourth try: Second machine

My setup

Result

Fifth try: Third machine

My setup

Result

Sixth try: Fourth machine, MacBook Pro

My setup

Result

Seventh try: Lenovo 32-bit Atom netbook

My setup

Result

Eighth try: MSI 32-bit Atom netbook

My setup

Result

Ninth try: 32-bit USB drive on MacBook Pro

My setup

Result

Side note: Apple keyboard

Side note: writembr to the rescue?

Conclusion

Written by probono