/etc/kernel/proxmox-boot-uuids missing after Proxmox installation – why?

[wrobelda]

I just installed Proxmox 9 on some of my servers and noticed proxmox-boot-tool status fails with:

Re-executing '/usr/sbin/proxmox-boot-tool' in new private mount namespace..
E: /etc/kernel/proxmox-boot-uuids does not exist.

From what I understand this means it's setup to use GRUB directly, skipping proxmox own tooling. May I ask why is this needed? What am I risking if I recreate /etc/kernel/proxmox-boot-uuids and reinstall GRUB using proxmox-boot-tool init? I assume there's a reason why OVH devs decided to go this way, but I wish it was documented somewhere on why is that a thing.

[sturpin]

Hi @wrobelda

OVH changed the boot configuration for its servers starting November 2025 to fix a critical issue with GRUB updates. There was a problem in the old scheme where multiple EFI system partitions (ESP) were created on each disk and only synchronized during installation. Over time, these partitions became unsynchronized, which could prevent the server from booting after a major GRUB update.

Sure, there is a risk in modifying the system; you’re right, changing this without understanding it can break the boot. OVHcloud developers have customized the system for a reason. One key reason is that OVHcloud servers boot via iPXE, which in turn runs GRUB from the ESP partition.

If you change the boot order or reinstall GRUB using proxmox-boot-tool without the proper option, you can break the server’s boot and also the rescue mode, because grub-install by default tries to write to NVRAM, which is not compatible with OVHcloud’s architecture.

The command I would recommend to reinstall GRUB in this environment is grub-install --no-nvram .

If you need full control over partitioning, OVHcloud also allows installing Proxmox manually using an ISO or netboot.xyz . But for most cases, the installation provided by OVHcloud is the most stable and secure option.

LVM-Thin Proxmox Baremetal

Bonjour, Je voudrais savoir comment faire en sorte de pouvoir configurer un stockage en LVM-Thin en passant par l'outil de partitionnement d'OVH lorsque l'on lance la réinstallation de l'OS (Ici Proxmox 9). J'ai vu des solutions en utilisant le KVM et en chargeant soi-même le média mais de mon coté l'installateur finit en KernelPanic au moment de se charger, et je ne trouve pour autant aucune option viable avec l'outil de partitionnement d'OVH. Cordialement

Hope I helped you,
Sergio Turpín

[wrobelda]

One key reason is that OVHcloud servers boot via iPXE, which in turn runs GRUB from the ESP partition.

Indeed, that's something I noticed, to my surprise. I understand this is to control whether the system successfully booted and, if not, to boot in rescue mode automatically. Still, one can simply pull up a boot menu via KVM and simply tell it to boot rescue iPXE over network, if need.

@sturpin

you can break the server’s boot and also the rescue mode, because grub-install by default tries to write to NVRAM, which is not compatible with OVHcloud’s architecture.

Sure, but these are one-time EFI boot requests that tell it to boot from a specific partition. It doesn't modify the BIOS own settings. In my 10 years experience with Proxmox I never noticed it affecting boot order.

Besides, boot order can and does get changed via IPMI as well, because despite my explicit configuration where where I placed HDD first and Network second, their tool still successfully booted the rescue-installer using the iPXE when I attempted to reinstall OS using their template. I can ask to boot in rescue mode from the Dashboard no matter the boot order settings and it also works.

So, with all respect, I just don't see it.

OVHcloud developers have customized the system for a reason

It also makes it nearly impossible to enable Secure Boot using the built in provision, since it all relies on proxmox-boot-tool (https://pve.proxmox.com/wiki/Secure_Boot_Setup#Using_a_Proxmox_Project_with_Secure_Boot). And don't even get me started on UKI and LUKS. Do OVH customers not use encryption?! What guarantee do you have your data is fully destroyed when they dispose your server or disks?

I can also only guess the amount of issues this will bring in future upgrades of Proxmox, especially when dist-upgrading to next release, considering how excessively they rely on proxmox-boot-tool in speech.

All in all, it's hacky, it's not transparent and at the very least it should be documented with clear information on WHY does it do that and, ideally, how to restore "regular" EFI/boot partition.

I appreciate your response, though, that's very helpful.

[le_sbraz]

@wrobelda

Indeed, that's something I noticed, to my surprise. I understand this is to control whether the system successfully booted and, if not, to boot in rescue mode automatically. Still, one can simply pull up a boot menu via KVM and simply tell it to boot rescue iPXE over network, if need.

Hi,
The only way for us to fully control whether servers boot to disk or to rescue (which is required for several operations like the installation process) is to make servers boot over the network.
We can't simply install the OS in rescue and then change the boot order to boot to disk directly; we'd lose the ability to reinstall the server without manual intervention or touching the BMC.
We also apply microcodes updates when you boot to disk via PXE, no matter what OS you have installed (e.g. even if you run an old Linux distribution with old microcodes installed).

I suggest reading https://docs.ovhcloud.com/en/guides/bare-metal-cloud/dedicated-servers/boot-process if you have time, I believe it answers some of your questions.

@wrobelda

I assume there's a reason why OVH devs decided to go this way, but I wish it was documented somewhere on why is that a thing.

Our Proxmox VE 9 image is created from Debian 13's official cloud image, which comes with GRUB. Our image creation process mostly consists of following https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_13_Trixie.
It's also a bit easier for us not having to handle different bootloaders for all Linux distros; at the moment, we use GRUB everywhere.

@wrobelda

I never noticed it affecting boot order.

It does make GRUB the first boot entry:

• efibootmgr -c is called here: https://cgit.git.savannah.gnu.org/cgit/grub.git/tree/grub-core/osdep/unix/platform.c?h=grub-2.12#n165
• The new boot entry gets inserted at the beginning of the boot order (-I | --index number When creating an entry, insert it in bootorder at specified position (default: 0). from efibootmgr -h).

@wrobelda

Besides, boot order can and does get changed via IPMI as well

Not all servers have a BMC/IPMI.

@wrobelda

I placed HDD first and Network second, their tool still successfully booted

We ask board vendors to customise the UEFI firmware to ensure PXE is always the first boot option so your changes were likely discarded. What does efibootmgr show on your server? I assume PXE is still first.

@wrobelda

It also makes it nearly impossible to enable Secure Boot

Fair point.

@wrobelda

I can also only guess the amount of issues this will bring in future upgrades of Proxmox, especially when dist-upgrading to next release, considering how excessively they rely on proxmox-boot-tool in speech.

If Proxmox stops supporting GRUB, we'll update our images. So far, I haven't heard anything to that effect.

@wrobelda

it's not transparent

That's why we wrote the documentation I mentioned above. If you have any suggestions to make it more visible or easier to understand, please let me know.

So, overall, we have nothing against proxmox-boot-tool and it's very likely that it could be used in conjunction with PXE boot but we haven't felt compelled to so far.

[fritz2cat]

Thank you Louis for this detailed explanation, @le_sbraz