[3.4 -> 3.5] | [3.5 -> 3.6] | [3.6 -> 3.7] | [3.7 -> 3.8] | [3.8 -> 3.9] | [3.9 -> 4.0] | [FAQ Index]

Guide de Mise à niveau : 4.0 vers 4.1

Remarque : Les mises à niveau ne sont supportées que d'une release à la suivante. Ne sautez pas les releases.

Il est hautement recommandé de lire entièrement la présente page et de bien comprendre la procédure de mise à jour avant de l'appliquer. Si vous comptez mettre à jour une machine critique ou physiquement distante, il est recommandé d'essayer la procédure ci-après sur un système local d'abord afin d'en vérifier le succès.

La mise à niveau est un moyen commode afin d'avoir votre système à jour avec la version la plus récente. Cependant, les résultats escomptés ne sont pas censés être précisément ceux d'une installation de zéro. Les fichiers d'anciennes bibliothèques en particulier ne sont pas supprimés lors du processus de mise à niveau, car ils pourraient être requis par de plus anciennes applications pouvant être ou non mises à jour à ce moment précis. Si vous voulez VRAIMENT vous débarrasser de ces anciens fichiers, vous feriez probablement mieux de réinstaller complètement votre système.

Table des matières :

Avant de mettre à jour
Procédure de mise à jour
Etapes finales

Avant de mettre à jour

Vérifiez si vous avez effectué des modifications à votre noyau. Par exemple vous pourriez avoir modifié un périphérique réseau afin que celui-ci utilise un paramètre non standard en utilisant config(8). Notez vos changements afin d'être en mesure de les reproduire sur le noyau 4.1.

rc.conf : A l'inverse des versions précédentes, il est désormais convenu que le fichier /etc/rc.conf ne devrait pas être altéré par l'utilisateur. Si vous avez effectué des changements à votre fichier /etc/rc.conf, fusionnez ces changements dans le fichier /etc/rc.conf.local. Si vous n'avez PAS de fichier /etc/rc.conf.local, copiez votre fichier /etc/rc.conf actuel vers /etc/rc.conf.local et supprimez la dernière ligne du script ! Sinon, ajoutez le contenu de votre fichier /etc/rc.conf actuel en haut de votre fichier /etc/rc.conf.local existant et supprimez la dernière ligne avant de procéder à la suite de la mise à jour.

Remarque concernant les utilisateurs d'ARM (armish, zaurus) : Des changements dans l'ABI requièrent un processus de mise à jour légèrement différent si vous n'utiliser pas le noyau d'installation standard. Ne redémarrez pas la machine entre l'installation du nouveau noyau et celle du userland.

Procédure de mise à jour

Mise à niveau avec un noyau d'installation

Si vous avez accès à la console système, la manière la plus facile et la plus sûre pour effectuer une mise à jour à partir de fichiers binaires consiste à démarrer depuis un média d'installation ou du noyau bsd.rd et de suivre les étapes de mise à jour; étapes fortement similaires à celles décrites dans la procédure d'installation. Ensuite, terminez la mise à jour en suivant les étapes finales ci-dessous.

Une solution simple pour démarrer sur le noyau d'installation est de mettre le noyau bsd.rd de la version 4.1 à la racine de votre lecteur de démarrage et de dire au chargeur de démarrage d'utiliser ce nouveau fichier bsd.rd. Sur amd64 et i386, vous pouvez entrer "boot bsd.rd" à l'invite de commandes boot>.

Mise à niveau sans noyau d'installation

Ce n'est pas la solution recommandée. Utilisez le noyau d'installation le plus souvent possible !

Le cas le plus courant est lorsque la machine est distante et que vous n'avez pas accès à la console système. On peut alors réaliser une mise à niveau depuis les sources :

