Understanding the dedicated server boot process
Objective
OVHcloud dedicated servers use a network-based boot process (netboot) that provides flexibility and security benefits. This guide explains how the boot process works and why you should not change the default boot order directly in the BIOS/UEFI settings, but instead use the OVHcloud Control Panel or the OVHcloud API.
This guide will help you understand:
- How the OVHcloud boot process works
- The available boot modes
- Why PXE must remain first in the BIOS/UEFI boot order
- How microcode updates are applied automatically
Requirements
- A dedicated server in your OVHcloud account
- Access to the OVHcloud Control Panel or to the OVHcloud API
Instructions
How the boot process works
OVHcloud dedicated servers use iPXE, an advanced network boot firmware, to boot from the network. When you set a boot mode for your server, OVHcloud automatically configures the corresponding iPXE script. When the server powers on, it follows this sequence:
- PXE boot via DHCP: The server boots from the network using DHCP on the public interface.
- Download iPXE: The DHCP server provides the server's public IP address and a filename to download iPXE.
- Query boot service: iPXE queries an internal OVHcloud boot service to retrieve the script to execute.
- Execute script: iPXE executes the script based on your configured boot mode.
This process happens every time your server boots.
Boot modes
You can configure your server to boot in one of the following modes:
| Boot mode | Description | Use case |
|---|---|---|
| Boot to disk | Boots the operating system installed on disk | Normal operation |
| Customer rescue | Boots into a temporary operating system | Troubleshooting, recovery, first-time setup |
| Custom boot script | Executes a user-defined iPXE script | Advanced use cases (volatile OS, custom deployment) |
Boot to disk
When set to boot to disk, the boot process follows these steps:
1. Microcode update
The system downloads and applies the latest CPU microcode for your processor (AMD or Intel). This happens transparently and provides security patches without requiring OS-level or BIOS/UEFI updates.
Microcode updates are verified (signature checked) before being applied. If the microcode download fails, the boot process continues normally — your server will still boot.
2. Boot to operating system
- Legacy boot servers: iPXE uses
sanbootto boot directly from the first disk. -
UEFI boot servers: iPXE uses
sanbootto boot the EFI bootloader path (efiBootloaderPath) specified during OS installation (e.g.\efi\debian\grubx64.efi).When OVHcloud installs an operating system, the boot order is not modified (e.g. GRUB is installed with the
--no-nvramoption) to ensure PXE remains first.If
sanbootfails (e.g. the specified file is broken or cannot be found), iPXE falls back to rEFInd, which auto-detects EFI bootloaders.The
efiBootloaderPathcan be changed via the OVHcloud API:
Customer rescue mode
A temporary operating system for troubleshooting, recovery, and initial configuration. Microcode updates are applied before booting into rescue, just as with boot to disk. For more information, see Activating and using rescue mode.
Custom boot scripts
For advanced use cases, you can configure a custom iPXE script via the OVHcloud API. For more information, see Configuring a custom iPXE script.
Custom boot scripts skip the automatic microcode loading described above.
Why you must not change the boot order
Do not change the boot order in your server's BIOS/UEFI settings or via tools like efibootmgr. PXE (network boot) must remain the first boot option.
If you install an operating system manually, ensure your bootloader does not modify the NVRAM boot order (e.g. use grub-install --no-nvram).
OVHcloud relies on the network boot process for:
- Boot mode selection: The boot service determines whether to boot to rescue, disk, or a custom script.
- UEFI boot to disk: OVHcloud does not create EFI boot entries — iPXE uses
efiBootloaderPathto chain to the bootloader. - Microcode updates: Security patches are applied during the boot process.
If you change the boot order:
- ❌ Boot mode changes made in the OVHcloud Control Panel or via the OVHcloud API will have no effect.
- ❌ UEFI servers may fail to boot (no EFI boot entry exists for the on-disk bootloader).
- ❌ Rescue mode will no longer be accessible.
- ❌ Microcode updates will no longer be applied automatically.
- ❌ OVHcloud support may be unable to assist with boot issues.
Servers with private-only interfaces (OLA)
If your server uses OLA (OVHcloud Link Aggregation) — a vRack-only configuration with no public interface — the standard netboot process will not work. Private networks cannot reach the OVHcloud DHCP and boot infrastructure.
In this case, you must deploy your own DHCP, TFTP, and boot services within your private network. For detailed instructions, see the guide on Managing server reboot with OVHcloud Link Aggregation.
As of February 2026, OVHcloud is working on native support for netboot over private networks. This guide will be updated when the feature becomes available.
Go further
Activating and using rescue mode
Configuring a custom iPXE script
Managing server reboot with OVHcloud Link Aggregation
OVHcloud microcode management at scale
Join our community of users.