Pour le problème principal : J'ai identifié la cause, mais je n'ai pas encore de solution.

Sans les drivers Xen (non initialisés avant l'installation), une VM est limitée à 4 périphériques. La séquence de boot ne peut donc pas détecter le second disque contenant le fichier Kickstart (ks).

Côté Packer, on semble être bloqués par cette contrainte XCP-ng. Les seules alternatives actuelles seraient de se limiter à :

• 2 disques + 2 CD
• ou 3 disques + 1 CD + HTTP

(Note : L'installation manuelle fonctionne car l'installateur démarre directement, avec le driver xen_blkfront, alors qu'avec Packer, l'injection de notre fichier interrompt le flux de démarrage classique).

Je vais fouiller encore un peu, mais sans certitude d'un contournement possible.

(et je regarde pour ajouter le CDlabel)

Je vais voir si je trouve un fix

Et j'ai du typo dans la doc, je vais faire une PR pour modifier

Je pense que c'est du a la façon d'insérer les disques et les DVD coté XCP-ng. Je vais investiguer !

@ataxyanetwork Je pense avoir mis le doigt sur le soucis...
J'ai repris ton code de la version air-gapped à l'identique (en modifiant un peu pour que cela colle à mon infra, comme l'agent positionné dans "http" pour l'installer car je ne peux pas sortir sur le net, etc).
En ne mettant qu'un seul disque : aucuns soucis le build réussi ^^ (que ce soit de la RHEL 9 ou 10)

Par contre en mettant plusieurs disques (nos builds comportent 3 disques) ça ne passe plus...
Il ne trouve pas le ks.cfg...
il m'indique "please insert CDROM containing '/ks.cfg' "

D'ailleurs la doc du plugins est erronée pour le multi-disk, il est dit de mettre :

  disk {
    disk_name = "root"
    disk_size = 20480    
  }
  disk {
    disk_name = "multidisk-is-working"
    disk_size = 10240    
  }

au build cela met en erreur avec :
Blocks of type "disk" are not expected here. Did you mean "disks"?
Il faut mettre "disks"

Faut bien prendre l'iso "dvd", pas "boot" en revanche ! (je me suis fait avoir en téléchargeant l'image)

Je ne connais pas assez le plugin pour dire si c'est simple à ajouter, donc je préfère ne rien promettre.
Merci en tout cas de documenter tout précisément, ça servira sans doute bien au-delà de votre POC.

Le code est ici: https://github.com/disruptivemindseu/xcpng-template-builder/tree/rhel-airgapped/packer/distros/rhel/10/uefi-airgapped

Je vais essayer avec une RHEL 9 ce week-end, il y a peut-etre une subtilité entre les deux versions

Je teste ça de mon coté et je fais un feedback vite !

On utilise Packer par "habitude et facilité" ^^ car on a une infra assez diversifié tant en terme de sites que d'hyperviseurs/Clouds...et Packer y répond bien.
Mais je note OSBuild, ça semble intéressant

@ataxyanetwork : C'est très cool ce partage en tous cas.
Voilà l'environnement:

• RHEL 9.8
• bios
• Boot sans DHCP
• fichier kickstart passé via le cd_files et renseigné via boot_command

D'ailleurs sur le plugin Nutanix il existe un paramètre : `

cd_label          = "OEMDRV"

qui permet de se passer complétement de boot_command.
Le paramètre cd_label = "OEMDRV" permet à Anaconda de détecter automatiquement un disque ou une partition étiquetée OEMDRV et d'y chercher un fichier ks.cfg
Ce serait top de retrouver ce paramètre pour le plugin xcp-ng

@olivierlambert said:

@john.c I really liked your "Jean C." signature before your edit You should keep it

I learned a bit of French in 6th form college many years ago now, as part of learning your culture. As part of a Skillpower course unit assignment. As part of this course during Sept 2001 to Summer 2006 went on an academic day trip visit to Boulogne, France.

But it was to a level that was useful for when going on holidays, so wasn’t very fluent.

Pas de soucis pour les tutos, c'est normal de partager !

Je vais essayer de reproduire votre soucis. Pour etre sur votre environnement:

• RHEL (10?)
• UEFI ?
• Boot sans DHCP
• Et un fichier Kickstart a passer sans la méthode HTTP ?

@jeremie1977 said:

Bonjour,
Nous sommes en plein POC de Vates et je test le build de nos images RHEL avec Packer (d'ailleurs un grand merci à @bvivi57 et @ataxyanetwork pour les tutos et exemples qui m'ont fait gagner un temps précieux ^^ ).

J'ai remarqué que le paramètre "cd_files" ne permettait pas de monter le kickstart au boot
Le provider expose cd_files, mais le contenu n'est pas visible par l'installeur (ou n'est pas attaché à la VM...je n'ai pas sût identifier).
J'ai même tenté avec "floppy_files"...idem.
Est-ce normal ? Voulu ?

Du coup, dans des environnements sans DHCP pendant l'installation, cela empêche l'utilisation d'un kickstart embarqué et oblige à mettre en place une IP via la "boot_command" avec une configuration réseau statique (ce qui oblige a multiplié les builds si plusieurs environnements/site)
Rien de dramatique en soit mais sur les provider Packer Vmware et Nutanix que nous utilisons par ex, cd_files nous permet de couvrir les environnements isolés (air-gapped) et/ou sans DHCP et simplifie grandement les builds automatisés en rendant le code le plus idempotent possible.

L'intérêt est multiple :
Environnements air-gapped : aucun serveur HTTP nécessaire.
Moins de dépendances : le build est autonome.
Compatibilité avec les autres builders Packer (VMware, Nutanix, QEMU...), où nous utilisons cette fonctionnalité pour nos Builds
Sécurité : le kickstart n'est pas exposé sur le réseau, même temporairement.

Si la raison pour laquelle le fichier Kickstart ne peut pas être connecté en réseau ou autrement accessible, c'est parce qu'il contient des secrets. Cela peut valoir la peine de regarder et de vérifier le logiciel de service de détenteur sécurisé secret OpenBao (https://openbao.org/). Qui est un fork public open source de Hashicorp Vault, avant l'entrée en vigueur de la licence BUSL dans les versions ultérieures de Vault. Un autre conseil utile est de combiner l'isolation du masque de sous-réseau avec l'isolation basée sur le VLAN.

Quoi qu'il en soit, saviez-vous qu'une instance de Cockpit, exécutant Cockpit Image Builder peut être utilisée comme Packer, pour créer des images "dorées" de VM via OSBuild ?

Quoi qu'il en soit, bonjour et bienvenue dans la communauté Vates VMS, j'espère que vous la trouverez utile, épanouissante, accueillante et/ou amusante.

Sincèrement,

Jean C.

A priori ce n'est ni normal ni voulu : le support de cd_files a été ajouté par la PR #144 (https://github.com/vatesfr/packer-plugin-xenserver/pull/144), mergée fin juin 2025, donc présent depuis la v0.8.1 du plugin, et la dernière version publiée est la v0.11.4. Ce qui me met plutôt sur une autre piste, d'autant que floppy_files échoue aussi chez vous : le ticket #151 (https://github.com/vatesfr/packer-plugin-xenserver/issues/151) décrit exactement ce symptôme, une image floppy que l'installeur ne voit pas en UEFI alors qu'elle passe sans souci en BIOS legacy.

Vos builds RHEL démarrent-ils en UEFI, et avec quelle version du plugin ? Je ne connais pas assez le plugin pour en être certain, donc corrigez-moi si je me trompe.