↓Skip to main content
SYNKEE

From Intermittent 'OS Not Found' to Bulletproof Reboots: Mastering EFI and GRUB in Proxmox VE

·4 mins

Introduction #

In homelab and production Proxmox VE environments, reboot reliability is table stakes. Yet even experienced admins occasionally encounter the dreaded “OS not found” screen after a simple reboot command — requiring a full power cycle to recover.

This was exactly the situation we faced with a Proxmox VE 9.1.1 node (Debian Trixie base) running on GRUB. The server would boot perfectly 80 % of the time, then randomly drop into the firmware “no operating system” state.

Instead of accepting it as “just one of those things,” we performed a systematic diagnosis and applied targeted fixes that eliminated the issue entirely.

This article walks through the root cause, the precise commands that resolved it, and the broader lessons for anyone managing Proxmox (or any modern UEFI-based Linux server).

The Symptoms and Initial Diagnosis #

Our node exhibited classic intermittent boot failure:

  • reboot sometimes succeeded.
  • Other times the system hung at the firmware stage with “OS not found.”
  • Only a hard power-off + power-on would bring it back.

efibootmgr -v quickly revealed the smoking gun:

  • BootCurrent: 0001 (proxmox entry — correct)
  • BootOrder: proxmox first (good)
  • Timeout: only 1 second
  • Multiple stale entries (Windows Boot Manager, VMware ESXi, generic USB/CD devices)

Combined with GRUB’s default GRUB_TIMEOUT=5, the firmware simply didn’t give the SSD enough time to initialize during cold boots or certain power states.

The Fix: Three Targeted Changes #

We applied the following fixes in sequence — all via SSH, zero downtime beyond the final test reboot.

1. Extend GRUB Menu Timeout #

sed -i 's/GRUB_TIMEOUT=5/GRUB_TIMEOUT=10/' /etc/default/grub
update-grub

This gives the bootloader 10 seconds to present the menu and let disks spin up.

2. Extend UEFI Firmware Timeout #

efibootmgr -t 5

Increasing the firmware-level boot menu timeout from 1 s to 5 s ensures the EFI environment waits long enough for the system drive to be ready.

3. Clean Up Unnecessary EFI Boot Entries #

We removed stale entries that cluttered the boot order:

efibootmgr -b 0000 -B   # Windows Boot Manager
efibootmgr -b 0002 -B   # VMware ESXi
# (optionally remove generic USB, CD, Shell, etc.)
efibootmgr -v           # verify clean list

Results and Validation #

After the changes:

  • efibootmgr -v now shows Timeout: 5 seconds and a clean BootOrder with proxmox at position 0001.
  • Multiple reboot cycles (both warm and cold) completed without a single “OS not found” incident.
  • No impact on existing GPU passthrough (Tesla P4 VFIO), LVM-thin storage, or network bridges.

The server is now rock-solid.

Broader Lessons for Proxmox Boot Reliability #

  1. Short firmware timeouts are the #1 hidden culprit in modern UEFI servers.
  2. Stale EFI entries from previous OS installs or hypervisors create noise that can delay boot.
  3. GRUB_TIMEOUT and efibootmgr -t are the two levers you should always check before blaming hardware.
  4. Even when using proxmox-boot-tool on other nodes, the same EFI principles apply — understanding the underlying boot chain prevents mysterious failures.

How SYNKEE can help #

SYNKEE is a Singapore-based engineering team with deep expertise in:

  • Designing AI-assisted development workflows and prompt engineering practices.
  • Building reusable knowledge systems and documentation frameworks.
  • Helping engineering teams transition from traditional code reuse patterns to AI-native development practices.
  • Creating structured specifications and internal knowledge repositories that work seamlessly with modern AI coding tools.

If your organization is running Proxmox (or any Linux infrastructure) and wants to eliminate boot flakiness, systematize server hardening, or capture these kinds of fixes as reusable prompt-ready specifications for your internal AI coding assistants, contact us to discuss how we can help accelerate your infrastructure reliability journey.

Conclusion #

What started as an annoying intermittent reboot failure turned out to be a simple mismatch between modern SSD initialization times and ultra-short UEFI/GRUB defaults.

By extending timeouts and pruning unnecessary boot entries, we transformed an unreliable node into one that reboots flawlessly every single time.

In the infrastructure world, the smallest parameters often make the biggest difference. The next time your Proxmox (or any UEFI Linux server) greets you with “OS not found,” remember: the fix is usually just a few efibootmgr and GRUB tweaks away.

Happy (and reliable) rebooting!