Describe the bug
Clover versions newer than r5165 (specifically r5172g tested) fail to boot properly on an ASUS P8B75-M LX Plus (B75 chipset) motherboard using latest 0906 AMIBIOS firmware in a legacy-era mid-UEFI environment 2.10.1208 (2014.)
(Ventoy-> memdisk mode on both for least usb interaction IMO)
Important clarification:
This motherboard does support UEFI boot
However, the firmware cannot boot NVMe devices natively
Pretty good, but can not get PCI NVme disks natively and with some unreasonably tricky ASUS BIOS anti-mod protection for us owners/modders and no possibility to do our own tricky lock options for us as well (c)
Clover is therefore used as a bridge/bootloader to chainload and boot an NVMe-installed OS
Behavior observed:
r5165: partially functional but unstable/fragile
intermittent boot success
random hangs/freezes before showing blue/gray boot menu
inconsistent behavior across reboots
sometimes succeeds in chainloading NVMe OS
r5172g:
fails to boot reliably at all (black screen, cursor blink)
freezes before usable Clover GUI or before successful NVMe chainloading
effectively unusable on this platform
This appears to be a regression affecting older AMIBIOS-era UEFI implementations used specifically for NVMe boot bridging.
How to reproduce
Steps to reproduce the behavior:
Use an ASUS B75 chipset motherboard with AMIBIOS firmware
Install OS on NVMe SSD
Configure Clover as NVMe boot bridge/loader
Boot system in UEFI mode
Attempt boot using Clover r5172g
Observe freeze/hang/failure before successful NVMe boot
Comparison:
Replace Clover with r5165
Repeat same process
Observe partial functionality with unstable/inconsistent behavior
Expected behavior
Expected:
Clover should initialize correctly on older AMIBIOS-era UEFI firmware
Clover should reliably chainload/boot NVMe-installed OS
Newer Clover revisions should maintain or improve compatibility relative to r5165
Actual:
r5165 = unstable but partially functional
r5172g = complete or near-complete boot failure on this platform
Screenshots
No screenshots currently available because boot failure often occurs before GUI becomes usable.
Can provide:
BIOS screenshots
Clover configuration
boot media layout
debug logs if required
Environment
OS: NVMe-installed OS booted through Clover
Boot mode: UEFI
Clover versions tested:
r5165 → partially works
r5172g → fails
Hardware:
ASUS B75 chipset motherboard
AMIBIOS firmware (B75-era)
Intel Xeon E3-1275 v2 (Ivy Bridge)
NVMe SSD (non-native BIOS support)
SATA boot helper / Clover boot media
Additional information
This motherboard generation supports UEFI but lacks native NVMe boot support in firmware.
Clover is specifically being used as:
NVMe boot bridge
UEFI chainloader
compatibility layer enabling NVMe boot on older firmware
Older Clover versions appear more tolerant of this firmware environment.
Possible regression areas:
legacy AMI UEFI compatibility
NVMe initialization
UEFI memory mapping changes
driver loading order
boot services handling
GOP/graphics initialization
DXE interaction with older firmware implementations
Potentially affected platforms may include:
Intel B75 / Z77 / H77
Ivy Bridge-era AMIBIOS UEFI boards
systems using Clover specifically for NVMe boot bridging on unsupported firmware generations
Describe the bug
Clover versions newer than r5165 (specifically r5172g tested) fail to boot properly on an ASUS P8B75-M LX Plus (B75 chipset) motherboard using latest 0906 AMIBIOS firmware in a legacy-era mid-UEFI environment 2.10.1208 (2014.)
(Ventoy-> memdisk mode on both for least usb interaction IMO)
Important clarification:
Behavior observed:
This appears to be a regression affecting older AMIBIOS-era UEFI implementations used specifically for NVMe boot bridging.
How to reproduce
Steps to reproduce the behavior:
Comparison:
Expected behavior
Expected:
Actual:
Screenshots
No screenshots currently available because boot failure often occurs before GUI becomes usable.
Can provide:
Environment
Additional information
This motherboard generation supports UEFI but lacks native NVMe boot support in firmware.
Clover is specifically being used as:
Older Clover versions appear more tolerant of this firmware environment.
Possible regression areas:
Potentially affected platforms may include: