Skip to content

[PUBM-49999] Add boot process guide for dedicated servers#9022

Merged
Y0Coss merged 1 commit intodevelopfrom
PUBM-49999_dedicated_boot_process
Feb 6, 2026
Merged

[PUBM-49999] Add boot process guide for dedicated servers#9022
Y0Coss merged 1 commit intodevelopfrom
PUBM-49999_dedicated_boot_process

Conversation

@sbraz
Copy link
Member

@sbraz sbraz commented Feb 5, 2026

What type of Pull Request is this?

  • New guide(s)

Description

Explain how OVHcloud dedicated servers boot using netboot (PXE/iPXE)
and why customers should not modify the BIOS/UEFI boot order.

Topics covered:

  • Boot flow: PXE → iPXE → boot service → boot script
  • Boot modes: boot to disk, customer rescue, custom boot script
  • Microcode updates applied transparently during boot
  • UEFI vs legacy boot paths with rEFInd fallback
  • OLA (all-private interfaces) exception and self-hosted boot

Also adds links from BYOL/BYOI guides and pages/index.md.

Mandatory information

The translations in this Pull Request have been done using:

  • This Pull Request didn't require any translation.
  • This Pull Request can be merged as soon as possible.

This Pull Request content should be replicated for the US OVHcloud documentation : YES

Already reviewed by @JayBeeDe, I just changed the following since his review:

diff --git a/pages/bare_metal_cloud/dedicated_servers/boot-process/guide.en-gb.md b/pages/bare_metal_cloud/dedicated_servers/boot-process/guide.en-gb.md
index d7954a308d..b559dcb890 100644
--- a/pages/bare_metal_cloud/dedicated_servers/boot-process/guide.en-gb.md
+++ b/pages/bare_metal_cloud/dedicated_servers/boot-process/guide.en-gb.md
@@ -6,7 +6,7 @@ updated: 2026-02-04
 
 ## 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 rather than in the [OVHcloud Control Panel](/links/manager) or [OVHcloud API](/links/api).
+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](/links/manager) or the [OVHcloud API](/links/api).
 
 **This guide will help you understand:**
 
@@ -42,7 +42,7 @@ 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 live rescue system | Troubleshooting, recovery, first-time setup |
+| **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
@@ -51,7 +51,7 @@ When set to **boot to disk**, the boot process follows these steps:
 
 **1. Microcode update**
 
-The system downloads and applies the latest [CPU microcode](https://blog.ovhcloud.com/ovhcloud-microcode-management-at-scale/) for your processor (AMD or Intel). This happens transparently and provides security patches without requiring OS-level or firmware/BIOS updates.
+The system downloads and applies the latest [CPU microcode](https://blog.ovhcloud.com/ovhcloud-microcode-management-at-scale/) for your processor (AMD or Intel). This happens transparently and provides security patches without requiring OS-level or BIOS/UEFI updates.
 
 > [!primary]
 >
@@ -70,14 +70,14 @@ The system downloads and applies the latest [CPU microcode](https://blog.ovhclou
 
   The `efiBootloaderPath` can be changed via the [OVHcloud API](/links/api):
 
-> [!api]
->
-> @api {v1} /dedicated/server PUT /dedicated/server/{serviceName}
->
+  > [!api]
+  >
+  > @api {v1} /dedicated/server PUT /dedicated/server/{serviceName}
+  >
 
 #### Customer rescue mode
 
-A live rescue 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](/pages/bare_metal_cloud/dedicated_servers/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](/pages/bare_metal_cloud/dedicated_servers/rescue_mode).
 
 #### Custom boot scripts
 
@@ -100,18 +100,20 @@ For advanced use cases, you can configure a custom iPXE script via the [OVHcloud
 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 `efiBootloaderPath` to chain to the bootloader.
 - **Microcode updates**: Security patches are applied during the boot process.
-- **Monitoring and recovery**: OVHcloud tools depend on the netboot mechanism.
 
 **If you change the boot order:**
 
-- Boot mode changes made in the Control Panel will have no effect.
+- Boot mode changes made in the 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 you have configured your server in **[OLA (OVHcloud Link Aggregation)](/pages/bare_metal_cloud/dedicated_servers/ola-enable-manager)** mode with all interfaces set to private (vRack), the standard netboot process will not work. Private interfaces cannot reach the OVHcloud DHCP and boot infrastructure.
+If your server uses **[OLA (OVHcloud Link Aggregation)](/pages/bare_metal_cloud/dedicated_servers/ola-enable-manager)** — 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](/pages/bare_metal_cloud/dedicated_servers/pxe-with-full-private-dedicated).
 

@sbraz sbraz requested a review from Y0Coss February 5, 2026 17:25
@Y0Coss Y0Coss added Offer: Bare Metal The PR documents Bare Metal products: Dedicated Servers, VPS Guide creation The Pull Request contains at least 1 new guide (meta.yaml and index edition needed) labels Feb 6, 2026
Explain how OVHcloud dedicated servers boot using netboot (PXE/iPXE)
and why customers should not modify the BIOS/UEFI boot order.

Topics covered:
- Boot flow: PXE → iPXE → boot service → boot script
- Boot modes: boot to disk, customer rescue, custom boot script
- Microcode updates applied transparently during boot
- UEFI vs legacy boot paths with rEFInd fallback
- OLA (all-private interfaces) exception and self-hosted boot

Also adds links from BYOL/BYOI guides and pages/index.md.
@sbraz sbraz force-pushed the PUBM-49999_dedicated_boot_process branch from aea73f3 to b7a76b0 Compare February 6, 2026 17:14
@Y0Coss Y0Coss merged commit 8865287 into develop Feb 6, 2026
@Y0Coss Y0Coss deleted the PUBM-49999_dedicated_boot_process branch February 6, 2026 17:27
@Y0Coss
Copy link
Collaborator

Y0Coss commented Feb 6, 2026

Thank you for the update @sbraz

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Guide creation The Pull Request contains at least 1 new guide (meta.yaml and index edition needed) Offer: Bare Metal The PR documents Bare Metal products: Dedicated Servers, VPS

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants