Serveurs Dédiés Eco - FreeBSD en CloudInit: marchait en mars, ne marche plus en décembre?
... / FreeBSD en CloudInit: mar...
< Previous question
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
Frage

FreeBSD en CloudInit: marchait en mars, ne marche plus en décembre?
Von
Guillaume Outters
Erstellungsdatum 2025-12-12 09:43:38 in Serveurs Dédiés Eco

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
Positive Bewertungen (0)
6694 Ansichten
Akzeptierte Lösung
Diese Antwort im Kontext anzeigen

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.
Hilfreich (0)
Antworten (1)
12 Antworten ( Latest reply on 2025-12-18 09:02:46 Von
Guillaume Outters
)

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?
Hilfreich (0)

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.
Hilfreich (2)

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.
Hilfreich (0)

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.
Hilfreich (1)

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.
Hilfreich (0)

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.
Hilfreich (1)

Ç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.
Hilfreich (0)

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.
Hilfreich (0)

An Diskussion teilnehmen