Opened 3 years ago
Last modified 5 weeks 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 (7)
comment:1 by , 3 years ago
Component: | - General → System/Boot Loader/EFI |
---|
comment:2 by , 3 years ago
follow-up: 4 comment:3 by , 3 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):
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.
comment:4 by , 3 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 , 21 months ago
Blocking: | 18262 added |
---|
comment:6 by , 21 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.
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?