Pour concevoir et créer des images Oracle Solaris avec le constructeur de distribution, réalisez les quatre tâches suivantes.
La création d'une machine virtuelle nécessite des instructions particulières, qui diffèrent des instructions générales ci-dessous. Pour créer une machine virtuelle, reportez-vous au Chapitre 3x86 : conception et création d'une machine virtuelle.
Vérifiez la section Configuration système requise et installez l'application du constructeur de distribution sur votre système.
Facultatif : Personnalisation de l'image en modifiant les fichiers manifest.
Facultatif : Personnalisation avancée d'une image à l'aide des scripts de finalisation.
Pour obtenir des instructions complètes, reportez-vous aux sections suivantes.
Pour pouvoir utiliser le constructeur de distribution, configurez les fonctionnalités suivantes sur votre système.
Tableau 2–1 Configuration système requise
Le constructeur de distribution crée des images en fonction des paramètres indiqués dans des fichiers XML, appelés fichiers manifest. Les fichiers manifest contiennent les spécifications relatives au contenu et aux paramètres des images ISO créées à l'aide du constructeur de distribution. Le constructeur de distribution contient des fichiers manifest par défaut permettant de créer un Live CD, une image du programme d'installation en mode texte x86 ou SPARC, une image ISO d'installation automatisée x86 ou SPARC ou une image de machine virtuelle personnalisés.
Spécifiez des paramètres manifest, tels que :
Nom des packages à inclure dans l'image
Emplacement réseau du référentiel auquel accéder pour récupérer les packages pour l'image
Nom et emplacement des scripts utilisés pour terminer la création de la nouvelle image
Lorsque vous utilisez le constructeur de distribution pour créer des images ISO, notez les points suivants :
L'archive root pour les images x86 diffère de l'archive root pour les images SPARC. L'archive whole root, ou boot_archive, pour les images x86, est un système de fichiers UFS compressé à l'aide de gzip. La plate-forme SPARC ne prend pas en charge la compression de l'archive whole root de cette manière. Au lieu de cela, les archives SPARC utilisent DCFS, qui compresse chaque fichier individuellement. Ces fichiers compressés séparément peuvent nécessiter un traitement spécifique dans le fichier manifest. Pour plus d'instructions, reportez-vous au champ <boot_archive_contents> de la page de manuel dc_manifest(4).
Les fichiers manifest par défaut inclus dans le package distribution-constructor sont répertoriés dans le tableau ci-dessous.
Tableau 2–2 Fichiers manifest par défaut
Type de fichier manifest |
Emplacement du fichier manifest |
Description |
|
---|---|---|---|
Image ISO du Live CD x86 |
|
Ce fichier manifest est utilisé pour créer une image ISO comparable au Live CD d'Oracle Solaris, également appelé « Slim CD ». |
|
Image ISO du programme d'installation en mode texte x86 |
|
Ce fichier manifest est utilisé pour créer une image ISO que vous pouvez initialiser pour lancer une installation en mode texte du SE Oracle Solaris sur des ordinateurs x86. |
|
Image ISO du programme d'installation en mode texte SPARC |
|
Ce fichier manifest est utilisé pour créer une image ISO que vous pouvez initialiser pour lancer une installation en mode texte du SE Oracle Solaris sur des ordinateurs SPARC. |
|
Image ISO d'installation automatisée SPARC |
|
Ce fichier manifest est utilisé pour créer une image ISO d'installation automatisée SPARC pour l'installation automatisée du SE Oracle Solaris sur des clients SPARC. |
|
Image ISO d'installation automatisée x86 |
|
Ce fichier manifest est utilisé pour créer une image ISO d'installation automatisée x86 pour l'installation automatisée du SE Oracle Solaris sur des clients x86. |
|
Machine virtuelle x86 |
|
Ce fichier manifest est utilisé pour créer une image de machine virtuelle. Pour plus d'instructions, reportez-vous à la section Chapitre 3x86 : conception et création d'une machine virtuelle. |
Tous les champs des fichiers manifest fournissent des valeurs par défaut, prédéfinies, qui créent le type d'image ISO dont vous avez besoin, ainsi que, pour les systèmes x86, des images USB. Vous pouvez modifier manuellement ces champs prédéfinis dans un fichier manifest afin de personnaliser davantage l'image obtenue.
Si vous souhaitez modifier les informations d'un fichier manifest, effectuez la procédure suivante :
Copiez un des fichiers manifest par défaut et créez un fichier manifest personnalisé avec un nouveau nom de fichier.
Vous ferez référence au fichier manifest par son nom lorsque vous utiliserez la commande distro_const pour créer une image.
Sauvegardez toujours le fichier manifest d'origine et les scripts par défaut avant de les copier.
Modifiez les champs du fichier manifest selon vos besoins. Reportez-vous à la page de manuel dc_manifest(4) pour obtenir des instructions.
Si les scripts de finalisation par défaut ne laissent pas build_area comme vous le souhaitez, vous pouvez créer vos propres scripts pour procéder à des modifications supplémentaires. Si vous créez de nouveaux scripts, mettez à jour les références de script dans la section de finalisation du fichier manifest.
Pour les instructions sur la modification de la section relative au script de finalisation dans le fichier manifest, reportez-vous à la page de manuel dc_manifest(4).
Pour obtenir des instructions sur la création de nouveaux scripts, reportez-vous à la section Personnalisation avancée d'une image à l'aide des scripts de finalisation.
Une fois toutes les modifications apportées au fichier manifest, et, éventuellement, les scripts de finalisation personnalisés comme décrit à la section suivante, vous pouvez passer à l'exécution de l'utilitaire distro_const pour créer une image. Pour plus d'instructions, reportez-vous à la section Création d'une image.
Le constructeur de distribution vous permet de spécifier les scripts qui peuvent être utilisés afin de personnaliser l'installation selon le type d'images créées. Ces scripts sont appelés scripts de finalisation. Les fichiers manifest désignent les scripts de finalisation, et ceux-ci transforment l'image générique en une distribution spécifique au support. Un ensemble de scripts par défaut est fourni dans les packages d'application.
L'application du constructeur de distribution inclut les scripts par défaut dans le répertoire /usr/share/distro_const et ses sous-répertoires. Ces scripts sont référencés dans la section de finalisation des fichiers manifest.
Par exemple, le tableau suivant répertorie certains scripts de finalisation par défaut utilisés pour créer un Live CD ou « Slim CD » x86.
Tableau 2–3 Scripts de finalisation Live CD x86
Script de finalisation |
Description |
---|---|
pre_boot_archive_pkg_image_mod |
Modifie la zone d'image pour tous les types d'images |
slim_cd/slimcd_pre_boot_archive_pkg_image_mod |
Modifie la zone d'image, en particulier pour les images Live CD |
slim_cd/slimcd_gen_cd_content |
Génère une liste de fichiers qui font partie de l'image Live CD |
boot_archive_initialize.py |
Initialise l'archive d'initialisation |
slim_cd/slimcd_boot_archive_configure |
Configure l'archive d'initialisation, en particulier pour l'image Live CD |
boot_archive_configure |
Configure l'archive d'initialisation |
boot_archive_archive.py |
Archive l'archive d'initialisation |
slim_cd/slimcd_post_boot_archive_pkg_image_mod |
Applique des modifications postérieures à la construction à la zone d'image de l'archive d'initialisation, en particulier pour l'image Live CD |
grub_setup |
Initialise le menu Grub |
post_boot_archive_pkg_image_mod |
Applique des modifications postérieures à la construction à la zone d'image de l'archive d'initialisation |
create_iso |
Crée une image ISO |
create_usb |
Crée une image USB |
Il est recommandé d'utiliser les scripts de finalisation fournis sans les modifier. Vous pouvez toutefois écrire et ajouter vos propres scripts afin d'effectuer d'autres opérations, comme décrit ci-dessous. Si vous créez de nouveaux scripts, modifiez les fichiers manifest pour qu'ils les désignent.
La prise en charge des scripts est limitée aux scripts par défaut, non modifiés, fournis avec les packages d'application. Si vous décidez de personnaliser ces scripts, sauvegardez les scripts d'origine au préalable.
Concevez vos nouveaux scripts. Utilisez les scripts existants comme modèles pour les nouveaux scripts. Reportez-vous à la section Caractéristiques des scripts de finalisation.
Consultez également les exemples de scripts personnalisés suivants :
Créez vos nouveaux scripts.
Ajoutez les nouveaux scripts au répertoire /usr/local/, à votre répertoire personnel ou ailleurs sur le système ou réseau. Assurez-vous que le rôle root puisse exécuter ces scripts.
Ajoutez le nom des nouveaux scripts dans la section de finalisation du fichier manifest approprié. Veillez à spécifier le chemin d'accès complet à vos scripts dans le fichier manifest, même s'ils se trouvent dans le répertoire /usr/share/distro_const.
Lorsque vous ajoutez une référence pour un nouveau script dans la section de finalisation d'un fichier manifest, vous devez spécifier un nom de point de contrôle utilisé pour interrompre la création de l'image avant que ce script ait effectué sa tâche ou après. Vous pouvez également inclure un message personnalisé associé au nom du point de contrôle. Si vous n'ajoutez pas un tel message, le chemin du script est utilisé comme message de point de contrôle par défaut.
Attribuez aux points de contrôle des noms explicites plutôt que des nombres. Si de nouveaux scripts sont ajoutés, les nouvelles étapes correspondant à ces nouveaux scripts perturberont l'ordre des points de contrôle numérotés.
Par exemple, la référence suivante dans un fichier manifest spécifie le nom de point de contrôle "ba-arch" pour un script d'archivage de l'archive d'initialisation et le message associé est "archivage de l'archive d'initialisation".
<script name="/usr/share/distro_const/boot_archive_archive.py"> <checkpoint name="ba-arch" message="Boot archive archiving"/> </script> |
Cet exemple vous permet de spécifier une commande distro_const pour créer votre image, ou interrompre ou reprendre la création à partir du point de contrôle "ba-arch". La création d'image s'interrompt juste avant que le script d'archivage de l'archive d'initialisation effectue sa tâche.
Pour en savoir plus sur le référencement des points de contrôle dans la commande distro_const, reportez-vous à la section Création d'une image par étapes.
Lorsque vous créez vos propres scripts de finalisation, prenez en compte les points suivants :
Les scripts peuvent être des programmes Python, des scripts shell ou des fichiers binaires.
Les scripts sont exécutés dans leur ordre d'apparition dans le fichier manifest.
La sortie standard (stdout) et la sortie d'erreur (stderr) des commandes exécutées dans les scripts de finalisation (modules shell et python) sont enregistrées dans les fichiers journaux. La sortie stderr est enregistrée dans le journal simple. Les sorties stdout et stderr sont capturées dans le journal détaillé.
Le constructeur de distribution transmet cinq arguments initiaux à tous les scripts exécutés. Ces cinq arguments ne sont pas inclus en tant qu'entrées dans le fichier manifest. Le fichier manifest spécifie d'autres arguments transmis après ces cinq arguments. Les arguments initiaux sont les suivants.
Argument |
Description |
|
---|---|---|
Nom de fichier du socket de serveur |
Le premier argument est le socket du lecteur de fichiers manifest. Cet argument spécifie le socket utilisé avec /usr/bin/ManifestRead pour accéder aux données du fichier manifest. Reportez-vous à la section Utilisation du lecteur de fichiers manifest. |
|
Chemin d'accès à la zone d'image du package |
Le deuxième argument est PKG_IMG_PATH, qui spécifie le chemin d'accès à la zone où l'image du package est créée. Utilisez cet argument pour localiser un fichier dans la zone d'image du package. L'exemple suivant vérifie si l'utilisateur, "jack", se trouve dans le fichier de mots de passe de la zone d'image du package.
|
|
Répertoire temporaire |
Le troisième argument spécifie un répertoire qui est utilisé lors de la création de fichiers temporaires nécessaires au processus de création. Dans l'exemple suivant, vous créez un fichier dans le répertoire temporaire pour générer l'archive d'initialisation.
|
|
Zone de construction de l'archive d'initialisation |
Le quatrième argument est la zone de création de l'archive d'initialisation, où les fichiers d'archive d'initialisation sont rassemblés. Reportez-vous à l'exemple suivant dans le module boot_archive_configure, qui ajoute ce fichier, /etc/nodename, à l'archive d'initialisation. Ce fichier donne au système le nom d'hôte, « solaris ».
|
|
Zone de média |
Le cinquième argument indique l'emplacement où le média terminé est consigné. Dans l'exemple suivant, le script create_iso utilise cet argument pour placer l'image ISO obtenue.
|
|
Arguments supplémentaires |
Une liste des arguments supplémentaires qui sont transmis à un script apparaît dans le fichier manifest avec la balise <argslist>. Le premier de ces arguments est transmis comme arg6. Entourez chaque élément de la liste de guillemets doubles. Si aucun guillemet n'est utilisé, ou si un ensemble de guillemets encadre l'intégralité de la chaîne, celle-ci, espaces et retours inclus, est interprétée comme un argument. N'utilisez pas de virgules pour séparer les arguments. Dans l'exemple suivant du fichier manifest slim_cd_x86.xml, deux arguments supplémentaires sont transmis au script boot_archive_configure, comme arg6 et arg7 :
Une autre moyen d'indiquer d'autres arguments consiste à utiliser des paires clé-valeur. Reportez-vous à la section suivante. |
Le constructeur de distribution transmet le socket du lecteur de fichiers manifest comme premier argument dans les scripts de finalisation. Dans un script shell de finalisation, transmettez cet argument en tant que premier argument à /usr/bin/ManifestRead pour accéder aux données du fichier manifest. Dans un module python, transmettez cet argument pour créer une instance d'un objet ManifestRead().
Les exemples de scripts shell suivants appellent ManifestRead afin de demander l'élément name à partir du fichier manifest. ManifestRead renvoie zéro ou plusieurs éléments, chacun sur sa propre ligne. Si ManifestRead doit rechercher plusieurs éléments, les lignes renvoyées contiennent l'élément recherché et un résultat.
MFEST_SOCKET=$1 VOLNAME=`/usr/bin/ManifestRead ${MFEST_SOCKET} "name"` if [ "XX${VOLNAME}" == "XX" ] ; then print -u2 "$0: Error retrieving volume ID" exit 1 fi |
L'exemple suivant montre comment utiliser ManifestRead à partir d'un script Python :
from osol_install.ManifestRead import ManifestRead # get the manifest reader object from the socket manifest_reader_obj = ManifestRead(MFEST_SOCKET) # get boot_archive compression type BR_COMPR_TYPE = get_manifest_value(manifest_reader_obj, "img_params/output_image/boot_archive/compression/type") if (BR_COMPR_TYPE == None): raise Exception, (sys.argv[0] + ": boot_archive compression type missing from manifest") |
Une autre méthode pour transmettre des arguments aux scripts consiste à spécifier une paire clé-valeur. Elle est utile pour transmettre le même argument à plusieurs scripts sans duplication. Un script peut accéder à une valeur codée en spécifiant la clé de /usr/bin/ManifestRead à partir du script. Indiquez le socket de serveur comme premier argument, puis précisez les chemins d'accès du nœud aux éléments dont les valeurs sont nécessaires, comme dans les exemples suivants.
L'exemple suivant appelle ManifestRead à partir d'un script shell pour obtenir une valeur codée.
... MFEST_SOCKET=$1 ... /usr/bin/ManifestRead -k $MFEST_SOCKET iso_sort iso_sort_file=`/usr/bin/ManifestRead $MFEST_SOCKET iso_sort` |
L'exemple suivant appelle ManifestRead à partir d'un script Python pour obtenir la même valeur codée.
from osol_install.ManifestRead import ManifestRead ... IS_KEY = True iso_sort_file = manifest_reader_obj.get_values("iso_sort", IS_KEY) fd = open(iso_sort_file,....) |
Après avoir configuré le fichier manifest que vous avez choisi d'utiliser et, éventuellement, personnalisé les scripts de finalisation, vous êtes prêt à créer une image en exécutant la commande distro_const.
Pour exécuter la commande distro_const, assumez le rôle root en exécutant la commande su -.
Vous pouvez utiliser la commande distro_const pour effectuer l'une des opérations suivantes :
Créer une image en une seule étape.
Créer une image, mais interrompre et redémarrer le processus de création selon les besoins pour examiner le contenu de l'image et déboguer les scripts de finalisation en cours d'exécution.
La syntaxe complète de cette commande est la suivante :
Syntax: distro_const build [-R] [-r step] [-p step] [-l] manifest |
Pour exécuter la création complète d'une image sans interruption, utilisez la commande distro_const de base sans option, comme suit :
# distro_const build manifest |
Remplacez manifest par le nom du fichier manifest à utiliser comme empreinte pour votre image. La sous-commande build est requise. Lorsque vous tapez cette commande, le constructeur de distribution extrait les packages requis pour l'image et crée l'image selon les spécifications définies dans le fichier manifest.
Vous pouvez utiliser les options offertes par la commande distro_const pour arrêter et redémarrer le processus de création à différentes étapes du processus de génération d'image, afin de contrôler et de déboguer votre sélection de fichiers, packages et scripts pour l'image en cours de création. Ce processus d'arrêt et de redémarrage au cours de la création est appelé création de points de contrôle.
La création de points de contrôle prend en charge le processus de développement et de débogage des images. Vous pouvez commencer à créer une image, interrompre le processus à tout moment pour examiner le contenu de l'image, puis reprendre la création de l'image. La création de points de contrôle est facultative.
La fonction de création de points de contrôle est activée par défaut dans le fichier manifest. Toutefois, un jeu de données ZFS ou un point de montage lié à un jeu de données ZFS, doit être spécifié comme zone de construction.
Vous pouvez également désactiver la création de points de contrôle dans le fichier manifest en définissant le paramètre checkpoint_enable sur false.
Utilisez les options de création de points de contrôle disponibles dans la commande distro_const comme décrit dans les instructions de base ci-dessous. Consultez également la page de manuel distro_const(1M).
Avant de créer l'image, vérifiez les étapes valides au cours desquelles vous pouvez choisir d'interrompre ou reprendre la création à l'aide de la commande suivante :
# distro_const build -l manifest |
La sous-commande build est requise.
Un point de contrôle dans le processus de création est créé après chaque exécution du script de finalisation.
Cette commande affiche les points de contrôle valides auxquels vous pouvez interrompre ou reprendre la création d'une image. Utilisez les noms d'étapes fournis par cette commande comme valeurs correctes pour les autres options de commande de création de points de contrôle.
Par exemple, la commande suivante confirme les points de contrôle disponibles, pour un fichier manifest nommé slim_cd_x86.xml.
# distro_const build -l slim_cd_x86.xml |
Une fois la commande exécutée, les étapes de création de points de contrôle valides s'affichent. Les étapes de création de points de contrôle sont décrites ci-après.
Step Resumable Description -------------- --------- ------------- im-pop X Populate the image with packages im-mod X Image area modifications slim-im-mod Slim CD image area modifications ba-init Boot archive initialization slim-ba-config Slim CD boot archive configuration ba-config Boot archive configuration ba-arch Boot archive archiving (64-bit) ba-arch-32 Boot archive archiving (32-bit) slim-post-mod Slim CD post boot archive image area modifications grub-setup Grub menu setup post-mod Post boot archive image area modification gen-slim-cont Generate Slim CD image content list iso ISO image creation usb USB image creation |
Dans le résultat de la commande, une coche dans le champ de reprise indique que vous pouvez reprendre la création à partir de cette étape.
Utilisez la commande suivante pour créer une image et pour interrompre la création de l'image à l'étape spécifiée.
# distro_const build -p step manifest |
La sous-commande build est requise. Les champs step et manifest sont obligatoires.
Par exemple, la commande suivante lance la création d'une image et interrompt la construction avant que l'étape im-mod ne modifie la zone d'image :
# distro_const build -p im-mod slim_cd_x86.xml |
Reprenez la création à partir de la dernière étape exécutée ou d'une étape de votre choix, en utilisant l'une des options suivantes :
Utilisez la commande suivante pour reprendre la création de l'image à partir d'une étape spécifiée.
# distro_const build -r step manifest |
L'étape spécifiée doit être l'étape à laquelle la création antérieure a été interrompue ou une étape précédente. Une étape ultérieure n'est pas valide. Les champs step et manifest sont obligatoires. La sous-commande build est requise.
Par exemple, la commande suivante reprend la création de l'image là où im-mod modifie la zone d'image :
# distro_const build -r im-mod slim_cd_x86.xml |
Utilisez la commande suivante pour reprendre la création de l'image à partir de la dernière étape exécutée.
L'argument manifest et la sous-commande build sont requis.
# distro_const build -R manifest |
Par exemple, la commande suivante reprend la création de l'image là où le processus avait été interrompu.
# distro_const build -R slim_cd_x86.xml |
Vérifiez les éléments de dépannage suivants.
Assurez-vous que la commande pkg(1) sur votre système fonctionne correctement et que votre connexion avec le serveur IPS est stable. Parfois le délai de connexion du serveur IPS arrive à expiration lors du téléchargement d'un grand cluster de packages. Pour effectuer une vérification en dehors de l'environnement du constructeur de distribution, essayez d'imiter ce que le constructeur effectue en termes d'installation des packages. Assumez le rôle root en exécutant la commande su -. Essayez ensuite les commandes suivantes, en confirmant leur fonctionnement.
pkg image-create -F -a opensolaris.org=http://pkg.opensolaris.org pkg -R /tmp/test_img install SUNWcsd pkg -R /tmp/test_ima install SUNWcs pkg -R /tmp/test_img install slim_install |
Si un fichier manifest n'est pas validé, comme cela peut être le cas après sa modification, exécutez l'utilitaire ManifestServ dans un mode détaillé pour trouver l'erreur.
L'utilitaire ManifestServ, /usr/bin/ManifestServ, sans aucun argument affiche l'usage suivant :
ManifestServ Usage: /bin/ManifestServ [-d] [-h|-?] [-s] [-t] [-v] [-f <validation_file_base> ] [-o <out_manifest.xml file> ] <manifest.xml file> where: -d: turn on socket debug output (valid when -s also specified) -f <validation_file_base>: give basename for schema and defval files Defaults to basename of manifest (name less .xml suffix) when not provided -h or -?: print this message -o <out_manifest.xml file>: write resulting XML after defaults and validation processing -t: save temporary file Temp file is "/tmp/<manifest_basename>_temp_<pid> -v: verbose defaults/validation output -s: start socket server for use by ManifestRead |
Le constructeur de distribution valide le fichier manifest par rapport à un schéma XML et un fichier manifest par défaut. ManifestServ vous permet d'effectuer une validation manuelle, en utilisant un mode détaillé qui affiche l'emplacement des problèmes.
L'exemple suivant présente un cas dans lequel le fichier manifest n'est pas validé par rapport au schéma. Le message en gras ci-après indique une erreur de validation du schéma.
# distro_const build my_distro.xml /usr/share/distro_const/DC-manifest.defval.xml validates /tmp/all_lang_slim_cd_x86_temp_7861.xml:350: element pair: Relax-NG validity error : Element pair failed to validate attributes /tmp/my_distro_temp_7861.xml fails to validate validate_vs_schema: Validator terminated with status 3 validate_vs_schema: Validator terminated abnormally Error validating manifest against schema /usr/share/distro_const/DC-manifest.rng # |
Exécutez ManifestServ, /usr/bin/ManifestServ en spécifiant l'option -t afin d'enregistrer le fichier temporaire, et l'option -v pour obtenir une sortie détaillée contenant le numéro de ligne de l'erreur.
# ManifestServ -f /usr/share/distro_const/DC-manifest -t -v manifest_file |
ManifestServ -f /usr/share/distro_const/DC-manifest -t -v my_distro.xml /usr/share/distro_const/DC-manifest.defval.xml validates Checking defaults for name Checking defaults for distro_constr_params/distro_constr_flags/stop_on_error Checking defaults for distro_constr_params/pkg_repo_default_authority/main/url ... ... (omitted content) ... ... /tmp/my_distro_temp_7870.xml:350: element pair: Relax-NG validity error : Element pair failed to validate attributes /tmp/all_lang_slim_cd_x86_temp_7870.xml fails to validate validate_vs_schema: Validator terminated with status 3 validate_vs_schema: Validator terminated abnormally Error validating manifest against schema /usr/share/distro_const/DC-manifest.rng Error running Manifest Server schema_validate: Schema validation failed for DC manifest /tmp/my_distro_temp_7870.xml |
Le fichier temporaire sera nommé vers la fin de la sortie. Dans l'exemple ci-dessus, le fichier est /tmp/my_distro_temp_7870.xml. Selon les messages d'erreur en gras, ouvrez ce fichier et recherchez le problème à la ligne 350. Dans cet exemple, la ligne 350 ressemble à ceci :
<key_value_pairs> <pair value='/usr/share/distro_const/slim_cd/slimcd_iso.sort' key='iso_sort'/> <pair VaLuE='myvalue' key='mykey'/> </key_value_pairs> |
L'attribut VaLuE est incorrect. Dans cet exemple artificiel, value devrait être en minuscules, comme dans la ligne juste au-dessus. Les messages de la deuxième à la dernière ligne indiquent que la validation du schéma a échoué. Le schéma utilisé pour la validation du constructeur de distribution est /usr/share/distro_const/DC-manifest.xml. Le schéma indique que les seuls attributs pour <pair> sont <value> et <key>, pas <VaLuE>.
Une validation sémantique est également réalisée. La validation sémantique contrôle le contenu à la recherche d'erreurs de "signification" et de contexte, et ne contrôle pas uniquement la syntaxe. Par exemple, les scripts de finalisation répertoriés dans un fichier manifest peuvent être validés pour confirmer qu'ils sont des fichiers exécutables.
L'exemple suivant illustre un cas où le fichier manifest ne passe pas la validation sémantique.
# distro_const build -l my_distro_sem.xml /usr/share/distro_const/DC-manifest.defval.xml validates /usr/share/distro_const/grub_setup.py either doesn't exist or is not an executable file validate_node: Content "/usr/share/distro_const/grub_setup.py" at img_params/output_image/finalizer/script/name did not validate Error validating manifest tree content |
La validation sémantique utilise des fonctions afin de mener à bien la validation. Ces fonctions impriment des messages d'erreur expliquant pourquoi le fichier manifest a échoué à la validation. Dans ce cas, le fichier /usr/share/distro_const/grub_setup.py est absent et le message d'erreur indique directement ce problème. Dans ce cas, grub_setup.py doit être restauré, ou, le cas échéant, la référence à ce fichier doit être supprimée du fichier manifest.
Vous pouvez toujours exécuter ManifestServ avec l'option -v pour obtenir plus de détails sur la validation sémantique. Toutefois, si elle est spécifiée, l'option de commande -v indiquera simplement l'échec parmi de nombreuses réussites, ce qui peut donner une sortie plus difficile à lire.
Une fois la validation et d'autres traitements préalables terminés, ManifestServ demande les données à vider et vérifier. Cette étape est plus utile pour tester le processus utilisant les données que les données elles-mêmes, dans la mesure où les données sont parfaitement visibles dans le fichier manifest même.
Reportez-vous aux ressources supplémentaires suivantes.
Tableau 2–5 Documentation relative à l'installation
Document |
Thème |
---|---|
Informations supplémentaires relatives au dépannage |
|
Installation à partir du Live CD ou du programme d'installation en mode texte |
|
Guide du programme d'installation automatisée d'Oracle Solaris 11 Express |
Réalisation d'installations automatisées sur plusieurs systèmes |
Gestion des environnements d'initialisation avec Oracle Solaris 11 Express |
Création et gestion de plusieurs environnements d'initialisation sur votre système |