Opened 2 years ago

Last modified 14 months ago

#17515 new bug

On Gigabyte B550M DS3H, cannot boot Haiku UEFI from motherboard boot menu

Reported by: nyanpasu64 Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: System/Boot Loader/EFI Version: R1/beta3
Keywords: Cc:
Blocked By: Blocking: #18262
Platform: All

Description

When testing Haiku OS Beta 3 on a desktop PC with a Gigabyte B550M DS3H motherboard, I cannot boot Haiku UEFI by pressing F12 in the BIOS boot sequence. If I select my Haiku flash drive in EFI mode (either "SanDisk" or "SanDisk, Partition 2"), Haiku shows 0 tiles lit, waits 1 second, and reboots itself. If I hold Shift and/or Space during boot, the same thing happens. If I select MBR mode, Haiku hangs at 0 tiles lit.

Nightly 55756 has the same issue. But if I hold Shift while restarting Windows and select Haiku UEFI in the Windows boot menu, or run efibootmgr -n .... (replace .... with the ID) and reboot my PC, Haiku boots successfully.

CPU: Ryzen 5 5600X
Motherboard: Gigabyte B550M DS3H, latest BIOS F14e (I think)
GPU: Nvidia GT 730

Change History (6)

comment:1 by diver, 2 years ago

Component: - GeneralSystem/Boot Loader/EFI

comment:2 by waddlesplash, 2 years ago

MBR boot failing on Ryzen is #13370 and/or its successor tickets.

You need to spam the spacebar key under the EFI loader unfortunately, holding it is insufficient.

Selecting the Haiku flash drive in EFI mode may still use the CSM and the MBR loader. Since booting succeeds via the Windows boot manager or efibootmgr, that seems to indicate the EFI loader is indeed working.

Can you disable your CSM in BIOS options and see if behavior changes?

comment:3 by nyanpasu64, 2 years ago

Disabled CSM, doing all testing on 55756, still get the issue when booting off "UEFI: SanDisk" or "UEFI: SanDisk, Partition 2" (correction, it spends 4 seconds at 0 tiles lit). Unplugging and replugging the flash drive while 0 tiles are lit doesn't change behavior. If I boot from UEFI and spam Space, I get the debug menu. If I "Enable on screen debug output", Haiku reaches 0 lit icons, pauses for ~4.7 seconds, and reboots without printing a log message. Unplugging and replugging the flash drive on the debug menu doesn't change behavior.

If I run efibootmgr -n 0006 (flash drive, not partition 2) and reboot, boot succeeds (with full-resolution graphics because I disabled CSM). If I spam space and enable debug output, the boot process continues, starts printing debug output 2 seconds after all tiles appear unlit, but boot panics at "failed to acquire spinlock ... for a long time" (I can't type into the debug prompt):

https://cdn.discordapp.com/attachments/653168829891084298/928019173836226661/PXL_20220104_201111032.jpg

If I press F12, then load Ventoy, use it to boot a rEFInd ISO, and use it to boot a Haiku flash drive, Haiku hangs at 0 tiles lit (my keyboard LEDs change after 4 seconds), with or without on-screen debugging enabled.

If I press F12, then load Ventoy, then press F4:Localboot and select "Search and boot BOOTX64.EFI", then Haiku OS usually hangs. I did get it to boot once successfully (without mashing Space), with full-resolution graphics. I'm not sure how to reproduce it.

I'm using a USB 3 flash drive plugged into a front USB 3 port, and got the same boot issue initially (didn't test the other permutations) in a front USB 2 port.

in reply to:  3 comment:4 by diver, 2 years ago

Replying to nyanpasu64:

If I spam space and enable debug output, the boot process continues, starts printing debug output 2 seconds after all tiles appear unlit, but boot panics at "failed to acquire spinlock ... for a long time"

The spinlock error is "expected" when using onscreen paging, and can be mitigated by disabling SMP when using onscreen paging.

comment:5 by waddlesplash, 14 months ago

Blocking: 18262 added

comment:6 by cafeina, 14 months ago

Per #18262 the same issue occurs with this hardware setup, I'm just mentioning here to taking it into account:

  • Motherboard: Gigabyte B650M GAMING X AX
  • CPU: AMD Ryzen 5 7600X (with AMD iGPU)
  • Graphics (dGPU): NVIDIA GeForce RTX 4070 Ti

In my case, using the workaround mentioned above allows to install the system and once installed, the workaround is not needed and the boot manager can transfer the control to the kernel.

Last edited 14 months ago by cafeina (previous) (diff)
Note: See TracTickets for help on using tickets.