[PACKER] soucis avec cd_files

AtaxyaNetwork

@jeremie1977 Merci !

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

AtaxyaNetwork

@jeremie1977 j'ai un packer qui fonctionne avec RHEL 10 (c'est ce que j'avais sous la main), uefi, sans dhcp, et un cd file qui sert le ks

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

poddingue

Merci pour les précisions, elles écartent ma piste. Si vous reproduisez en BIOS comme en UEFI, le ticket #151 ne colle pas, d'autant qu'il parle de l'installeur Windows et pas d'Anaconda : je l'avais résumé un peu vite.
La différence intéressante est peut-être RHEL 9 contre RHEL 10, puisque @AtaxyaNetwork a un build qui fonctionne en 10 avec cd_files et sans DHCP, et son test en 9 ce week-end devrait trancher.
Sur cd_label = "OEMDRV", je n'ai trouvé ni issue ni PR dans le dépôt du plugin, donc ça n'existe visiblement pas encore : si ça vous va, ça ferait une demande propre à ouvrir sur https://github.com/vatesfr/packer-plugin-xenserver, en reprenant l'argument air-gapped que vous détaillez plus haut, qui est plus convaincant que ce que j'écrirais moi.

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.

AtaxyaNetwork

Du coup j'ai testé avec RHEL 9, ça fonctionne aussi.

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

jeremie1977

@poddingue Bonne idée !
Je pense ouvrir une PR pour "cd_files" en rapport avec les environnements air-gapped.
En tous cas merci de te pencher sur mon soucis

@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"

AtaxyaNetwork

@jeremie1977 Ah, oui effectivement je n'ai pas testé avec plusieurs disques !

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 !

poddingue

Merci d'avoir isolé le déclencheur, c'est la partie la plus utile du fil. Un disque ça passe, trois disques et l'installeur ne trouve plus le ks.cfg.
Si @AtaxyaNetwork reproduit de son côté, ça fait deux personnes sur le même symptôme, et là une issue sur https://github.com/vatesfr/packer-plugin-xenserver se justifie, avec le HCL minimal, le nombre de disques, la version du plugin et le message exact.
Je ne sais pas comment le plugin attache le CD quand il y a plusieurs disques, donc je peux très bien me tromper de piste, encore une fois.
Si tu ouvres la demande cd_label / OEMDRV, je pense qu'il faudrait reprendre ton argument air-gapped tel quel, il est plus convaincant que ce que j'écrirais.

AtaxyaNetwork

Je confirme que je reproduis le comportement.

Je vais voir si je trouve un fix

AtaxyaNetwork

Déja une piste intéressante, on dirait que pour une raison quelconque l'iso est mount deux fois

AtaxyaNetwork

Pour l'ISO montée deux fois : My bad, j'ai ajouter un truc en trop sur mon précédent fix. Une PR est en cours pour corriger ça.

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)