[R1/beta2] Cannot boot Haiku install medium (USB stick).

[LSS37040]

I'm trying to install R1/beta2 on the system with ASUS Crosshair V Forumula-Z motherboard and I'm getting these issues when booting the install medium.

1. search_module called during kernel startup! name: "bus_managers/acpi/v1"

Not sure why this is happening (from what I read this appears to be some kind of assertion). As the stacktrace mentioned io_apic, If I disable IO APIC from safe mode options this goes away (I can also continue here, which will lead to the second and the real issue).

2. did not find any boot partitions!

It seems for some reasons Haiku cannot see my USB stick, regardless of whether it's plugged to the USB 2.0 or USB 3.0 ports.

This is reproducible with both 32-bit and 64-bit versions. Not sure what else I could do to get more information about the issue which is preventing me from installing this.

[LSS37040]

Did not find any boot partitions

[LSS37040]

search_module called during kernel startup, with on screen boot output.

[waddlesplash]

If you can "reboot" at the prompt, see if the previous syslog is available inside the bootloader (see bootloader documentation in the user guide.) If it is, please save it to another stick and upload it here.

[LSS37040]

I'll try when I get back.

However, I don't think reboot will always work here to acquire the previous syslog, as with this motherboard, when I entered reboot in the KDL, it seems to perform a power cycle instead of warm reboot (which invalidates the memory).

Maybe I can just try pressing the RESET button as that way the board would not do a power cycle. Sadly the board is too new to have an onboard serial port that would allow me to directly get the syslog from there (which would make things easier).

[LSS37040]

Nope. Pressing RESET button doesn't allow me to access the previous syslog.

And there's no way to actually warm reboot the system, as either typing reboot or pressing CTRL-ALT-DEL to attempt a warm reboot would result in the board performing a power cycle, which invalidates the memory buffer (and would not show up in the boot loader).

The board doesn't have any onboard serial port... so I'm not sure how to get detailed logs there...

[mmlr]

You could try provoking a tripple fault, which should reset the CPU. It may or may not cause a power cycle on your hardware as well.

This can be done by overwriting many critical things so that fault handling will result in faults again. One way to do it is to corrupt the interrupt handler. In KDL, look up the address for the int_bottom symbol and overwrite it with 0:

kdebug> symbol int_bottom
0xffffffff8015131c   185 kernel_x86_64:int_bottom
0xffffffff801513d5   469 kernel_x86_64:int_bottom_user
kdebug> expr *0xffffffff8015131c = 0
0 (0x0)
kdebug> continue

At which point the system should reset.

[mmlr]

As for the actual problem: It seems rather strange. The ACPI module is used in IO APIC init and it has been since a very long time. That the module is used at this point is not a bug. But apparently the module has not been preloaded by the bootloader and is therefore not available which caused a module search. A search can only work once the boot volume has been mounted, hence the panic.

Can you run the modules command in KDL and post a picture of its output? It should have the bus_managers/acpi/v1 in the list.

The bootloader gets the list of modules to be preloaded from the symlinks in the /system/add-ons/kernel/boot directory. For them not to be available would mean the bootloader did not find them. It was obviously able to read the system package, as otherwise it couldn't have loaded the kernel from there. That you don't see a boot volume selection in the bootloader may be related. Can you enter the bootloader and use "debug options" and "display current boot loader log" to investigate what might have happened here. Maybe there are obvious errors ("could not load X error Y"), otherwise please post pictures of the log.

[LSS37040]

By the way, not sure if this might be related.

The system currently has an existing Haiku R1/beta1 install that I intend to replace (reinstall), as it was installed while the system was still on an older motherboard, and with the current motherboard I couldn't use the keyboard/mouse anymore.

When I hold SHIFT to invoke the Haiku boot loader menu, it seems to choose the installation on my hard disk by default, instead of the USB stick (which has the Haiku label), so I have to manually choose it to boot from the USB stick, and eventually I get this error saying it can't find the boot partition.

And again, how should one create a bootable USB stick? My sticks were created on Linux using GNOME disk utility (which seems to use the dd method for ISO images).

Plus something minor and off-topic: The system uses ​Airboot as the primary boot manager, as I also intend to boot other operating systems, including OS/2 (ArcaOS) on it. The boot manager can directly boot other operating systems like Windows and Linux (GRUB) by choosing their respective system/boot partition, but not Haiku (even after installation, or marking it bootable). For now I can use GRUB from my Linux installation to chainload into Haiku. Not sure which side is the problem. If the issue is not related to Haiku's boot loader then I'll file a bug report on Airboot side instead.

[LSS37040]

modules output.

[LSS37040]

boot loader log (part 1)

[LSS37040]

boot loader log (part 2)

[LSS37040]

boot loader log (part 3)

[LSS37040]

boot loader log (part 4)

[LSS37040]

boot loader log (part 5)

[LSS37040]

boot loader log (part 6)

[LSS37040]

boot loader log (part 7)

[LSS37040]

boot loader log (part 8)

[LSS37040]

boot loader log (part 9)

[LSS37040]

boot loader log (part 10)

[LSS37040]

boot loader log (part 11)

[LSS37040]

boot loader log (part 12)

[LSS37040]

boot loader log (part 13)

[LSS37040]

boot loader log (part 14)

[LSS37040]

boot loader log (part 15, last few lines)

[LSS37040]

Triple fault trick doesn't work. Doing so the system still performs a power cycle. and I still can't get the log out in a digital form.

I've attached the pictures of the modules KDL screen output, as well as boot loader logs (14 pages, plus a few lines after page 14).

[LSS37040]

I'm closing this issue as I've replaced that board with another one (and reverted to FX-8350) and with the new board and CPU I could succeed in booting to Haiku x64 via UEFI without encountering any issues.

I don't know whether it's possible to UEFI boot the newly installed Haiku x64 system, as it's on a GPT partition. As there's also a Linux installation (UEFI boot) on the disk I installed Haiku x64 on, not sure if the EFI GRUB can be used to chainload it. I did not see a Haiku boot option in UEFI BIOS boot menu, so at present, there's nothing installed by Haiku into the ESP yet.

The exact reason why the bus_managers/acpi/v1 module was absent in the modules when booting on the previous board remains unknown (and very unusual since the panic was due to an assertion being hit).

Unfortunately, the old CPU (FX-9590) has been proven to be ridiculously hard to "tame" , that I suspect the CPU has put too much pressure on the old board's circuitry that the board has started to become faulty, causing random black screen freezes. The board seemed to have entered some kind of protection state that it shut down everything, even the power/reset logic stopped working (can only be powered off by holding POWER for at least 5 secs).

[kallisti5]

hrev54912 might have solved this one. Closing at users request.

[diver]

Still reproducible with eeepc701 and the latest nightly.

[diver]

I don't have this hardware anymore, so I can't comment on this.