How to fail at installing Haiku

Before you read, be aware that this is the story of a few failures, and what I learned, not a call for help. :smiley:

I successfully installed hrev52031 in a virtual machine (VirtualBox) and now that I wanted to do some Wi-Fi & Ethernet testing I installed Haiku hrev52039 on an old laptop - sort of.

Important: I read the [Making a Haiku USB Stick](http://Making a Haiku USB Stick) guide and I decided to use Etcher to write the hybrid ISO to the USB drive.

I booted from the USB drive, I wiped all the partitions from the HDD, I created a single partition for Haiku, I formatted it and made it active, I installed Haiku and after I rebooted I saw a broken grub (I had Ubuntu previously).

I assumed there was something wrong with hrev52039 or DriveSetup, which doesn’t do anything (after the partition is formatted) when I click Change parameters… in the Partition menu, although the option is active when I have the Haiku partition selected. So I ended up reading How To Get Haiku Booted and then makebootable - What and why and how to do it manually.

So I booted Haiku from the USB drive (with Haiku installed on the HDD), I used makebootable on /dev/disk/ata/0/master/raw, I rebooted and I got Haiku’s boot loader but it couldn’t boot for some reason. I booted from the USB drive again and, to my surprise, DriveSetup reported I had no formatted partition on my HDD. It looks like makebootable installed the boot loader but also wiped my previous installation. By the way, I used /dev/disk/ata/0/master/raw because /dev/disk/ata/0/master/0 was not accepted by makebootable.

So I reinstalled Haiku and I still had the newly installed Haiku boot loader but the OS failed to boot for some reason. But after so many tries it occurred to me that I have two volumes named Haiku:

  • first, Etcher automatically (without an option to name/change the label) named the partition Haiku;
  • second, each time when I formatted the newly created partition, DriveSetup proposed the volume name Haiku, which I accepted without second thoughts.

Now the more experienced people around here probably know what went wrong. Anyway, with me lacking experience with installing Haiku, I assumed the volume names are nothing but decorative, because I never encountered an OS that relied on those names to perform the installation. And with this detail not being documented, I wasted an hour trying, failing, reading then try/fail/read again until I suspected the volume names would be the problem.

So I formatted my partition again, I named it HaikuHDD and everything went well after that. So my advice to the Haiku developers is to make sure the volume names are not used this way in the installer. To everyone else, now you know how to fail at installing Haiku. :smile: So if you use Etcher like I did, make sure you don’t name your partition “Haiku”.

3 Likes

My problem seems to be I can’t get Etcher to create a bootable USB device (via the Haiku Anyboot image). I did once, but not recently. Anyone else have this issue?

Thanks nicu for you Story. Things like this can, if you write, help other people to serve there problems installing haiku.

Hey forum admin, should we do such stories into a separate forum area?

The besly is a good place for it too.

1 Like

The name are indeed decorative, and this is not where you failed. The trap is actually in Linux doing things the wrong way.

You had a Linux system installed. For some reason, the default setup there is to install a grub loader directly in the master boot record of the main hard drive - outside of any partitions. This loader needs a Linux partition with grub files inside to boot.

When you removed the Linux partition, you kept that loader. It would then complain that it doesn’t know how to boot the system.

You identified the problem correctly, however you used the wrong tool to fix it. Had you used writembr, your system would now be working. This is a tool that just writes a standard mbr to the disk, one that will boot the active partition.

Makebootable is meant to be run on a partition, not a whole disk. What it does is fix some hardcoded offsets in our partition boot record so it can load the bootloader. By using it on the whole disk, you corrupted the mbr and possibly the partition table. Then your system wouldn’t boot, of course.

Finally you either installed haiku directly to the whole drive (without partition table) or recreated a partition table from drivesetup (this puts a standard mbr on the disk too). And the next install attempt worked.

Long story short: I hope we can soon switch to uefi and forget about writembr, makebootable, active partitions, etc.

4 Likes

Good story and important lessons learned - especially those who may come to Haiku via Linux.

When “recycling” a system drive from one operating system to another one, I use one of two tools depending on what will be installed to the drive. I am using “system drive” as it could a conventional hard drive, a solid state drive, or a hybrid drive. Maybe the old “fixed disk” term would be more appropriate?

For a Windows install, I let Windows go about its own path of destruction of anything on the drive not associated/related to Windows. This approach is essentially starting with a whole drive re-format and accepted any default presented by the installer.

For Haiku, I use GParted to handle the erasing and, if necessary, resizing the partitions and cleaning up the MBR. I also use GParted when preparing a multi-boot system drive.

I have still to find a Linux distribution to my liking and worth installing on a system drive. And, while “test driving” a Mac when being in a store feels nice, it had never been an experience so out of this world to warrant climbing the steep learning curve to become proficient with MacOS X and/or follow the rabbit hole to build a hackintosh.

Even though Haiku is still not yet production ready, I like it enough to accept any headaches suffered when installing it and climbing the learning curve every time something is new with it.

I have used Etcher a few times and found its minimalist approach a well suited to one especially since I am in the Windows world most of the time The portable version is actually quite convenient although I found it outrageous that the ~65 MB download has to expand to ~250 MB for the task! In the ChromeOS world, the Recovery App, which essentially performs a similar task, does not go through such an expansion although one needs to have plenty of space on the drive as the uncompressed image is 4 GB (ChromeOS) or 8 GB (CloudReady).

As for “collecting” stories like this one into one area, I think that linking to the post from the pertinent Haiku on-line guide would be appropriate. After all, one tries first and then goes through the forums and tickets when having issues.

P.S. I admit to “using” Linux via SystemRescueCD for GParted, PartImage, SFDisk, and TestDisk (Said to be able to find lost BFS partitions - Unsure if it can cope with the related Atheos/Syllable and SkyOS partitions).

P.P.S. A long time ago, I have used the capability to burn SystemRescueCD and up to ~3.75 GB recovery data onto a single DVD for a system for which no recovery media was included.