[OpenBSD]

[Index de La FAQ] [Section 4 - Guide d'Installation] [Section 6 - Mise en place du réseau]

5 - Construire le Système à partir des Sources

Table des matières


5.1 - Les Saveurs ("Flavors") OpenBSD

Il existe trois "saveurs" OpenBSD : Schématiquement, le développement de ces versions ressemble à ceci :
,------o-----------o----X 3.8 Stable | . . | . ,------o---------o----X 3.9 Stable | . | . . | . | . ,----o----------o--> 4.0 Stable | . | . | . . | . | . | . ,-----o--> 4.1 Stable | . | . | . | . | . | . | . | . -->3.8Rel----->3.9Rel----->4.0Rel----->4.1Rel----> Current Time --->

-Current: La version courante pour laquelle le développement est réalisé, et qui deviendra la prochaine -release d'OpenBSD. Tous les six mois, lorsqu'une version d'OpenBSD est révisée, -current est tagguée, et devient -release : un point gelé dans l'histoire de l'arbre des sources. Chaque -release demeure inchangée; c'est pour cela qu'on la trouve sur les CDs et serveurs FTP.

-Stable est basée sur -release, et est une branche du chemin de développement principal d'OpenBSD. Quand des corrections très importantes sont faites sur -current, elles sont "backportées" (intégrées) aux branches -stable; à cause de celà, -stable est aussi connue sous le nom de branche patch. Dans l'illustration ci-dessus, la ligne verticale en pointillés symbolise les corrections de bogues incorporées aux branches -stable. Vous remarquerez aussi dans l'exemple ci-dessus que la branche 3.8-stable a été supprimée à la sortie de 4.0-release, et que la branche 3.9-stable a été supprimée à la sortie de 4.1-release -- les anciennes versions sont typiquement supportées durant deux "releases" au maximum. Le support d'anciennes versions nécessite des ressources et du temps, et alors que nous pourrions vouloir plutôt fournir un support continu pour les anciennes versions, nous préférerons nous concentrer sur les nouvelles fonctionnalités. La branche -stable est, par conception, très facile à construire à partir de -release de la même version (c'est à dire en allant de 4.1-release vers 4.1-stable).

La branche -stable est -release à laquelle on a ajouté les correctifs listés dans la page des errata, ainsi que quelques correctifs ne nécessitant pas d'erratum. Habituellement, le fonctionnement de -stable est le même que celui de -release sur laquelle elle est basée. Si les pages de manuel doivent être modifiées, il est très probable que ces modifications ne fassent pas partie de -stable. En d'autres termes, le support de nouveaux périphériques NE sera pas ajouté à - stable, et le support de nouvelles fonctionnalités sera très rarement ajouté sauf si cela est considéré comme très important.

Il est utile de préciser que le nom "-stable" ne signifie pas pour autant que -current est instable. -current change et évolue, alors que -stable ne change que très peu (tant aux niveau des APIs qu'au niveau opérationnel), et vous n'aurez pas à apprendre à nouveau votre système, à changer des fichiers de configuration ou à ajouter de nouvelles applications à votre système. En fait, notre préoccupation étant de faire continuellement évoluer OpenBSD, vous devriez trouver -current plus performante que -stable.

Attention : -current change tout le temps. Elle change pratiquement toutes les minutes. Bien que les développeurs travaillent sans cesse afin que le système se compile toujours et qu'il n'y ait pas de bogues majeurs, il est tout à fait possible de récupérer les sources de -current et que celles-ci ne soient pas compilables, alors que tout fonctionne correctement cinq minutes plus tard. Il y a aussi des "jours drapeau" et des changements majeurs du système que les développeurs gèrent avec des outils en un, mais qui empêchent une quelconque mise à jour basée sur les sources. Si vous n'êtes pas préparé à les traiter, rester à l'écart de -current.

La plupart des utilisateurs devraient utiliser -stable ou -release. Cela dit, plusieurs personnes utilisent -current sur des systèmes en production, et il est important que certaines personnes fassent cela pour identifier des bogues et tester les nouvelles fonctionnalités. Cependant, si vous ne savez pas comment décrire, diagnostiquer et gérer proprement un problème, ne vous dites pas (ou à quelqu'un d'autre) que vous être entrain d'"aider le projet" en utilisant -current. "Ça ne marche pas !" n'est pas un rapport de bogue utile. "Les changements récents dans le pilote pciide ont brisé la compatibilité avec mon interface IDE basée sur Slugchip, ci-joint le dmesg d'un système fonctionnel et un système ne fonctionnant pas..." peut être un rapport utile.

Des fois, les utilisateurs "normaux" veulent disposer des derniers développements et utiliser -current. La raison la plus commune de faire cela est que l'utilisateur possède un périphérique qui n'est pas supporté par -release (et donc, par -stable non plus), ou qu'il souhaite utiliser une nouvelle fonctionnalité de -current. Dans ce cas, soit l'utilisateur utilise -current soit il n'utilise pas le périphérique, et utiliser -current est peut-être l'option la plus logique. Cependant, il ne faut pas espérer que les développeurs vous tiennent la main.

Snapshots

Entre les versions formelles d'OpenBSD, des snapshots sont mis à disposition sur les sites FTP . Comme le nom l'indique, ce sont des images du code dans l'arborescence à l'instant où le créateur de l'image a pris une copie du code pour une plate-forme donnée. Il est à noter que, pour certaines plates-formes, il peut s'écouler des jours entiers avant que l'image ne soit complètement construite et mise à disposition. Aucune garantie n'est donnée quant au bon fonctionnement ou à la possibilité d'installer des snapshots. Souvent, une modification qui a besoin d'être testée peut enclencher le processus de création des snapshots. Quelques plates-formes ont des snapshots construits pratiquement tous les jours, d'autres en ont beaucoup moins fréquemment. Si vous souhaitez utiliser -current, un snapshot récent est tout ce dont vous aurez besoin, et mettre à jour un snapshot est un point de départ nécessaire avant de tenter de compiler -current depuis les sources.

Parfois, on demande s'il y a un moyen d'obtenir une copie exacte du code qui a servi à construire un snapshot. La réponse est non. Primo, il n'y a aucun intérêt. Secundo, les snapshots sont construits selon le souhait des développeurs, lorsque le planning le permet, et lorsque des ressources sont disponibles. Sur les plates-formes rapides, il est possible de créer plusieurs snapshots en un jour. Sur les plates-formes lentes, la création d'un snapshot peut durer une semaine ou plus. Fournir des balises ou des marques dans l'arborescence des sources pour chaque snapshot peut s'avérer peu pratique.

Mise à jour majeure vs. mise à jour mineure

Il existe deux types de mises à jour sous OpenBSD : des mises à jour majeures et des mises à jour mineures. Il existe des différences notables entre ces deux types de mises à jour que nous allons tâcher d'expliquer ci-après.

Une mise à jour majeure consiste à installer une nouvelle version d'OpenBSD, qui inclut généralement de nouvelles fonctionnalités. Par exemple, le passage d'une version 4.0 à une version 4.1 ou la mise à jour d'un snapshot du 12 juin avec un snapshot du 24 juin sont considérés comme mises à jour majeures. Lors d'une mise à jour majeure, vous devez typiquement consulter Suivre la version de développement "-current" ou le Guide de Mise à niveau d'OpenBSD (lors du passage d'une version à une plus récente) pour effectuer les modifications nécessaires au bon fonctionnement de la nouvelle version d'OpenBSD.
Une mise à jour mineure consiste à appliquer des correctifs à un système afin d'améliorer son fonctionnement SANS modification des fonctionnalités de base ou de la compatibilité binaire. Ceci est généralement effectué en suivant le processus d'Application des correctifs sous OpenBSD ou en suivant la procédure décrite dans le document intitulé Maintenir son système à niveau par rapport à -stable. Quand vous effectuez une mise à jour mineure, votre système passe d'un état -release à un état -stable (ou -release corrigé) de la même version. Par exemple, de 4.1-release à 4.1-stable. Vous pouvez ensuite effectuer une nouvelle mise à jour mineure vers un -stable plus récent de la même version. Le processus de mise à jour est généralement sans conséquence étant donné que les fichiers /etc ou d'autres configurations système n'ont pas besoin d'être modifiés.

Ainsi, vous pouvez installer un système (tel que 4.0-release) à partir du CD, puis vous pourrez le mettre à jour un certain nombre de fois en 4.0-stable et par la suite effectuer une mise à jour majeure vers 4.1-release et ainsi de suite.

Garder les Composants Synchronisés

Il est important de comprendre qu'OpenBSD est un Système d'Exploitation, et il faut le prendre en tant que tel et non pas comme un noyau entouré d'un ensemble d'outils. Vous devez vous assurer que votre noyau, le "userland" (les utilitaires et fichiers complétant le noyau) et l'arborescence des ports sont synchronisés, autrement des choses désagréables peuvent arriver. Dit autrement (vu que les gens continuent à commettre les mêmes erreurs), vous ne pouvez pas utiliser des ports tout neufs sur un système datant d'il y a un mois, ou reconstruire un noyau à partir de -current et espérer qu'il fonctionne avec un "userland" -release. Oui, cela veut dire que vous aurez besoin d'effectuer une mise à jour majeure de votre système si vous voulez utiliser un nouveau programme qui a été rajouté aujourd'hui à l'arborescence des ports. OpenBSD n'a malheureusement que des ressources limitées.

Il faut aussi comprendre que le processus de mise à jour majeure est uniquement supporté dans une seule direction uniquement : de l'ancien au nouveau, et de -stable vers -current. Vous ne pouvez pas utiliser 4.1-current (ou un snapshot), puis décider que c'est trop dangereux, et revenir vers 4.1-stable. Vous ne pouvez compter que sur vous-même si vous choisissez un autre chemin que celui, supporté, consistant à réinstaller votre système proprement. Vous ne devez espérer aucune aide de la part de l'équipe de développement OpenBSD.

Oui, cela veut dire que vous devez prendre le temps de réfléchir avant d'utiliser -current.

5.2 - Pourquoi devrais-je compiler mon système depuis les sources ?

Actuellement, il y a de fortes chances pour que vous n'en ayez pas besoin.

Voici quelques raisons pour NE PAS compiler votre systèmes depuis les sources :

Voici quelques raisons d'avoir besoin de compiler depuis les sources :

L'équipe OpenBSD réalise fréquemment des instantanés basés sur le code de -current pour toutes les plates-formes. Dans la plupart des cas, cela vous suffira pour utiliser -current.

La raison la plus courante de compiler depuis les sources est de suivre la branche -stable, pour laquelle la compilation depuis les sources est la seule issue supportée...

5.3 - Compilation d'OpenBSD depuis les sources

5.3.1 - Aperçu du processus de compilation

La compilation d'un système OpenBSD depuis les sources implique un certain nombre d'étapes : Il ya deux étapes supplémentaires que certains utilisateurs pourraient vouloir réaliser, ceci dépend de la raison de la compilation et de la présence ou non de X :

5.3.2 - Installer ou mettre à niveau depuis les binaires les plus récents

La première étape dans la compilation depuis les sources est de s'assurer d'avoir le binaire le plus récent installé. Utilisez ce tableau afin de savoir ou vous en êtes, ou vous voulez aller, et avec quel binaire commencer :

Vous êtes au But Mise à niveau binaire vers ensuite ...
Ancienne -release Nouvelle release Dernière release C'est fait !
-release -stable Dernière release Récupérer & compiler -stable
Ancienne -stable -stable Nouvelle release Récupérer & compiler -stable
-release -current Dernier instantané Récupérer (optionnel) & compiler -current
Ancienne -current -current Dernier instantané Récupérer (optionnel) & compiler -current

Il est recommandé d'installer le binaire via l'option "Upgrade" du média d'installation. Si ce n'est pas possible, vous pouvez aussi décompacter les binaires comme décris ici. Vous pouvez faire le processus complet de mise à niveau sans soucis, incluant la création d'utilisateurs ou d'autres changements de répertoires de /etc.

5.3.3 - Téléchargement des sources appropriées

Le source d'OpenBSD est géré en utilisant le système de contrôle de versions CVS, et cvs(1) est utilisé pour récupérer les sources désirées sur votre machine locale, à des fins de compilation. Ceci peut être réalisé en utilisant le serveur AnonCVS (une machine proposant une copie du dépôt CVS utilisé par le projet OpenBSD) et ce publiquement, ou depuis une archive locale que vous maintenez en utilisant les programmes CVSup, ou CVSync, disponibles dans les paquetages. CVSup peut aussi être utilisé en mode "checkout", mais cela n'est pas couvert par le présent document. Si vous avez plusieurs machines sur lesquelles vous désirez maintenir le code source, vous devriez trouver utile d'avoir un dépôt CVS local, créé et maintenu en utilisant CVSup ou CVSync.

Après avoir décidé quel Serveur AnonCVS vous allez utiliser, vous devez effectuer un "checkout" (récupération) de l'arbre des sources, que vous maintiendrez par la suite en lançant des "updates" (mises à jour), afin de récupérer les fichiers les plus récents dans votre arbre local.

La commande CVS(1) dispose de nombreuses options, certaines d'entre elles sont requises afin de récupérer et de mettre à jour un arbre. Les autres commandes peuvent résulter en un arbre cassé. Le fait de comprendre et de suivre les directions est ici important.

Suivis de -current

Dans ce cas, nous supposons que vous utilisez un serveur AnonCVS publique, anoncvs@anoncvs.example.org:/cvs. Nous supposons également que vous utilisez le shell sh(1), vous devrez dans le cas contraire ajuster certaines commandes.

Pour récupérer un arbre des sources CVS de -current, vous pouvez utiliser la commande suivante : # cd /usr # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT checkout -P src

Une fois l'arbre récupéré, vous pourrez plus tard le mettre à jour avec : # cd /usr # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT up -Pd

Suivis de -stable
Si vous souhaitez récupérer une "branche" alternative de l'arbre, comme la branche -stable, vous devez utiliser le modificateur "-r" : # cd /usr # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT checkout -rOPENBSD_4_1 -P src Ceci aura pour effet de récupérer les fichiers sources de la branche OPENBSD_4_1, aussi connue sous le nom de "Branche patchée" ou "-stable". Vous pourrez mettre à jour le code de façon similaire : # cd /usr/src # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT up -rOPENBSD_4_1 -Pd CVS est vraiment agréable car il permet de suivre une balise dans les fichiers récupérés, vous n'avez ainsi pas à vous rappeler de la partie "-rOPENBSD_4_1" de la ligne de commande, ceci sera mémorisé jusqu'a ce que vous l'effaciez ou en spécifiez un autre via l'option "-A" de "update". Cependant, il est probablement plus correct de fournir trop d'infos que pas assez sur vos lignes de commande CVS.

L'arbre "src" ayant le seul à avoir été montré jusqu'a présent, vous pouvez faire les mêmes étapes pour "XF4" et "ports". Toutes les parties d'OpenBSD devant être en synchronisation, tous les arbres utilisés devraient être mis à jour en même temps. Vous pouvez allier plusieurs récupérations sur une seule ligne (-stable est montré) avec : # cd /usr/src # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT checkout -rOPENBSD_4_1 -P src ports XF4 Cependant, les mises à jour doivent être faites répertoire par répertoire.

A ce niveau, que vous ayez suivi -stable ou -current vous devriez avoir un arbre des sources correct. Soyez attentif à ce que vous récupérez -- vous pourriez compiler -current en pensant compiler -stable.

Pré-chargement de l'arbre des sources : src.tar.gz, sys.tar.gz

Au lieu de télécharger l'arbre des sources dans sa totalité à partir d'un serveur AnonCVS, vous pouvez le "pré-charger" à partir des fichiers des sources se trouvant sur le CD d'OpenBSD ou sur les serveurs FTP. Vous économiseriez ainsi beaucoup de temps et de bande passante. Ceci est particulièrement vrai si utilisez -stable, étant donné le peu de différences entre cette version et -release.

Pour extraire l'arbre des sources à partir du CD vers /usr/src (en supposant que le CD est monté dans /mnt) : # cd /usr/src; tar xzf /mnt/src.tar.gz # cd /usr; tar xzf /mnt/XF4.tar.gz # tar xzf /mnt/ports.tar.gz Les fichiers sources téléchargeables depuis les serveurs FTP sont séparés en deux fichiers pour minimiser le temps nécessaire à leur téléchargement pour les personnes souhaitant travailler avec telle ou telle partie de l'arbre uniquement. Ces deux fichiers sont sys.tar.gz, qui contient les fichiers utilisés pour créer le noyau, et src.tar.gz qui contient toutes les autres applications "userland", hormis l'arbre des ports et les sources X11. Cependant, et de manière générale, vous aurez besoin des deux. En supposant que vous les ayez téléchargé src.tar.gz et sys.tar.gz dans /usr : # cd /usr/src # tar xzf ../sys.tar.gz # tar xzf ../src.tar.gz # cd /usr # tar xzf XF4.tar.gz # tar xzf ports.tar.gz

L'extraction de toutes les parties de l'arbre source n'est pas obligatoire mais si on souhaite garder un système cohérent, il est conseillé de les extraire toutes.

Astuces CVS courantes

Comme indiqué précédemment, certaines options sont obligatoires afin d'obtenir un arbre src d'OpenBSD valide. L'option "-P" ci-dessus est l'une d'entre elle : elle "prune" (efface) les répertoires vides. Avec les années, des répertoires ont été créés puis supprimés, et les noms de ces répertoires sont parfois utilisés actuellement pour des fichiers. Sans l'option "-P", votre arbre NE compilera PAS.

Même chose pour l'option -d sur une commande 'update' -- elle crée les nouveaux répertoires ayant pu être ajoutés au dépôt depuis votre dernier "checkout".

Les utilisateurs de CVS expérimentés auront pu se demander pourquoi le CVSROOT est précisé et utilisé dans cet exemple, alors que cvs(1) enregistre la situation du serveur dans l'arbre ainsi obtenu. Ceci est correct, cependant, un utilisateur devra souvent outrepasser le serveur enregistré, et de nombreuses personnes recommandent de toujours spécifier le dépôt à utiliser. Il est aussi à noter que si la variable d'environnement CVSROOT peut être utilisée directement par cvs(1), elle est utilisée uniquement si rien ne viens la remplacer, et la spécification de la ligne de commande est prépondérante.

Dans cet exemple, notez que -Pd est utilisé comme paramètre de la commande up. Ceci est une autre de ces options REQUISES, elle permettra aux nouveaux répertoires qui n'existaient pas dans la récupération précédente d'être créés lors du processus de mise à jour.

Il est souvent utile d'utiliser un .cvsrc dans votre répertoire home afin de spécifier les options par défaut. Un fichier .cvsrc d'exemple : $ more ~/.cvsrc cvs -q -danoncvs@anoncvs.example.org:/cvs diff -up update -Pd checkout -P Ce fichier ordonnera à cvs(1) d'utiliser le serveur anoncvs@anoncvs.example.org:/cvs, supprimant les sorties souvent inutiles ("-q" pour "quiet", tranquille) pour toutes les opérations, la commande "cvs up" utilisant par défaut -Pd, la commande "cvs diff" réalisant par défaut des "diffs unifiés" suite à l'option "-u", et un "cvs checkout" utilisera l'option "-P". Tandis que cela est confortable, si vous oubliez que ce fichier existe, ou si vous essayez de lancer ces commandes auxquelles vous êtes habitué sans ce fichier, vous rencontrerez des problèmes.

L'arbre des sources est constitué d'un grand nombre de petits fichiers. Il est donc conseillé d'activer soft updates sur la partition où se trouve cet arbre afin d'améliorer significativement les performances.

5.3.4 - Compilation du noyau

Nous supposerons que vous désirez construire un noyau standard (GENERIC ou GENERIC.MP). Normalement, c'est ce que vous devriez faire. N'essayez pas de construire un noyau personnalisé si vous ne maîtrisez pas le processus de compilation standard.

Evidemment, le noyau est un composant TRES dépendant du matériel du système. Les sources du noyau sont dans le répertoire /usr/src/sys. Certaines parties du code du noyau d'OpenBSD sont utilisées sans distinction de plate-forme, alors que d'autres sont très spécifiques à un processeur ou une architecture. Si vous regardez dans le répertoire /usr/src/sys/arch/, vous verrez certaines choses quelque peu intrigantes -- par exemple, il y a des répertoires mac68k, m68k et mvme68k. Dans ce cas, les systèmes mvme68k et mac68k utiliseront tous deux le même processeur, mais les machines sur lesquelles ils sont basés sont très différentes, et elles demandent ainsi un noyau très différent (il y a bien plus de choses qu'un processeur dans un ordinateur !). Cependant, certaines parties du noyau sont communes, elles demeurent dans le répertoire m68k. Si vous compilez simplement un noyau, les répertoires de l'architecture de base comme m68k ne sont pas un soucis, vous devriez travailler uniquement avec les répertoires de "l'architecture composant", comme mvme68k.

Les noyaux compilés sont basés sur les fichiers de configuration du noyau, qui se trouvent dans le répertoire /usr/src/sys/arch/<votre plate-forme>/conf. La compilation du noyau consiste à l'utilisation du programme config(8) pour créer et peupler un répertoire compile, qui se terminera dans /usr/src/sys/arch/<votre plate-forme>/compile/<nom du noyau>. Pour cet exemple, nous supposerons que vous utilisez la plate-forme i386 :

# cd /usr/src/sys/arch/i386/conf # config GENERIC # cd ../compile/GENERIC # make clean && make depend && make [...beaucoup de sortie...] # make install
Remplacez "i386" sur la première ligne par le nom de votre plate-forme. La commande machine(1) peut vous donner le nom de la plate-forme sur laquelle vous êtes afin de pouvoir utiliser "cd /usr/src/sys/arch/`machine`/conf" à la place de la première ligne.

A ce stade, redémarrez votre machine afin d'activer le nouveau noyau. Notez que le nouveau noyau devrait être lancé avant l'étape suivante, ce que vous savez si vous avez suivis les explications ci-dessus sur la mise à niveau vers les instantanés les plus récents. Parfois, les APIs changent cependant, et l'ancien noyau sera dans l'incapacité de lancer de nouvelles applications, mais les nouveaux noyaux supportent en général les applications plus anciennes.

Variation du processus ci-dessus : arbre des sources en lecture seule

Parfois, vous voudrez peut-être vous assurez que /usr/src/sys reste intacte. Ceci peut être fait en utilisant les procédés suivants :
$ cd /somewhere $ cp /usr/src/sys/arch/i386/conf/GENERIC . $ config -s /usr/src/sys -b . GENERIC $ make clean && make depend && make ... beaucoup de messages affichés ...
Remarquez que vous pouvez compiler un noyau sans accès root, mais vous devez être root pour pouvoir l'installer.

5.3.5 - Compilation du "userland"

Il y a une marche à suivre spécifique afin que cela fonctionne, sans quoi vous vous amuserez à trouver d'où les problèmes viennent.

5.4 - Compilation d'une Révision

Qu'est ce qu'une "release" (révision), et pourquoi voudrais-je en créer une ?

Une "release" est le jeu de fichiers complet pouvant être utilisé pour installer OpenBSD sur un ordinateur. Si vous n'avez qu'une seule machine sous OpenBSD, vous n'avez pas de réelle motivation à construire une release, le processus ci-dessus vous apportant tout ce dont vous avez besoin. Un exemple d'utilisation du processus de release pourrait être de compiler une -stable sur une machine puissante, et de faire une release installable sur tous vos ordinateurs.

Le processus de release utilise les binaires créés dans le répertoire /usr/obj lors du processus ci-dessus, vous devez donc accomplir celui-ci au préalable, et rien ne doit perturber le répertoire /usr/obj. Ceci peut être un problème si vous utilisez un disque mémoire pour /usr/obj avec de petites performances lors du processus de compilation, vous ne voudrez pas redémarrer l'ordinateur entre les étapes de compilations et de "release" !

Le processus de release requiert deux répertoires de travail, appelés DESTDIR et RELEASEDIR. Tous les fichiers faisant partie d'une installation OpenBSD "propre" seront copiés à l'endroit correct au sein de DESTDIR. Ils seront tar(1)és puis placés dans RELEASEDIR. A la fin du processus, RELEASEDIR arborera la release OpenBSD intégralement. Le processus de release utilisera aussi /mnt, ce point ne doit donc pas être utilisé par autre chose pendant le processus de release. A titre d'exemple, nous utiliserons DESTDIR à /usr/dest et RELEASEDIR à /usr/rel.

Deux utilitaires qui ne sont pas dans le système de base d'OpenBSD, crunch et crunchgen(1), sont utilisés pour créer un exécutable unique composé de plusieurs binaires. Le nom qui l'invoque détermine quel composant binaire est utilisé. C'est un peu comme si plusieurs fichiers de programmes individuels étaient concentrés sur un ramdisk noyau qui existe sur les disquettes et autres médias d'installation. Ces utilitaires doivent être traités lorsque le processus de release est lancé Ils n'ont besoin d'être installés qu'une seule fois, mais certaines personnes oublient parfois cette étape, et ces programmes sont compilés rapidement, certaines personnes optent pour compiler crunch et crunchgen à chaque fois qu'ils utilisent le script.

Vous devez avoir les privilèges root pour créer une release.

Faire une release

Tout d'abord, si cela n'a pas encore été fait sur la machine, compilez crunch et crunchgen :
# cd /usr/src/distrib/crunch && make obj depend all install
A présent, définissons nos variables d'environnement DESTDIR et RELEASEDIR :
# export DESTDIR=/usr/dest # export RELEASEDIR=/usr/rel
Nettoyons DESTDIR et créons le répertoire :
# test -d ${DESTDIR} && mv ${DESTDIR} ${DESTDIR}.old && rm -rf ${DESTDIR}.old & # mkdir -p ${DESTDIR} ${RELEASEDIR}
RELEASEDIR ne doit pas forcément être vide lors du lancement du processus mais, cependant, s'il y a des changement dans les fichiers de la release ou dans leurs noms, les anciens fichiers seront conservés. Vous voudrez ainsi certainement effacer ce répertoire.

Passons à présent à la release elle-même :

# cd /usr/src/etc # make release
Une fois la release construite, il peut être bon de la vérifier afin d'être sûr que les fichiers tar reflètent bien le contenu de DESTDIR. La sortie de cette étape devrait être très courte :
# cd /usr/src/distrib/sets # sh checkflist
Vous avez à présent un jeu de fichiers complet et fonctionnel dans RELEASEDIR. Ces fichiers peuvent être utilisés afin d'installer ou de mettre à jour OpenBSD sur d'autres machines.

Les instructions faisant foi sur la création d'une release sont dans release(8).

Remarque : Si vous souhaitez distribuer les fichiers résultants par HTTP pour être utilisables par les scripts de mise à jour ou d'installation, vous aurez besoin d'ajouter un fichier "index.txt". Ce fichier contient la liste de tous les fichiers constituant votre release fraîchement créée.

# /bin/ls -1 >index.txt

5.5 - Compilation de X

X utilise possède un processus de compilation différent du reste de l'arbre OpenBSD, étant basé sur imake, plutôt que sur le make(1) standard. Une conséquence de ceci est qu'il n'y a pas de répertoire "obj", les binaires générés finissent mélangés au code source, ce qui peut poser des problèmes (ou du moins des sorties excessives) avec cvs(1). Une solution à ce problème est d'utiliser lndir(1) afin de créer un répertoire ombre contenant des liens symboliques vers le répertoire des sources actuel pour l'arbre XF4.

i386 seulement : La plate-forme i386 nécessite l'installation des paquetages "tcl" et "tk" avant la compilation de X (ils se trouvent dans l'arbre des ports à /usr/ports/lang/tcl/8.4/ et /usr/ports/x11/tk/8.4/. L'installation du paquetage "tk" installera "tcl" en tant que dépendance). Comme d'habitude, l'installation qu'un paquetage est plus rapide que l'installation de ces applications depuis les sources. Un échec de l'installation de ces paquetages avant de compiler X est quelque chose de frustrant, car le système fonctionnera un certain temps sans afficher la moindre erreur.

Afin de compiler X en utilisant le "répertoire ombre" de /usr/Xbld (compiler et installer les nouveaux binaires dans les bons répertoires), suivez ces étapes :

# rm -rf /usr/Xbld # mkdir -p /usr/Xbld # cd /usr/Xbld # lndir ../XF4 [...beaucoup de sortie...] # make build [...beaucoup de sortie...]

Création d'une release X

Ceci est similaire au processus de release principal. Après avoir compilé X avec succès, vous définirez DESTDIR et RELEASEDIR, de la même manière qu'évoqué précédemment. RELEASEDIR peut être le même répertoire que la principale RELEASEDIR système, mais DESTDIR sera effacé et reconstruit lors de ce processus. Si cela est fait avec attention, ce n'est pas un problème, mais l'utilisation d'une DESTDIR séparée est plus sûr.

Pour cet exemple, nous utiliserons les DESTDIR et RELEASEDIR comme /usr/Xbld/dest et /usr/Xbld/rel, respectivement. Ceci doit être fait après le processus de compilation ci-dessus.

# export DESTDIR=/usr/Xbld/dest # export RELEASEDIR=/usr/Xbld/rel # cd /usr/Xbld # rm -rf dest # mkdir dest rel # make release

Si vous prévoyez de faire à la fois une compilation et une release de X, vous pouvez utiliser une cible make(1) différente, "b-r", qui réalise à la fois la compilation et les étapes de release. La cible "b-r" suppose que DESTDIR et RELEASEDIR sont les sous-répertoires "rel" et "dest" au sein de votre sous-répertoire de compilation :

# rm -rf /usr/Xbld # mkdir -p /usr/Xbld /usr/Xbld/dest /usr/Xbld/rel # cd Xbld # lndir ../XF4 [...beaucoup de sortie...] # make b-r [...beaucoup de sortie...]

5.6 - Pourquoi aurais-je besoin d'un noyau sur mesure ?

En réalité, vous n'en avez très probablement pas besoin.

Un noyau sur mesure est un noyau construit à partir d'un fichier de configuration autre que GENERIC, le fichier de configuration fourni de base. Un noyau sur mesure peut se baser sur du code source -release, -stable ou -current comme c'est le cas pour le noyau GENERIC. Alors que la compilation de votre propre noyau GENERIC est supportée par l'équipe OpenBSD, la compilation de votre propre noyau sur mesure ne l'est pas.

Le fichier de configuration noyau OpenBSD standard (GENERIC) est conçu pour convenir à la plupart des utilisateurs. Bon nombre de personnes ont rendu leur système inopérant en essayant d'optimiser le noyau au lieu d'améliorer son fonctionnement. Il existe certaines personnes qui pensent qu'un noyau et un système d'exploitation doivent être taillés sur mesure pour obtenir des performances optimales. Ceci n'est pas vrai dans le cas d'OpenBSD. Seules les personnes très compétentes avec des applications très particulières doivent penser à faire un noyau et un système sur mesure.

Voici quelques raisons pour lesquelles vous devriez créer un noyau sur mesure :

Voici quelques raisons pour lesquelles vous ne devez pas compiler un noyau sur mesure :

La suppression de pilotes pourrait rendre plus rapide la phase de démarrage système. Cependant, elle peut compliquer la récupération suite à problème matériel. La suppression de pilotes est une tâche très souvent mal réalisée. La suppression de pilotes ne rendra pas votre système plus rapide de manière perceptible même si elle peut produire un noyau plus petit. La suppression des parties liées au déboguage et à la vérification d'erreurs peut améliorer les performances, mais rendra impossible l'analyse du système si quelque chose ne fonctionne plus ou pas.

Encore une fois, les développeurs ignorent d'habitude les rapports de bogue relatifs à des noyaux personnalisés, sauf si le problème peut être reproduit avec un noyau GENERIC. Vous aurez été prévenu.

5.7 - Options de configuration du noyau

Nous partons du fait que vous avez lu ci-dessus, et que vous aimez la douleur. Il est aussi supposé que vous avez un but ne pouvant être atteint ni avec Configuration au démarrage (UKC>), ni avec config(8)urer un noyau GENERIC. Si les deux possibilités sont fausses, vous devriez vous en tenir à utiliser GENERIC. Vraiment.

La création d'un noyau OpenBSD est contrôlée par le biais de fichiers de configuration, se trouvant dans le répertoire /usr/src/sys/arch/<arch>/conf/ par défaut. Toutes les architectures possèdent un fichier, GENERIC, qui peut être utilisé pour générer un noyau OpenBSD standard pour une plate-forme donnée. Il peut aussi y avoir d'autres fichiers de configuration qui peuvent être utilisés pour créer des noyaux avec des objectifs différents tels que la minimisation de l'utilisation de la RAM, les stations de travail "diskless", etc.

Le fichier de configuration est traité par config(8), qui crée et peuple un répertoire de compilation situé sous ../compile. Pour une installation typique, le chemin absolu du répertoire serait situé sous /usr/src/sys/arch/<arch>/compile/. config(8) peut aussi créer un fichier Makefile, et d'autres fichiers requis pour créer avec succès un noyau.

Les options de configuration du noyau sont des options que vous ajoutez à la configuration de votre noyau pour activer certaines caractéristiques dans celui-ci. Ceci vous permet d'avoir exactement le support que vous voulez sans vous encombrer des pilotes inutiles. Il y a une multitude d'options qui vous permettront de personnaliser votre noyau. Veuillez consulter la page de manuel options(4) pour une liste complète des options. Vous pouvez aussi consulter les fichiers d'exemples de configurations qui sont disponibles pour votre architecture.

L'ajout, la suppression, ou la modification d'options dans votre noyau ne doivent être effectués que si vous avez une bonne raison pour le faire ! N'éditez pas le fichier de configuration GENERIC !! La seule configuration du noyau supportée par l'équipe OpenBSD est le noyau GENERIC, la combinaison d'options figurant dans les fichiers /usr/src/sys/arch/<arch>/conf/GENERIC et /usr/src/sys/conf/GENERIC tels que livrés par l'équipe OpenBSD (i.e. non édités). Emettre un rapport de bogue concernant un noyau personnalisé va dans la plupart des cas se résumer à une réponse vous demandant d'essayer de reproduire le problème avec un noyau GENERIC. Les options ne sont pas toutes compatibles entre elles, et plusieurs options sont nécessaires au bon fonctionnement du système. Il n'y a aucune garantie quant au fonctionnement d'un noyau personnalisé que vous avez réussi à compiler. Il n'y a aucune garantie sur le fait qu'un noyau pouvant être "config(8)uré" puisse être compilé.

Vous pouvez voir les fichiers de configuration spécifiques à une plate-forme donnée ici :

Si vous lisez attentivement ces fichiers, vous verrez une ligne comme : include "../../../conf/GENERIC" Cela signifie que l'on fait référence à un autre fichier de configuration. Ce fichier comprend toutes les options qui ne sont pas dépendantes de l'architecture. Donc quand vous créez votre fichier de configuration, soyez sûr de regarder /sys/conf/GENERIC pour voir ce que vous voulez.

Toutes les options ci-dessous doivent être placées dans le fichier de configuration du noyau avec le format :

option      nom
ou
option      nom=valeur
Par exemple, pour utiliser l'option "DEBUG" dans le noyau, il faut mettre la ligne suivante :
option DEBUG
Les options dans le noyau OpenBSD sont traduites en tant qu'options du préprocesseur, donc une option telle que DEBUG compilerait les sources avec l'option -DDEBUG. Ce qui est équivalent à placer un #define DEBUG à travers les sources du noyau.

Vous aurez peut-être parfois besoin de désactiver une option précédemment définie dans le fichier "src/sys/conf/GENERIC" typiquement. Bien entendu, vous pouvez modifier une copie de ce fichier, mais une meilleure méthode consiste à utiliser la clause rmoption. Par exemple, si vous souhaitiez vraiment désactiver le débogueur intégré au noyau (non recommandé !), vous ajouteriez la ligne suivante : rmoption DDB à votre fichier de configuration du noyau. option DDB est définie dans src/sys/conf/GENERIC, mais la ligne rmoption ci-dessus la désactive.

Encore une fois, veuillez consulter options(4) pour plus d'informations concernant les spécificités de ces options. Il est à noter que plusieurs options possèdent leurs propres pages de manuel -- il faut toujours lire toutes les informations disponibles au sujet d'une option avant de l'ajouter ou la supprimer de votre noyau.

Compiler un noyau sur mesure

Dans ce cas, nous compilerons un noyau supportant les cartes série ISA multi-port boca(4). Cette carte n'est pas dans le noyau GENERIC, du fait qu'elle entre en conflit avec d'autres drivers. Une autre raison courante de construire un noyau personnalisé est d'utiliser RAIDframe, trop gros pour être dans le noyau par défaut. Il y a deux moyens courants de faire un noyau personnalisé : copier le fichier de configuration GENERIC vers un autre nom et l'éditer, ou créer un fichier "wrapper" qui inclut le noyau standard GENERIC ainsi que toutes les options dont vous avez besoin, et qui ne sont pas dans GENERIC. Dans ce cas, votre fichier "wrapper" pourrait ressembler à :
include "arch/i386/conf/GENERIC" boca0 at isa? port 0x100 irq 10 # BOCA 8-port serial cards pccom* at boca? slave ?
Les deux lignes au regard des cartes boca(4) sont copiées depuis les lignes commentées dans GENERIC, avec l'IRQ ajusté comme requis. L'avantage d'utiliser ce fichier "wrapper" est que les changements imprévus dans GENERIC sont automatiquement mis à jour comme lors de toute mise à jour du code. L'inconvénient est qu'on ne peut supprimer un périphérique (cependant, c'est en général une mauvaise idée).

Un autre moyen de générer un noyau personnalisé est de faire une copie du GENERIC standard, en lui donnant un autre nom, et en l'éditant selon les besoins. L'inconvénient est que les futures mises à jour du fichier de configuration GENERIC devront être fusionnés dans votre copie, ou vous devrez refaire votre fichier de configuration.

Dans un autre événement, après avoir fait votre fichier de configuration personnalisé, utilisez config(8) et construisez le noyau comme documenté ci-dessus.

Les instructions complètes pour la création de votre propre noyau sont dans la page de manuel afterboot(8).

5.8 - Configuration au démarrage

Lorsque vous démarrez votre système il est possible que vous remarquiez que votre noyau trouve vos périphériques mais à la mauvaise IRQ. Et que vous aillez immédiatement besoin de ce périphérique. Sans recompiler votre noyau vous pouvez utiliser la configuration au démarrage de celui-ci. Cela vous permettra de corriger votre problème pour cette fois et uniquement pour cette fois. Si vous redémarrez le système il faudra recommencer la procédure. Il s'agit donc d'une méthode temporaire. Le problème devra être corrigé en utilisant config(8). De plus votre noyau à besoin de l'option BOOT_CONFIG dans la configuration du noyau. Le noyau GENERIC possède cette option.

Une grande partie de ce document peut-être trouvée dans la page de manuel boot_config(8).

Pour démarrer avec UKC (User Kernel Config), il faut spécifier l'option -c au démarrage.

boot> boot hd0a:/bsd -c
ou n'importe quel autre noyau que vous voulez démarrer. L'invite de commandes UKC apparaîtra, et vous pourrez spécifier au noyau les périphériques que vous désirez modifier, ceux que vous voulez activer ou désactiver.

Voici un liste des commandes les plus utilisées dans UKC.

Une fois votre noyau configuré, utilisez quit ou exit et continuez le démarrage. Une fois votre système démarré, vous devriez rendre la modification permanente au niveau de votre binaire du noyau, tel que c'est décrit dans utilisation de config(8) pour changer le binaire du noyau

5.9 - Utilisation de config(8) pour changer le binaire du noyau

Les options -e et -u de config(8) peuvent être très utiles et vous évitent de perdre du temps à recompiler votre noyau. Le drapeau -e vous permet de rentrer en configuration UKC alors que le système fonctionne. Les changements prendront effets au prochain redémarrage. Le drapeau -u permet de voir si des changements ont été effectués au noyau pendant le démarrage, signifiant que vous avez utilisé boot -c pour entrer en configuration UKC.

Les exemples suivants montrent la désactivation des périphériques ep* dans le noyau. Pour plus de sécurité, il est préférable d'utiliser l'option -o qui écrira les changements dans un fichier spécifié. Par exemple : config -e -o bsd.new /bsd écrira les changements dans bsd.new. Les exemples n'utilisent pas l'option -o, mais les changements sont ignorés et ne sont pas écrits dans le binaire du noyau. Pour plus d'informations sur les messages d'erreur et autres avertissements, lisez la page de manuel config(8) .

$ sudo config -e /bsd OpenBSD 4.1 (GENERIC) #1107: Sat Sep 16 19:15:58 MDT 2006 deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC warning: no output file specified Enter 'help' for information ukc> ? help Command help list add dev Add a device base 8|10|16 Base on large numbers change devno|dev Change device disable attr val|devno|dev Disable device enable attr val|devno|dev Enable device find devno|dev Find device list List configuration lines count # of lines per page show [attr [val]] Show attribute exit Exit, without saving changes quit Quit, saving current changes timezone [mins [dst]] Show/change timezone nmbclust [number] Show/change NMBCLUSTERS cachepct [number] Show/change BUFCACHEPERCENT nkmempg [number] Show/change NKMEMPAGES shmseg [number] Show/change SHMSEG shmmaxpgs [number] Show/change SHMMAXPGS ukc> list 0 audio* at sb0|sb*|gus0|pas0|sp0|ess*|wss0|wss*|ym*|eap*|eso*|sv*|neo*|cmpci* |clcs*|clct*|auich*|autri*|auvia*|fms*|uaudio*|maestro*|esa*|yds*|emu* flags 0x0 1 midi* at sb0|sb*|opl*|opl*|opl*|opl*|ym*|mpu*|autri* flags 0x0 2 nsphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr* |ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e p*|ep* phy -1 flags 0x0 3 nsphyter* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*| vr*|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep *|ep*|ep* phy -1 flags 0x0 4 qsphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr* |ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e p*|ep* phy -1 flags 0x0 5 inphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr* |ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e p*|ep* phy -1 flags 0x0 6 iophy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr* |ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e p*|ep* phy -1 flags 0x0 7 eephy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr* |ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e p*|ep* phy -1 flags 0x0 8 exphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr* |ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e p*|ep* phy -1 flags 0x0 [...snip...] ukc> disable ep 67 ep0 disabled 68 ep* disabled 69 ep* disabled 155 ep0 disabled 156 ep0 disabled 157 ep* disabled 158 ep* disabled 210 ep* disabled ukc> quit not forced

Dans l'exemple ci-dessus, tous les périphériques ep* sont désactivés du noyau et ne seront donc pas testés. Dans certaines situations où vous aurez effectué ces changements au démarrage avec UKC et boot -c, il vous faudra les rendre définitifs. Pour ce faire, il faudra utiliser l'option -u. Dans l'exemple suivant, l'ordinateur a été démarré avec UKC et les périphériques wi(4) sont désactivés. Étant donné que les changements fait par boot -c ne sont pas permanents, ceux-ci doivent être écrits sur le disque. Cet exemple montre comment écrire les changements effectués par boot -c dans un nouveau noyau binaire bsd.new.

$ sudo config -e -u -o bsd.new /bsd OpenBSD 4.1 (GENERIC) #1107: Sat Sep 16 19:15:58 MDT 2006 deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC Processing history... 105 wi* disabled 106 wi* disabled Enter 'help' for information ukc> quit

5.10 - Obtention d'une sortie plus verbeuse lors du démarrage

L'obtention d'une sortie plus verbeuse peut s'avérer être très utile lors des tentatives de résolution de problème au boot. Si vous avez un problème inhérent à votre disquette de boot et désirez obtenir plus d'informations, redémarrez. A l'arrivée au prompt "boot>", bootez avec l'option -c. Ceci vous permettra d'être dans UKC>, puis de faire :
UKC> verbose autoconf verbose enabled UKC> quit

Vous aurez à présent une sortie très verbeuse au démarrage.

5.11 - Problèmes courants, astuces et questions lors de la compilation et de la construction

La plupart du temps, les problèmes lors de la compilation sont causés par le fait de ne pas suivre précisément les indications précédentes. Cependant, il peut exister occasionnellement de véritables problèmes lors de la compilation de -current à partir du snapshot le plus récent mais les erreurs lors de la compilation de -release ou -stable sont presque toujours dues à une erreur de l'utilisateur.

Les problèmes les plus courants sont :

Voici tout de même certains problèmes auxquels vous pourriez être confronté :

5.11.1 - La compilation s'est arrêtée avec une erreur "Signal 11"

La compilation d'OpenBSD et d'autres programmes à partir des sources est une tâche qui sollicite le matériel plus que la plupart des autres opérations, faisant un usage intensif du CPU, du disque et de la mémoire. Par conséquence, si votre matériel a des problèmes, ces derniers apparaîtront plus facilement durant une compilation. Les défaillances "Signal 11" sont typiquement causées par des problèmes matériel, et la plupart du temps à cause de problèmes de mémoire. Mais ces défaillances peuvent aussi causées par le CPU, la carte mère, ou des problèmes de surchauffe. Votre système peut d'ailleurs être stable la plupart du temps et connaître des défaillances lors de la compilation de programmes.

Il est recommandé de réparer ou remplacer les composants à l'origine des défaillances; les problèmes pouvant se manifester sous d'autres formes plus tard. Si vous avez du matériel que vous souhaitez utiliser et qui ne vous pose aucun problème, installez simplement un snapshot ou une "révision".

Pour plus d'informations, consultez la Faq Sig11.

5.11.2 - "make build" échoue en générant un message "cannot open output file snake: is a directory"

Ceci est le résultat de deux erreurs séparées : Il est important de suivre soigneusement les instructions lors de la récupération et de la compilation de votre arbre.

5.11.3 Mon système sans IPv6 ne fonctionne pas !

Oui. Nous vous prions de ne pas faire de modifications au système de base pour lesquelles vous ne comprenez pas toutes les conséquences. Un "petit" changement dans le noyau peut avoir un impact très large sur le reste entier du système. Relisez s'il vous plaît ceci.

5.11.4 - Oops ! J'ai oublié de créer le répertoire /usr/obj avant de commencer !

En faisant un "make build" avant de faire un "make obj", vous devrez en terminer avec les fichiers objets accumulés dans votre répertoire /usr/src. C'est une mauvaise chose. Si vous désirez essayer d'avoir à télécharger l'arbre des sources une nouvelle fois, vous pouvez essayer les manipulations suivantes afin de nettoyer les fichiers objets : # cd /usr/src # find . -type l -name obj | xargs rm # make cleandir # rm -rf /usr/obj/* # make obj

5.11.5 - Conseil : Placer /usr/obj sur sa propre partition

Si vous compilez souvent, vous trouverez plus rapide de mettre /usr/obj sur sa propre partition. Le bénéfice est simple, il est typiquement plus rapide de : # umount /usr/obj # newfs VotrePartitionObj # mount /usr/obj que de faire "rm -rf /usr/obj".

5.11.6 - Comment ne pas compiler certaines parties de l'arbre ?

Vous souhaiterez peut-être de pas compiler certaines parties de l'arbre, typiquement parce que vous l'avez remplacé par une application incluse dans un paquetage, ou parce que vous voulez créer une installation "plus petite" pour diverses raisons. La solution est d'utiliser l'option SKIPDIR de /etc/mk.conf.

Note : il est de ce fait possible de compiler des systèmes cassés. Les résultats de cette option ne sont pas supportés par le projet OpenBSD.

5.11.7 - Ou puis-je avoir plus d'informations sur le processus de compilation ?

5.11.8 - Je ne vois aucun snapshot sur le site FTP. Ou sont-ils passés ?

Les snapshots peuvent être retirés lorsqu'ils deviennent anciens (ou obsolètes) ou lorsque la sortie d'une -release approche.

5.11.9 - Comment puis-je amorcer sur une nouvelle version du compilateur (gcc)?

Vous devriez vraiment installer le dernier snapshot.

OpenBSD supporte désormais deux compilateurs dans l'arbre, gcc v3.3.5 par la plupart des plates-formes, et également gcc v2.95.3 utilisé par des plates-formes qui n'ont pas encore été converties, ou qui ne seront pas converties à cause des manques du support de gcc3 ou de ses performances pauvres.

Les deux compilateurs sont dans des parties différentes de l'arbre :

Parce que la mise à niveau du compilateur est un peu comme le problème du poulet et de l'oeuf, les changements sur le compilateur intégré à l'arbre demandent une attention toute particulière. Vous devez construire le compilateur deux fois -- la première construction produit un compilateur qui génère un nouveau code mais utilise l'ancien code pour fonctionner, la deuxième construction construit un nouveau compilateur intégralement. En général, vous voudrez réaliser la procédure suivante : Si votre plate-forme utilise gcc 2.95.3 : # rm -r /usr/obj/gnu/egcs/gcc/* # cd /usr/src/gnu/egcs/gcc - ou - Si votre plate-forme utilise gcc 3.3.5 : # rm -r /usr/obj/gnu/usr.bin/gcc/* # cd /usr/src/gnu/usr.bin/gcc Procédure commune de compilation pour v3.3.5 ou v2.95.3 # make -f Makefile.bsd-wrapper clean # make -f Makefile.bsd-wrapper obj # make -f Makefile.bsd-wrapper depend # make -f Makefile.bsd-wrapper # make -f Makefile.bsd-wrapper install # make -f Makefile.bsd-wrapper clean # make -f Makefile.bsd-wrapper depend # make -f Makefile.bsd-wrapper # make -f Makefile.bsd-wrapper install

Puis lancer un make build classique.

5.11.10 - Quel est le meilleur moyen de mettre à jour /etc, /var, et /dev ?

En tant que politique, les logiciels dans l'arbre OpenBSD ne modifient pas de fichiers dans /etc automatiquement. Cela signifie que les modifications à réaliser incombent toujours à l'administrateur. Les mises à niveau n'y font pas exception. Pour mettre à jour les fichiers dans ces répertoires, déterminez tout d'abord les changements qui ont été opérés sur les fichiers de la base (distribution) et répétez manuellement ces changements.

Par exemple, pour voir les fichiers dans l'arbre qui ont changé récemment, faîtes un : # cd /usr/src/etc # ls -lt |more

Pour voir tous les changements dans le répertoire /etc entre des versions arbitraires d'OpenBSD, vous pouvez utiliser CVS. Par exemple, pour voir les changements entre 4.0 et 4.1, faîtes un : # cd /usr/src/etc # cvs diff -u -rOPENBSD_4_0 -rOPENBSD_4_1 Pour voir les changements entre 4.1 et -current ("HEAD"), utilisez : # cd /usr/src/etc # cvs diff -u -rOPENBSD_4_1 -rHEAD Le script /dev/MAKEDEV n'est pas mis à jour automatiquement lors du processus de compilation, mais il est cependant installé comme partie de la mise à jour binaire. En règle générale, c'est une bonne idée que de copier (si besoin est) et de lancer ce script depuis votre arbre des sources lors de la mise à niveau : # cd /dev # cp /usr/src/etc/etc.`machine`/MAKEDEV ./ # ./MAKEDEV all

Une fois que vous avez identifié les changements, appliquez à nouveau ceci à votre arbre local, en préservant toute configuration que vous auriez pu faire.

Les changements typiques de /etc à considérer, entre les release concernent :

Ces changements sont résumés dans upgrade39.html (pour aller vers 3.9-release) ou current.html (pour aller vers -current).

5.11.11 - Y a t'il un moyen facile de faire des changements sur tous les fichiers de la hiérarchie ?

De temps en temps, des fichiers et répertoires sont ajoutés, ou supprimés dans le fichier hierarchy. Aussi, le possesseur de l'information pour les portions du système de fichiers peut changer. Un moyen facile de s'assurer que votre hiérarchie est à jour est d'utiliser l'outil mtree(8).

Tout d'abord, procurez vous les dernières sources, en faisant : # cd /usr/src/etc/mtree # install -c -o root -g wheel -m 600 special /etc/mtree # install -c -o root -g wheel -m 444 4.4BSD.dist /etc/mtree # mtree -qdef /etc/mtree/4.4BSD.dist -p / -u

Votre hiérarchie de fichiers devrait à présent être à jour.

5.11.12 - La compilation de l'environnement X a échoué !

Une cause très commune d'échec de la compilation sur un système i386 est l'oubli de l'installation des paquetages "tcl" et "tk" avant cette opération, tel que précédemment indiqué dans la section Compilation de X.

5.11.13 - Puis-je cross-compiler ? Pourquoi pas ?

Les outils de cross-compilation sont présent dans le système, et sont utilisés par les développeurs lors de la création d'un nouveau port. Cependant, ils ne sont pas maintenus pour une utilisation généralisée.

Lorsque les développeurs créent le support d'une nouvelle plate-forme, l'un des premiers gros tests est la compilation native. Compiler le système depuis les sources augmente très fortement la charge de l'OS et de la machine, et permet de voir à quel point le système fonctionne correctement. Pour cette raison, OpenBSD réalise les compilations sur les plates-formes que la compilation concerne, ceci est appelé le "native building". Sans compilation native, il serait bien plus difficile de s'assurer que les différentes plates-formes sont stables et qu'elles ne font pas que booter.

[Index de La FAQ] [Section 4 - Guide d'Installation] [Section 6 - Le réseau]

[back] www@openbsd.org
$OpenBSD: faq5.html,v 1.82 2007/11/12 20:29:58 saad Exp $