Placez les fichiers d'installation dans un "bon" endroit. Assurez vous d'avoir la place suffisante !
Stopper toutes les applications "insécurisées" de démarrage au boot : Il y aura un moment ou PF ne sera pas le bienvenu pendant le processus de mise à jour, mais vos applications continueront de démarrer et de s'arrêter correctement. Toute application dépendante de PF pour la sécurité devrait être désactivée avant qu'un problème ne se produise, et ne devrait pas être réactivée avant que le fonctionnement de PF après la mise à jour ait été vérifié. Il pourrait également y avoir d'autres applications que vous devriez suspendre lors de la mise à jour, arrêtez et désactivez les de la même manière.
Vérification du noyau : Bien que la plupart des gens peuvent sauter cette étape, si vous aviez un noyau modifié en 4.0 il est probable que vous devrez modifier le noyau 4.1 de base. Surtout si vous effectuez une mise à jour à distance, maintenant est le bon moment pour vérifier que le nouveau noyau fonctionnera après le redémarrage de la machine. Si une modification du noyau doit être effectuée, la façon la plus sûre est de l'effectuer sur un système 4.1 local. Cela peut être aussi simple que de modifier un périphérique spécifique avec config(8) ou il peut être nécessaire de recompiler le noyau si l'option que vous souhaitez n'est pas incluse dans le noyau GENERIC. Consultez la section FAQ 5 - Construire le Système à partir des Sources avant d'envisager une recompilation de votre noyau.
Installez le(s) nouveau(x) noyau(x)
export RELEASEPATH=/usr/rel # où mettre les fichiers cd ${RELEASEPATH} rm /obsd ; ln /bsd /obsd && cp bsd /nbsd && mv /nbsd /bsd cp bsd.rd bsd.mp /
Notez les étapes additionnelles pour copier par dessus un premier noyau : celles-ci sont réalisées afin de s'assurer qu'il y ai toujours une copie valide du noyau sur le disque et que le système puisse booter en cas de coupure électrique ou de panne du système.
Installez les nouveaux fichiers /etc/firmware : parce que certains "firmwares" aient pu être mis à jour, il est possible que vous deviez mettre à jour le dossier /etc/firmware. Ceci concerne les utilisateurs de certains périphériques, bien que tout utilisateur devrait considérer cette étape. Afin d'extraire les fichiers firmware de base41.tgz, tapez en étant root les commandes suivantes :
cd / tar -C / -xzpf ${RELEASEPATH}/base41.tgz ./etc/firmware
Redémarrez votre système avec le nouveau noyau : (SAUF pour les utilisateurs d'ARM) Il peut être tentant de sauter cette étape, mais ceci devrait être fait dès à présent, le nouveau noyau lancera d'anciennes applications utilisateur (tel que la commande reboot ! qui sera importante pour la suite) mais souvent un nouveau "userland" ne fonctionnera PAS sur un ancien noyau.
Remarque : les utilisateurs d'ARM (armish/zaurus) DEVRAIENT sauter cette étape lors de cette mise à jour.
Installez les nouvelles applications du userland. Ne PAS installer etc41.tgz ni xetc41.tgz maintenant, car cela écrasera vos fichiers de configuration actuels !
export RELEASEPATH=/usr/rel cd ${RELEASEPATH} tar -C / -xzpf base41.tgz tar -C / -xzpf comp41.tgz tar -C / -xzpf game41.tgz tar -C / -xzpf man41.tgz tar -C / -xzpf misc41.tgz tar -C / -xzpf xbase41.tgz tar -C / -xzpf xfont41.tgz tar -C / -xzpf xserv41.tgz tar -C / -xzpf xshare41.tgz
Remarque : tous les jeux de fichiers ne devront pas être installés pour toutes les applications, cependant, si vous aviez installé originalement un jeu de fichiers, vous devrez certainement le mettre à niveau avec le nouveau jeu de fichiers.
Remarque : les fichiers appartenant à /etc sont gérés séparément. C'est pourquoi les archives etc41.tgz et xetc41.tgz ne sont PAS ouvertes à cette étape.
Mettre à jour /dev. Le nouveau fichier MAKEDEV sera copié dans /dev par l'installation de base41.tgz, vous n'avez ainsi qu'à faire ce qui suit :
cd /dev ./MAKEDEV all
Mise à niveau de /etc comme ci-dessous.
Redémarrez

Pendant ce processus, sendmail(8) pourrait produire des messages d'erreur comme :


        Nov 1 12:47:05 puffy sm-mta[16733]: filesys_update failed: No such
        file or directory, fs=., avail=-1, blocksize=380204

Ces messages peuvent être ignorés sans risque, mais vous pourriez vouloir arrêter sendmail(8) pendant la mise à niveau.

Etapes finales

1. Mise à jour de `/etc`

Si vous mettez à niveau en utilisant un noyau d'installation et faites une "mise à niveau" formelle, ou faites une mise à niveau binaire "sur place", il y a certaines étapes manuelles qui doivent être réalisées.

1.1. Nouveaux utilisateurs et groupes

Un service RIP et un service de vérification d'état de hôte ("host state") ont été importés. Pour utiliser ces nouveaux services, de nouveaux utilisateurs et groupes sont nécessaires. En tant que root, ajoutez les utilisateurs et groupes suivants en utilisant useradd(8) :
useradd -u88 -g=uid -c"RIP Daemon" -d/var/empty -s/sbin/nologin _ripd useradd -u89 -g=uid -c"HostState Daemon" -d/var/empty -s/sbin/nologin _hoststated
Ces étapes ajouteront en même temps les nouveaux utilisateurs et les groupes correspondants. Votre environnement devrait vous permettre de faire un "copier/coller" de cette commande.

1.2. Applications du Userland

Il ne s'agit pas d'une liste exhaustive des changements introduits entre 4.0 et 4.1 mais plutôt certains aspects qui impacteront un grand nombre d'utilisateurs lors de la mise à niveau. Pour une liste plus complète des changements, référez-vous à plus41.html ainsi qu'aux "changelogs" CVS.

"flags S/SA keep state" devient implicite dans pf.conf(5)
flags S/SA keep state est à présent le mode par défaut pour les règles "pass" de pf.conf(5), et les options no state et flags any ont été ajoutées afin de changer le fonctionnement par défaut. Les jeux de règles actuels continueront de se charger, mais leurs comportements pourraient changer quelque peu, ces nouvelles options par défaut étant plus restrictives. Les jeux de règles avec un filtrage sans état (no state) ou qui doivent créer des états sur les paquets intermédiaires (flags any) doivent être mis à jour explicitement afin d'obtenir le comportement souhaité.
Une attention toute particulière devra être prise avec l'interface enc0, étant donné que des états flottants constituent un problème potentiel pour le filtrage du trafic IPsec : les états doivent être liés à une interface afin d'éviter l'autorisation de trafic non chiffré dans le cas où isakmpd(8) serait amené à s'arrêter. Toutes les règles liées à l'interface enc0 devraient donc contenir keep state (if-bound).
Les partitions DOS de FreeBSD et NetBSD au niveau du MBR ne sont plus utilisées pour stocker des disklabels et pour chercher un disklabel.
Ainsi, les partitions DOS de FreeBSD et NetBSD au niveau du MBR ne contiendront plus une partition 'a' créée par le disklabel usurpé. Le disklabel de tels disques sera stocké et chargé à partir du secteur 1. Mais cette opération pourrait trouver un vieux disklabel de manière accidentelle. Utilisez fdisk(8) pour changer le type de partition en OpenBSD ('A6') pour utiliser le disklabel existant.
amd64, i386, macppc et mvmeppc n'essaient plus désormais de démarrer à partir de la première partition NetBSD lorsqu'aucune partition OpenBSD n'a été trouvée.
Encore une fois, utilisez fdisk(8) pour changer le type de partition en OpenBSD ('A6').
Nouvelle façon d'activer l'accounting au démarrage
Afin d'activer l'accounting lors du démarrage de la machine vous devez à présent renseigner la variable rc.conf "accounting=YES". La seule présence du fichier /var/account/acct ne suffit plus à l'activer automatiquement.
spamd(8) tourne à présent en mode greylist (liste grise) par défaut
Précédemment, le greylisting devait être activé via l'option -g ; a présent, il s'agit du comportement par défaut. L'option -b (qui servait à indiquer sur quelle IP spamd(8) devait écouter) peut être utilisée pour lancer spamd en mode blacklist seulement. La nouvelle option -l est utilisée pour indiquer sur quelle interface spamd doit écouter.
spamd.conf(5) est à présent contenu dans /etc/mail
Le fichier spamd.conf(5) a été déplacé de /etc vers /etc/mail. Déplacez votre fichier spamd.conf vers /etc/mail afin que spamd(8) puisse lancer la configuration correcte.
La MIB sysctl(3) des sondes du noyau est désormais hiérarchique
La MIB sysctl(3) des sondes contient à présent le nom du périphérique de la sonde ainsi que le type et l'index de celle-ci. Ainsi, précédemment lorsque vous tapiez "sysctl hw.sensors" vous pouviez avoir une sortie comme "hw.sensors.12=it0, Temp 1, 25.00 degC" ; à présent, vous verrez "hw.sensors.it0.temp0=25.00 degC". Mettez à jour votre fichier sensorsd.conf(5) afin de changer les noms de vos sondes.

1.3. Changement de fichiers dans `/etc`

Il vous faut extraire etc41.tgz dans un répertoire temporaire :

tar -C /tmp -xzpf ${RELEASEPATH}/etc41.tgz

Fichiers pouvant probablement être copiés de etc41.tgz "en l'état" :

etc/daily etc/disktab etc/hoststated.conf etc/magic etc/monthly etc/netstart etc/rc etc/rc.conf etc/ripd.conf etc/sasyncd.conf etc/security etc/weekly etc/mail/Makefile etc/mail/localhost.cf etc/mail/sendmail.cf etc/mail/submit.cf etc/mail/spamd.conf etc/mtree/* var/www/conf/bgplg.css var/www/conf/bgplg.foot var/www/conf/bgplg.head var/www/htdocs/bgplg/*

Notez qu'il EST possible de modifier ces fichiers localement, si ceci a été fait, une fusion manuelle pourrait être nécessaire. Faites attention aux fichiers présents dans le dossier mail/* si vous utilisez une configuration Sendmail(8) différente de celle par défaut. Voici les lignes copiées/collées pour copier ces fichiers, à la condition que vous ayez extrait etc41.tgz dans le répertoire conseillé ci-dessus :

cd /tmp/etc cp daily disktab hoststated.conf magic monthly netstart rc rc.conf ripd.conf sasyncd.conf security weekly /etc cp mtree/* /etc/mtree/ cp mail/Makefile mail/localhost.cf mail/submit.cf /etc/mail cp mail/sendmail.cf /etc/mail # Faire attention pour cette commande !! cp mail/spamd.conf /etc/mail # ou... mv /etc/spamd.conf /etc/mail cd /tmp/var/www cp conf/bgplg.css conf/bgplg.foot conf/bgplg.head /var/www/conf mkdir /var/www/htdocs/bgplg cp htdocs/bgplg/* /var/www/htdocs/bgplg/

Fichiers devant être fusionnés manuellement, en respectant tout changement local effectué sur ceux-ci s'ils ont été modifiés par rapport à la configuration par défaut ; sinon, copiez-les simplement :

etc/changelist etc/ftpusers etc/login.conf etc/newsyslog.conf etc/services etc/sysctl.conf etc/mail/aliases var/cron/tabs/root

Les modifications effectuées sur ces fichiers se trouvent dans le fichier "patch". Vous pouvez essayer de l'utiliser en exécutant la commande suivante avec les privilèges root :

cd / patch -C -p0 < upgrade41.patch

Ceci aura pour effet de tester le "patch" pour voir s'il s'applique bien à VOTRE système. Pour l'appliquer, supprimez l'option "-C" de la commande précédente. Si vous avez effectué des modifications locales sur ces fichiers ou si vous ne les avez pas gardées aussi à jour que possible par rapport aux versions officielles, ou si vous effectuez la mise à jour depuis un snapshot de la version 3.9, il se peut que le "patch" ne passe pas correctement. Vous devriez alors intervenir manuellement. Merci de bien vouloir tester ce procédé avant de vous y fier pour une machine à laquelle vous ne pouvez pas avoir accès facilement.

Les fichiers suivants contiennent des modifications à considérer. Cependant, une copie ou une comparaison sont peu probables (dans le cas de pf.conf par exemple, considérez les changements de stratégie s'il y a lieu et déterminez si ces changements sont adaptés à votre utilisation).

etc/hostapd.conf etc/pf.conf etc/sensorsd.conf

Enfin, utilisez newaliases(8) afin de mettre à jour la base des aliases puis mtree(8) pour créer les nouveaux répertoires :

newaliases mtree -qdef /etc/mtree/4.4BSD.dist -p / -u

2. Vérification du noyau

Remarque : la plupart des gens peuvent sauter cette étape !

Si vous avez suivi les instructions de mise à niveau sans noyau d'installation vous aurez déjà accompli cette étape. En revanche, si vous utilisez le média d'installation et si vous aviez un noyau modifié en 4.0 il est probable que vous devriez modifier le noyau 4.1 de base. Cela peut être aussi simple que de modifier un périphérique spécifique avec config(8) ou il peut être nécessaire de recompiler le noyau si l'option que vous souhaitez n'est pas incluse dans le noyau GENERIC. Consultez la section FAQ 5 - Construire le Système à partir des Sources avant d'envisager une recompilation de votre noyau.

3. Mise à jour des paquetages

Si vous avez installé des paquetages sur votre machine vous devriez les mettre à jour après la mise à niveau de votre système de base. Attention cependant car de nombreux paquetages nécessiteront une manipulation supplémentaire avant et/ou après avoir été mis à jour. Référez-vous au guide de mise à niveau de l'application pour de plus amples informations.

Les paquetages suivants sont connus pour avoir certains problèmes lors de la mise à niveau pouvant impacter un grand nombre d'utilisateurs. Le fait qu'un paquetage ne soit pas listé ne signifie en rien que sa mise à jour sera aisée. Vous devez vous renseigner sur les applications que VOUS utilisez.

Postgresql : vous devez faire un dump de votre base de données avant la mise à niveau et la restaurer après.

Les utilitaires de gestion des paquetages ("pkg tools") supportent la mise à jour avec la commande pkg_add -u. Par exemple, pour mettre à jour tous vos paquetages, soyez certains que PKG_PATH pointe bien vers le répertoire contenant les paquetages 4.1 sur votre CD ou un miroir FTP proche et utilisez une commande du type

# pkg_add -ui -F update -F updatedepends

où -u indique le mode mise à jour et -i le mode interactif, ainsi pkg_add vous demandera ce que vous souhaitez faire lorsque celui-ci rencontrera une ambiguïté. Lisez le manuel de pkg_add(1) et le chapitre de la FAQ sur la gestion des paquetages pour de plus amples informations.