The installation completed on an older ASRock H61M-VG4 system, but the machine displayed “Reboot and select proper boot device” after the installer USB was removed. The SSD was visible in firmware, Secure Boot was disabled, Debian could boot, and a repair tool reported Locked NVRAM.
Those details point away from a failed SSD write and toward the firmware boot path: ZimaOS may be present on disk while the motherboard has no usable UEFI entry that points to it.
Confirm the Current ZimaOS Boot Requirements
The current ZimaOS installation guide requires generic x86-64 hardware with at least 25 GB of storage, UEFI boot mode enabled, and Secure Boot disabled. The installation USB should be selected through its UEFI entry.
- Confirm UEFI mode is active.
- Disable Secure Boot.
- Disable CSM or Legacy boot for a clean UEFI test.
- Confirm the target SSD uses GPT rather than an old MBR-only layout.
- After installation, look for a named UEFI boot entry as well as the raw SSD model.
Why “Locked NVRAM” Matters
UEFI firmware stores boot variables in NVRAM. If the firmware rejects a new variable, the installer can copy all operating-system files successfully but still fail to register a boot target. Seeing the SSD model in BIOS only proves the drive is detected; it does not prove the firmware knows which EFI loader to start.
The community suspected unreliable NVRAM handling on this older board. That diagnosis was plausible, but the thread did not include an IceWhale-confirmed board-specific fix.
Use a Non-Destructive Diagnostic Order
- Load firmware defaults, then reapply UEFI mode and disable Secure Boot.
- Check for a firmware update from the motherboard vendor and read its change notes before applying it.
- Disconnect other storage devices during one clean reinstall so the EFI System Partition cannot land on another disk.
- Erase only the intended ZimaOS target after backing up anything important, then let the installer create the GPT layout.
- After installation, inspect the boot menu before removing or rewriting partitions again.
Community Workarounds Are Not the First Choice
Two workarounds were suggested: use a small Linux installation to create a valid EFI entry and repoint it to the ZimaOS loader, or leave a USB device attached only as a bootloader while ZimaOS runs from the SSD. Both approaches add another dependency to every boot and can break after firmware or boot-file changes.
Do not copy EFI files or rewrite NVRAM entries without a recovery USB and a backup. If the firmware consistently blocks boot-variable writes, provide IceWhale support with the board model, BIOS version, installer version, partition layout, and exact error.
Separate a Missing Boot Entry from a Broken ZimaOS Slot
If GRUB appears but ZimaOS itself fails later, that is a different recovery path. Use the current ZimaOS system recovery guide to test the alternate system slot. If GRUB never appears, remain focused on UEFI detection and firmware boot entries.
ZimaOS Boot FAQ
Does BIOS seeing the SSD prove ZimaOS is bootable?
No. The firmware can detect a disk without having a valid EFI loader entry.
Why did Debian boot on the same machine?
Its installer may have registered an entry that this firmware accepted. That does not prove the ZimaOS files were missing.
Should I immediately replace the motherboard?
No. Verify UEFI, GPT, CSM, firmware version, and a clean single-disk install first.
