Installer doesn't install bootman and DriveSetup doesn't set the created partition as active, leading to unbootable system

[HaikuReactOSTrac]

Haiku is no longer able to boot in Virtualbox and Virtual PC. I tried installing Build 42637 which is the latest build as of the reporting of this ticket. After installing Haiku, I rebooted the virtual Machine to find an error message which says "no bootable active volume" 15-20 seconds later, another message appeared which says "rom basic fatal: init18: boot failure" in capital letters. Does anyone know what this is being caused by? Is this particular build a broken build? the second message does not appear in Virtual PC. The 2 screen shots attached below show this problem.

[HaikuReactOSTrac]

Screenshot of problem occurring in Virtualbox.

[HaikuReactOSTrac]

Screenshot of problem occurring in Virtual PC

[taos]

No such problems with haiku-nightly.vmdk from haiku-nightly-hrev42637-x86gcc2hybrid-vmware.zip and VirtualBox 4.0.8 on Windows 7. Did you attach the vmdk file as hard disk to your virtual machine or did you install ("After installing Haiku") from CD or anyboot image?

[deejam]

I had no problems installing (and upgrading) hrev42637 using the nightly .iso image in VirtualBox 4.1.0 on Mac OS X.

Edit: In both cases, I installed Haiku onto the entire disk without any partitions and initialized it as Be File System.

[siarzhuk]

I have NO PROBLEM booting hrev42637 both on VB 4.1.0 hrev73009 and on VPC Win 7 Ultimate x64.

[tqh]

That doesn't mean that there isn't a real problem. It would be good if you could setup your vm to write serial port data to file and attach it.

[HaikuReactOSTrac]

I cannot write serial port data because Haiku refuses to boot in Virtualbox whenever a serial port is present, even from the CD.

[deejam]

If I understand this correctly, the "No bootable active volume" is an error message from Haiku's boot loader and "ROM BASIC FATAL: INIT18: BOOT FAILURE" is VirtualBox's counterpart. They do say the same thing; no bootable volume is found.

• Are you installing Haiku on a system that has partitions or are you installing Haiku on the entire disk?
• Are you installing on a virtual disk, or a physical?
• Are you performing a clean install, or an upgrade (upgrade = installing on top of a previous Haiku installation)?

[HaikuReactOSTrac]

I am using an entire Virtual disk to do a clean install of Haiku, just one BeFS partition for the Haiku system files.

[taos]

I can only reproduce HaikuReactosTrac's error message if I initialize the virtual disk as Intel Partition Map in DriveSetup, create a partition that is formatted as Be File System, and install Haiku onto the Haiku partition (but don't install the Bootmenu to MBR). No problems when going the "traditional" way of initializing the whole disk as Be File System (without creating any partitions).

[HaikuReactOSTrac]

Initializing the entire disk as BeFS allows a successful installation of Haiku.

[bonefish]

Replying to deejam:

If I understand this correctly, the "No bootable active volume" is an error message from Haiku's boot loader and "ROM BASIC FATAL: INIT18: BOOT FAILURE" is VirtualBox's counterpart. They do say the same thing; no bootable volume is found.

Not quite. The former message is likely from the MBR boot code -- Haiku's boot loader (both stage 1 and stage 2) doesn't care whether the partition is active. Since there's no indicator in the partition table whether a partition is bootable or not, the message means that none of the defined partitions has been marked active.

Please check in DriveSetup whether the partition exists and is marked active. If so, please provide the MBR (the first 512 bytes of the disk).

[taos]

I'm not sure if this can really be called a bug: When I install any operating system to a partition I expect to have to install some kind of boot manager to the mbr in order to be able to boot the operating system (Windows and some linux distributions do this without asking the user - nasty behaviour in a multiboot environment), or at least to have to mark the partition as active. Right before the installation, Haiku even warns the user that either Haiku has to be added to a boot manager like Grub manually or Haiku's boot menu should be installed to prevent boot failures such as described here. If the boot menu is installed (or the haiku partition is set as active), I can boot Haiku even if it resides on a BFS partion inside an Intel Partition Map.

