FreeBSD en CloudInit: marchait en mars, ne marche plus en décembre?

system · December 12, 2025, 9:43am

Quelqu'un a-t-il pu installer une FreeBSD (14.2, 14.3, 15.0) en BYOI ces derniers mois?

Sur ma KS-LE-1 (ns301819.ip-94-23-44.eu), une install d'une 14.2 en mars s'était super bien passée; en retentant une install' avec le même paramétrage (notamment l'image FreeBSD-14.2-RELEASE-amd64-BASIC-CLOUDINIT.ufs.raw.xz n'avait pas bougé, SHA256 à l'appui) en décembre, plus de réponse au ping.

Savoir que d'aucuns ont un FreeBSD fonctionnel, avec date et paramétrage d'install, ainsi que l'organisation des partoches (gpart show), m'aiderait à cerner ce que j'ai pu foirer (… ou si un changement OVH est à incriminer).

Là seul le rescue démarre, et voit un disque UFS de 5 Go dont 2,5 d'occupés, avec des dates correspondant à l'image installée: la copie disque s'est bien déroulée. Par contre /var/log/ absolument vide: le FreeBSD n'a jamais dû atteindre son amorçage. D'où j'imagine un problème dès le loader.efi (et avec une machine sans IPMI / KVM pas facile d'y voir clair…).

Donc mon interrogation: y aurait-il eu une modification du script de réinstall OVH, sur la partie config de l'EFI?
Je note que le PUT /dedicated/server/{serviceName} est sans effet sur efiBootloaderPath: j'ai beau le pousser (avec des /, des \\, des \\\\), un GET juste après le voit toujours revenir vide.
Cela dit le loader.efi FreeBSD est placé en \EFI\BOOT\bootx64.efi sur l'ESP, donc devrait être trouvé puisque c'est le chemin par défaut où l'EFI cherche:

cksum /tmp/d2/EFI/BOOT/bootx64.efi /tmp/d5/boot/loader.efi
2680227830 665088 /tmp/d2/EFI/BOOT/bootx64.efi
2680227830 665088 /tmp/d5/boot/loader.efi

Mais je ne peux inspecter la NVRAM avec le rescue (efibootmgr: "EFI variables are not supported on this system.". Est-ce normal?).
Notons que la première réinstall qui a provoqué le foutoir (d'une 15.0: je pensais la réinstall le moyen le plus rapide de passer de 14.2 en 15.0 sur une machine inutilisée) a été interrompue par une intervention OVH "défaut de redémarrage" suivi de "incident terminé, la réinstall de votre serveur va maintenant reprendre".

Autre point à noter: depuis la rescue, parted --list braille deux fois (mais peut-être est-il normal les partoches soient créées à l'arrache avant le growfs?):

Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used.
Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 3894377392 blocks) or continue
with the current setting?
Number  Start   End     Size    File system  Name          Flags
 1      17.4kB  79.9kB  62.5kB               bootfs
 2      79.9kB  34.2MB  34.1MB  fat32        efiboot0      boot, esp
 3      34.2MB  1108MB  1074MB               swapfs
 4      1108MB  1109MB  1049kB               config-drive
 5      1109MB  6478MB  5369MB  freebsd-ufs  rootfs

system · December 12, 2025, 10:59am

Hum, alors le truc rigolo (suite à la rescue qui apparemment n'est pas du tout EFI), c'est qu'en installant une Debian 12, l'OS marche parfaitement au bout… mais avec une première partoche en bios_grub, et un efibootmgr convaincu qu'il n'est pas du tout sur un système démarré en EFI.

Se pourrait-il que ma carte-mère (KS-LE-1 achetée en mars 2025) soit incapable d'EFI, mais que le script d'install ne sache (plus?) faire que de l'EFI?

le_sbraz · December 12, 2025, 12:55pm

Bonjour et merci d'avoir mis le nom du serveur, ça m'a permis d'aller vérifier ses specs et les logs :)

Je vous confirme que la carte mère DH67BL est ancienne et que nous n'avons jamais activé l'UEFI dessus (je ne sais même pas si ça fonctionnerait).

Comme le serveur est en boot legacy, efiBootloaderPath n'est pas utilisé. En UEFI, iPXE lance sanboot --drive 0 --filename $efiBootloaderPath

Par contre, en legacy, iPXE exécute sanboot --no-describe --drive 0x80 pour chaîner sur le premier disque BIOS. Il est possible que l'image FreeBSD en question ne supporte pas bien le boot legacy, je vais me renseigner à ce sujet et tenter des installations sur quelques machines en boot legacy dont une ayant la même carte mère DH67BL.

Pour ce qui est de la réinstall avec intervention, d'après les détails laissés par le technicien, le serveur avait un boot order incorrect (il devait booter sur disque sans passer par PXE + iPXE donc ne démarrait pas en rescue). Chez nous, les serveurs doivent booter en PXE, sinon impossible de faire l'aiguillage rescue/disque.

Pour l'erreur "Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used.", je pense que c'est parce que la table de backup est en fin d'image. Quand on la copie sur disque, la fin de l'image se retrouve quelque part au milieu du disque (qui est plus grand que l'image). Comme on ne sait pas si le client met une image GPT ou MBR, on ne peut pas aller "fix le GPT" lors de l'installation.

Et l'erreur "Not all of the space available to /dev/sda appears to be used" vient bien du fait que la dernière partition de l'image se termine avant la fin du disque, ça me semble normal avant le grows.

system · December 12, 2025, 2:30pm

Merci pour les explications!

Pour l'intervention, tout à fait d'accord pour le PXE.
Pour le GPT, oui, je me dis aussi que le growfs prévu par le nuageinit (et bien présent dans l'/etc/rc.conf, n'attendant plus que le lancement de l'OS…) aurait tout réglé.

Par acquis de conscience, après avoir éclusé toutes les installs en CLOUDINIT, j'ai tenté une version non CLOUDINIT (FreeBSD-15.0-RELEASE-amd64-ufs.qcow2.xz), et là, oh miracle, j'ai le ping! Mais serveur non joignable en SSH, j'imagine pour cause de fin d'install interactive via console.
Je vais voir si ça peut être une voie de résolution (rescue, montage de la partoche UFS, avec un peu de chance il y a juste à activer le sshd dans l'/etc/rc.conf).

Petite différence d'organisation du disque (outre pas d'erreur GPT, avec un UFS qui occupe bien les 2 To disponibles):

Number  Start   End     Size    File system  Name          Flags
 1      17.4kB  79.9kB  62.5kB               bootfs
 2      79.9kB  34.2MB  34.1MB  fat32        efiboot0      boot, esp
 3      34.2MB  1108MB  1074MB               swapfs
 4      1108MB  2000GB  1999GB  freebsd-ufs  rootfs
 5      2000GB  2000GB  1052kB               config-drive

Le config-drive se retrouve à la fin, alors qu'avant il était entre swapfs et rootfs: est-ce ce qui aurait pu perturber iPXE en legacy (prendre le config-drive CloudInit pour un disque bootable)?

system · December 12, 2025, 7:32pm

Sans résoudre la question de "pourquoi la réinstall sur carte mère non-UEFI à partir des images CLOUDINIT donne-t-elle une machine non démarrante?", une solution de contournement:

L'install' d'une FreeBSD 15.0 peut se faire à partir d'une image non-CLOUDINIT (FreeBSD-15.0-RELEASE-amd64-ufs.raw.xz) (cf. le fil de discussion sous la réponse de @le_sbraz).

Cette image ne livrant pas un système clés en main, il est nécessaire de la modifier pour au moins avoir sshd de démarré.
Ex. grâce à un autre FreeBSD (10.2 dans mon cas!) possédant un serveur HTTP:

curl -O https://download.freebsd.org/releases/VM-IMAGES/15.0-RELEASE/amd64/Latest/FreeBSD-15.0-RELEASE-amd64-ufs.raw.xz
xz -d -c FreeBSD-15.0-RELEASE-amd64-ufs.raw.xz > FreeBSD-15.0-RELEASE-amd64-ufs.raw
mdconfig -a -t vnode -f FreeBSD-15.0-RELEASE-amd64-ufs.raw -u 0
mkdir /tmp/fbsd15
mount /dev/md0p4 /tmp/fbsd15
vi /tmp/fbsd15/etc/rc.conf # Ajouter sshd_enable="YES" 
vi /tmp/fbsd15/etc/ssh/sshd_config # PermitRootLogin yes
mkdir /tmp/fbsd15/root/.ssh 
cat > /tmp/fbsd15/root/.ssh/authorized_keys <<TERMINE
[…] # Votre clé SSH
TERMINE
chmod go-rwx /tmp/fbsd15/root/.ssh
umount /tmp/fbsd15
mdconfig -d -u 0
xz < FreeBSD-15.0-RELEASE-amd64-ufs.raw > FreeBSD-15.0-RELEASE-amd64-ufs+sshd.raw.xz

L'image FreeBSD-15.0-RELEASE-amd64-ufs+sshd.raw.xz résultante doit ensuite être exposée en HTTP, dont on récupère l'URL pour lancer la réinstall' du serveur.

le_sbraz · December 12, 2025, 8:04pm

Merci pour l'info. En effet la partie modification de l'image est contraignante si on n'a pas de BSD car on ne pourra pas écrire l'UFS2 depuis un Linux.

De mon côté, j'ai bien un souci avec un serveur en DH67BL comme le votre alors que ça semble booter sur une autre machine en legacy. Ça va me prendre un peu de temps de refaire des tests. Je vais me concentrer sur l'image https://download.freebsd.org/releases/VM-IMAGES/15.0-RELEASE/amd64/Latest/FreeBSD-15.0-RELEASE-amd64-BASIC-CLOUDINIT-ufs.raw.xz

Et sinon, si le config-drive arrive en quatrième, c'est qu'il est déjà présent dans l'image cloud-init alors que sur l'image normale, nous l'ajoutons (donc elle arrive en cinquième position).

$ parted FreeBSD-15.0-RELEASE-amd64-BASIC-CLOUDINIT-ufs.raw GNU Parted 3.6 Using /root/FreeBSD-15.0-RELEASE-amd64-BASIC-CLOUDINIT-ufs.raw Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Model: (file) Disk /root/FreeBSD-15.0-RELEASE-amd64-BASIC-CLOUDINIT-ufs.raw: 6478MB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 17.4kB 79.9kB 62.5kB bootfs 2 79.9kB 34.2MB 34.1MB fat32 efiboot0 boot, esp 3 34.2MB 1108MB 1074MB swapfs 4 1108MB 1109MB 1049kB config-drive 5 1109MB 6478MB 5369MB freebsd-ufs rootfs (parted) $ parted FreeBSD-15.0-RELEASE-amd64-ufs.raw GNU Parted 3.6 Using /root/FreeBSD-15.0-RELEASE-amd64-ufs.raw Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Model: (file) Disk /root/FreeBSD-15.0-RELEASE-amd64-ufs.raw: 6477MB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 17.4kB 79.9kB 62.5kB bootfs 2 79.9kB 34.2MB 34.1MB fat32 efiboot0 boot, esp 3 34.2MB 1108MB 1074MB swapfs 4 1108MB 6477MB 5369MB freebsd-ufs rootfs

(parted)

Je ne pense pas que ça soit qui pose problème mais il faut que je fasse plus de tests sur des machines en boot legacy pour bien comprendre.

system · December 13, 2025, 10:05am

Chouette que ça soit reproductible! C'est une machine avec un peu plus de possibilité de diagnostic (console) que la mienne? Je découvre un peu toutes ces questions de firmwares de boot, mais est-ce que l'iPXE permettrait d'avancer de façon plus interactive (dommage qu'avec toutes ses capacités réseau, TFTP, HTTP, iPXE ne propose pas encore de telnet en alternative à la console)?

system · December 13, 2025, 2:13pm

Hypothèse (avec de très bonnes raisons d'y croire):
Le PXE ne serait-il pas ultrasensible à ce que chaque disque ait au moins une GPT correcte?
Donc sur ma machine à 3 disques (prévue pour du Soft RAID), même si je ne prévois d'utiliser que le 0, il suffirait que mon disque 2 ne soit pas initialisé pour faire partir en vrille le PXE.

Les péripéties qui m'y ont amené:

en mars, j'avais donc une FreeBSD 14.2 CloudInit (mettons CI pour abréger) fonctionnelle
hier 12 décembre, après pas mal de frayeurs, j'avais une FreeBSD 15.0 non-CI personnalisée (image non-CI retapée pour sshd démarré)
Rappel de l'itinéraire: FBSD 15.0 CI foirée → FBSD 14.2 CI foirée → Debian 12 fonctionnelle → FBSD 15.0 non-CI fonctionnelle → FBSD 15.0 non-CI + sshd fonctionnelle
hier soir, apprenti sorcier souhaitant continuer à diagnostiquer, j'ai voulu remettre en jeu ma machine pour une série de réinstalls (après avoir sécurisé mon install' fonctionnelle pour pouvoir rapidement revenir dessus)
Le plan foireux: dupliquer mon disque 0 sur le disque 2, puis tenter de concocter un bootScript iPXE qui puisse démarrer du disque 2.
Outre ne pas connaître iPXE j'ai voulu optimiser mon clonage de disque (dd if=/dev/sda of=/dev/sdc, mais avec des bs=1048576 count=… puis skip=… pour ne prendre que les 8 premiers et le dernier Go, en espérant que le reste serait constitué de 0), et en fait j'ai oublié le seek=… en face du skip=…, bref j'ai massacré le volume.
Mais fait notable: après ce pourrissage du disque 2 même le démarrage "standard" depuis le disque 0 ne se faisait plus.
tentatives de réinstaller mes FBSD 15.0 qui avaient fonctionné: chou blanc. Re-frayeurs. Et formulation de l'hypothèse sur la bonne santé du disque 2, nécessaire au PXE.
(en me rappelant notamment que les recommandations d'install BYOI incluent du "storage": [{"diskGroupId":1,"hardwareRaid":[],"partitioning":{"disks":1,"schemeName": "default"}}. Notons le "disks":1, qui va laisser les deux autres disques en l'état (massacré).
réinstall' d'une Debian 12 (au fait du Soft RAID, donc qui va GPTer les 3 disques)
réinstall' d'une FBSD 15.0 CI, fonctionnelle
Donc le problème n'était pas CloudInit ou pas CloudInit, le problème était juste d'avoir les 3 disques d'aplomb pour que le PXE (ou le BIOS derrière) commence à les parcourir à la recherche du premier bootable.

J'ai derrière redétruit volontairement mon disque 2, pour essayer une réinstall' avec "disks": 3, mais sans succès.
Un coup de rescue pour parted /dev/sdb mkt gpt (et idem sdc) n'a pas marché non plus.

le_sbraz · December 15, 2025, 11:55am

Merci pour le debug. Ça me rappelle en effet des problèmes que l'on a pu voir par le passé sur des serveurs en boot legacy.

Difficile à vérifier précisément sur la machine où on fait nos tests car elle n'a pas de KVM mais, parfois, il était nécessaire de changer l'ordre des disques dans le BIOS dans le menu "Hard Disk Drive BBS Priorities" pour mettre celui qui contient l'OS en premier :

Je vais voir si je retrouve un comportement similaire au votre sur mon serveur ayant 2 disques. La théorie serait que le mauvais disque est en premier dans le boot order, que, lorsqu'iPXE exécute sanboot --no-describe --drive 0x80, la carte mère tente de booter sur le premier disque qui n'est pas partitionné et ça bloque. Si le fait d'ajouter un GPT valide sur le second disque permet au système de passer au disque suivant, c'est en effet une information intéressante. Sinon, peut-être qu'un script iPXE lançant juste "exit" aiderait et la carte mère passerait seule au disque suivant.

Heureusement, ce problème n'est pas présent sur les serveurs en boot UEFI où iPXE trouve le disque de boot en fonction du efiBootloaderPath qu'on lui donne.

> Réinstall' avec "disks": 3: sans succès.

BYOI n'installe que sur le premier disque, c'est une limite de ce système. C'est pourquoi on propose aussi Bring Your Own Linux (mais ça ne fonctionnerait pas aisément avec BSD à moins de tout partitionner en ZFS et de faire un script make_image_bootable.sh qui soit capable d'installer le bootloader de FreeBSD depuis Linux).

> certaines autres (clé SSH) sont placées dans le config-drive

En effet, l'intégralité de la customization de l'OS se fait par cloud-init qui lit la partition config-drive.

le_sbraz · December 15, 2025, 8:32pm

Ça ressemble bien à un souci de boot order. J'ai créé un GPT sur le second disque : ça ne bootait pas. J'y ai alors recopié la table des partitions du premier et le contenu de chacune partition : ça boote.
J'ai ensuite enlevé toutes les signatures du premier disque et ça ne semble plus booter.
Il faudrait vraiment un KVM pour voir ce qui se passe.

system · December 15, 2025, 9:31pm

Comme je précisais un peu noyé dans mon roman du 13 à 16 h 49:

avoir juste la table GPT ne suffit pas,
mais pas la peine d'avoir des partitions pleines: du moment que la GPT liste au moins une partition, ça peut démarrer

D'où le:
parted /dev/sdc mkt gpt
parted /dev/sdc mkpart bios_grub 1049k 2097k

Peut-être qu'une option "réinitialiser les autres disques" (décochée par défaut) dans le /reinstall ferait l'affaire.

Ce qui serait sans doute plus simple que de permettre de pousser tous les diskGroupId (plus simple à la fois à l'implémentation, et pour le client: va-t'en comprendre que pour rendre démarrable ta machine il faut que tu renseignes autant de diskGroupId que de disques, dont 1 qui peut accepter la valeur default (= remplacement par l'image) mais pour les autres comme il n'y a pas de défaut il faut un partitioning avec au moins un fileSystem: "none").

le_sbraz · December 15, 2025, 9:57pm

Désolé, j'ai essayé de lire tout mais je suis allé trop vite :) J'essaie de tester demain si j'ai le temps (et aussi en créant une partition d'un autre type et à un autre offset). Merci pour tous les tests, c'est un cas particulier intéressant.

Ne pas nettoyer les disques, c'est s'exposer à de nombreuses erreurs lors de la réinstall (parce que le client a laissé un device md0 en doublon avec celui qu'on est en train d'ajouter, idem un LVM). Il est peu probable qu'on le propose à court ou moyen terme.

On est ici sur une configuration très rare :

une carte mère extrêmement ancienne
qui n'a probablement pas le "premier" disque en premier dans le boot order
où on n'installe que sur un disque
où il n'y a pas de KVM pour voir ce qui se passe au boot

Il est rare que ces conditions soient réunies donc je ne suis pas certain de pouvoir justifier l'effort d'un développement supplémentaire ou d'une rédaction documentaire appropriée (sans pour autant inquiéter la majorité qui n'est pas concernée par le problème).
Si jamais vous avez des idées pour améliorer la documentation, elle est sur GitHub et on accepte les PR : https://github.com/ovh/docs/blob/develop/pages/bare_metal_cloud/dedicated_servers/bring-your-own-image/guide.en-gb.md.

Évidemment, l'idéal serait de faire une installation avec du RAID ZFS et le bootloader sur tous les disques. Dans le genre de https://community.ovhcloud.com/community?id=community_user_profile&user=fdd9cb9161a89a90f078e6dcf9270b1d / https://community.hetzner.com/tutorials/freebsd-openzfs-via-linux-rescue
Par contre, en legacy, je ne sais pas comment vous pourriez installer le bootloader.

system · December 18, 2025, 9:02am

Effectivement, se lancer dans un dév serait sans doute prendre un marteau pour faire casse-noix (+ comme par sécurité je proposais de conditionner à une case à cocher décochée par défaut, ça pourrait finir jamais utilisé, ou alors avec le support obligé de faire remarquer l'existence de la case à cocher).

Donc c'est parti pour une demande d'enrichissement de la doc en PR #8837, en attente de

la reproductibilité du problème et de sa résolution (par mise au propre du partionnement des disques secondaires), et
validation de la forme (emplacement et tournure du nouveau bout de doc assez neutres pour ne pas affoler)

Merci pour l'orientation, technique au départ pour me mettre sur la piste et aboutir à la solution, documentaire ensuite pour en faire profiter d'éventuels autres clients!