So this "bug" could rather be changed to an enhancement request: if there is only one partition (therefore no other operating systems on the disk that could be affected) mark the partition as active or install the boot menu to the mbr by default (wouldn't please me but possibly other users).

EDIT: The Haiku boot menu is not mentioned before the installation but rather in the user guide (humdinger introduced a new BootManager entry) - my fault. So maybe, a reminder that the (only) partition should be set to active (I hope Haiku's DriveSetup supports more than one active partition if there is more than one disk) or that alternatively a boot menu/manager should be installed could be added?

[siarzhuk]

Replying to pulkomandy:

Dear Adrien, have you really understand what the original problem is??? Your changes look like obfuscating original idea. Modifying MBR is not the Installer's business most of time. This bug was about very specific and rare case of empty single-partition configuration with zero-filled MBR. But you propose to edit MBR every time Installer was run and DriveSetup creates the partition. Most of users would kill you after this. ;-)

[pulkomandy]

I changed the description because what was stated before (virtualbox and all that) doesn't have anything to do with the actual problem.

There are several solutions to it :

• Drivesetup could put a default MBR when creating the partition map. I don't think it does
• It could also activate the created partition if it is the only one on the drive
• Or, this could be fixed in installer by detecting an empty MBR and asking to install bootman on it

I didn't propose any solution, just made the ticket title related to the involved tools. Before it sounded like a hardware crash early in bootloader or kernel boot, now it's clear that it's just a missing MBR, and thus a problem at install time.

[pulkomandy]

NetBSD has an MBR code which could be used for this (in the minimal configuration - no bootmenu stuff): ​http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/sys/arch/i386/stand/mbr/mbr.S?rev=1.23&content-type=text/plain&only_with_tag=MAIN

When creating an intel partition we should put that code in it instead of leaving it with en empty boot code.

[axeld]

We already have MBR code, why not just use that in that case? I'm pretty sure that our intel partitioning module already writes an MBR, anyway.

[pulkomandy]

What we need here is (I think) an MBR that just chainloads to the active partition. Our MBR code does not does that, and instead relies on makebootable being run on it to point to the stage2 loader at the right place.

The other one we have is bootman, which works fine too but needs some user configuration to setup the boot menu. Which you can't do when you are creating the partition map, because no partitions are there yet. So I don't think it can be used in that case.

I can confirm that starting with an empty disk (dd if=/dev/zero), creating a partition map on it, and installing haiku (but no bootman) results in a system that won't boot. It may work if you don't clear the disk first because the disk may already have a standard MBR on it which we don't erase. But if there's nothing there, you get an unbootable system.

At a minimum we need a clearer warning message that setting up bootman or some other MBR is required in that case.

[axeld]

Didn't we have a writembr tool that did that? Anyway, why not just check in the Installer whether or not the MBR is empty, and if so, automatically run makebootable on it?

[pulkomandy]

Right, writembr sounds like it would work. Not sure makebootable would work in the current state as it's designed to write the partition boot record, not the master boot record.

And after checking it looks like the partitionning system does reference it already. The "no bootable active volume" comes from there. So that part is actually working. (sorry, a bit of lack of sleep this week).

The problem is then that the partition is not active. We should automatically check the checkbox when creating the first partition on a volume in that case.

[axeld]

That certainly would help. Alternatively, Installer could make sure that the Haiku partition is active, if there isn't any active partition.

[pulkomandy]

Fixed in hrev48184.

[axeld]

I would prefer to have the test logic in Installer, too -- if you already have created a partition elsewhere, you might still end up with an unbootable Haiku afterwards.

Even worse, if you don't install Haiku to the first partition, the fix doesn't do anything useful at all. So IMO it would be nicer not to randomly choose a partition to make active, but let Installer do an informed decision instead.

[pulkomandy]

You are correct. But now I tried to add this to Installer (to makebootable, actually, since that's what Installer uses to make the partition bootable), and I can't understand how to change partition parameters from there. It seems the support for editing partition parameters after creation is missing or incomplete. Or maybe it's just undocumented and I can't understnad the code and how these BPartition, BMutablePartition, BPartitionHandle are supposed to fit together.

[nielx]

Replying to pulkomandy: You intend to work on this or is it open to pick up?

[pulkomandy]

It's open if you want to take a look

[pulkomandy]

Move unsolved issues to beta 4 since there is no chance of fixing them now.

[waddlesplash]

Kicking the can down the road again.

[bruno]

This bug is still alive. Haiku 32bit Beta 3 to 4 hrev somewhere at 56595 I could not boot into the updated Beta 4.. bios_is32 sforge 1 or so?

[pulkomandy]

If your system was working before and is not working after an update, then it's not this bug.

This bug only happens when creating a new partition and forgetting to check the "active partition" checkbox.

If you have a problem with booting after an update, please create your own bug report. There are many reasons why this could happen, and mixing reports from different persons in the same ticket is always confusing.

[waddlesplash]

Should Installer refuse to install on non-"active" partitions? For GPT we could also check the partition has the correct GUID.

[X512]

Installing in non-active partitions is perfectly valid if use BootMan MBR.

[pulkomandy]

Maybe not refusing to install, but doing some checks and having a warning alert (that no one will read) would be nice.

I think the best way to fix this is having DriveSetup set the active flag by default for tqe first created partition (just check the checkbox by default, people can still change it if they want). It would solve this specific issue in the most common case, not get in the way of anything, and seems reasonably simple to implement. And to me it seems better than having checks in Installer which would lead to a frustrating experience like this (exagerated for dramatic effect):

-installer complains that there are no partitions

• you go in drivesetup and create a partition
• installer now complains that the partition is not formatted
• you return to drivesetup and format the partition
• installer now complains that the partition is not active

When justa small change to DriveSetup will help people stay on the "happy path", at least for this specific test (for the other problems with setting this up correctly, I believe there are other tickets already)

• you give up trying to use a computer and go live in a cabin in the woods

[X512]

you go in drivesetup and create a partition installer now complains that the partition is not formatted

I still strongly believe that partition creation and formatting should be one operation. It will improve user experience a lot. User still may select "not formatted" option if he really want it.

[pulkomandy]

Yes, but again this is not what this ticket is about. Can we have the simple fix to activate the first partition done for the next beta? It is a simple fix and would already solve a large part of the issue and would be one less thing to worry about.

If you have other enhancement suggestions, you can create more tickets or upvote the corresponding tickets if they already exist, and you can make the changes if you want. We can discuss it there, then.