[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ suivant ]


Notes de publication pour Debian GNU/Linux 4.0 (« etch »), PA-RISC
Chapitre 4 - Mise à jour depuis les versions précédentes


4.1 Actions nécessaires avant la mise à niveau

Nous vous suggérons, avant la mise à niveau, de lire les informations de Problèmes à connaître pour etch, Chapitre 5. Ce chapitre couvre des problèmes potentiels non liés directement au processus de mise à niveau, mais qu'il pourrait être important de connaître avant de commencer.


4.1.1 Sauvegarder toutes les données et informations de configuration

Avant de mettre à niveau votre système, il est fortement conseillé de faire une sauvegarde complète ou, du moins, une sauvegarde des données et informations de configuration que vous ne pourriez pas vous permettre de perdre. Les outils de mise à niveau sont tout à fait fiables, mais une panne matérielle au milieu de la mise à niveau pourrait fortement endommager votre système.

Ce que vous voudrez principalement sauvegarder est le contenu des répertoires /etc et /var/lib/dpkg, du fichier /var/lib/aptitude/pkgstates et la sortie de dpkg --get-selections "*" (les guillemets sont importants).

Le processus de mise à niveau en lui-même ne modifie rien dans le répertoire /home. Cependant, certaines applications (par exemple, des parties de la suite Mozilla et les environnements de bureau GNOME et KDE) sont connues pour écraser des paramètres utilisateur existants avec de nouvelles valeurs par défaut quand une nouvelle version de l'application est lancée pour la première fois par un utilisateur. Comme précaution, vous pouvez vouloir faire une sauvegarde des fichiers et répertoires cachés (les « dotfiles ») dans les répertoires personnels des utilisateurs. Vous pouvez également informer les utilisateurs de ce problème.

Toutes les opérations d'installation de paquets doivent être exécutées avec les privilèges du superutilisateur, vous devez donc soit vous connecter en tant que root, soit utiliser su ou sudo pour obtenir les droits nécessaires.

Il existe quelques pré-requis à la mise à niveau ; vous devriez les vérifier avant d'effectuer réellement la mise à niveau.


4.1.2 Informer les utilisateurs à l'avance

Il est sage d'informer à l'avance tous les utilisateurs que vous planifiez une mise à niveau, bien que les utilisateurs accédant à votre système par connexion ssh ne devraient pas remarquer grand chose durant la mise à niveau et devraient pouvoir continuer à travailler.

Si vous voulez prendre des précautions supplémentaires, sauvegardez ou démontez la partition /home des comptes des utilisateurs avant la mise à niveau.

Vous devrez probablement faire une mise à jour du noyau lors de la mise à niveau vers etch, un redémarrage sera donc normalement nécessaire. Généralement, celui-ci devra être effectué après la fin de la mise à niveau.


4.1.3 Préparations pour une récupération

En raison des nombreux changements dans le noyau entre sarge et etch en ce qui concerne les pilotes, la détection matérielle et le nommage et l'ordre des fichiers de périphérique, il existe un risque réel que vous rencontriez des problèmes lors du redémarrage de votre système après la mise à niveau. Un grand nombre des problèmes potentiels sont documentés dans ce chapitre et les suivants de ces notes de publication.

Pour cette raison, il est raisonnable de s'assurer que vous pourrez faire une récupération si votre système échouait au redémarrage ou, pour les systèmes gérés à distance, échouait lors de la mise en place du réseau.

Si vous effectuez une mise à niveau à distance par un lien ssh, il est fortement recommandé de prendre toutes les précautions nécessaires pour pouvoir accéder au serveur par un terminal série distant. Il est possible qu'après la mise à jour du noyau et le redémarrage, les noms de quelques périphériques soient changés (comme décrit dans Réordonnement de l'énumération des périphériques, Section 4.6.3) et vous devrez corriger la configuration du système depuis une console locale. Par ailleurs, si le système est redémarré accidentellement au milieu de la mise à niveau, il est possible que vous deviez effectuer une récupération en utilisant une console locale.

L'action la plus évidente à tenter est de redémarrer sur votre ancien noyau. Cependant, pour diverses raisons expliquées ailleurs dans ce document, il n'est pas garanti que cela fonctionnera.

Si cela échoue, vous aurez besoin d'une méthode alternative pour amorcer votre système afin de pouvoir y accéder et de le réparer. Une option est d'utiliser une image de récupération spéciale ou un CD autonome Linux (« Live CD ») Après avoir démarré à partir de ce support, vous devriez pouvoir monter votre système de fichiers racine et effectuer un chroot dans celui-ci pour investiguer et corriger le problème.

Une autre option que nous vous recommandons est d'utiliser le mode de récupération (« rescue mode ) de l'installateur Debian d'etch. L'avantage d'utiliser l'installateur est que vous pouvez choisir entre ses nombreuses méthodes d'installation pour celle qui convient le mieux à votre situation. Pour plus d'informations, veuillez consulter la section « Réparer un système cassé » du chapitre 8 du manuel d'installation et la FAQ de l'installateur Debian.


4.1.3.1 Shell de débogage pendant l'amorçage utilisant un initrd

Le paquet initramfs-tools inclut un shell de débogage[5] dans les initrd qu'il génère. Si, par exemple, l'initrd ne peut pas monter votre système de fichiers racine, vous vous retrouverez dans ce shell de débogage qui a des commandes de base disponibles pour aider à tracer le problème et peut-être à le corriger.

Les points de base à vérifier sont : la présence de fichiers de périphérique corrects dans /dev ; quels modules sont chargés (cat /proc/modules) ; la sortie de dmesg pour des erreurs au chargement de pilotes. La sortie de dmesg affichera également quels fichiers de périphériques ont été assignés à quels disques  vous devriez vérifier cela par rapport à l'affichage de echo $ROOT pour vous assurer que le système de fichiers racine est sur le périphérique attendu.

Si vous parvenez à corriger le problème, entrer exit arrêtera le shell de débogage et continuera le processus d'amorçage au point où il avait échoué. Bien sûr, vous devrez également corriger le problème sous-jacent et régénérer l'initrd afin d'éviter un nouvel échec au prochain amorçage.


4.1.4 Préparer un environnement sain pour la mise à niveau

Vous devriez faire la mise à niveau de la distribution soit localement, à partir d'une console texte virtuelle ou d'un terminal série directement connecté, soit à distance via une connexion ssh.

Pour avoir une marge de sécurité supplémentaire lors des mises à jour à distance, nous vous suggérons d'exécuter les processus de mise à jour dans la console virtuelle fournie par le programme screen qui permet de se reconnecter en cas de coupure et garantit que le processus de mise à jour ne sera pas interrompu même si le processus de connexion à distance était coupé.

Important : vous ne devez pas effectuer la mise à niveau en utilisant telnet, rlogin, rsh, ou depuis une session X gérée par gdm, kdm, etc. sur la machine que vous mettez à niveau. En effet, chacun de ces services pourrait être interrompu pendant la mise à niveau, ce qui peut rendre inaccessible un système à moitié mis à niveau.


4.1.5 La prise en charge des noyaux 2.2 a été abandonnée

Si vous utilisez un noyau avant la version 2.4.1, vous devez le mettre à jour pour un noyau (au moins) de version 2.4 avant de faire la mise à jour du paquet glibc. Ceci devrait être fait avant de commencer la mise à niveau du système. Il est recommandé de faire directement une mise à jour du noyau vers la version 2.6.8 disponible dans sarge au lieu de faire simplement une mise à jour vers une version 2.4 du noyau.


4.2 Vérifier l'état du système

Le processus de mise à niveau décrit dans ce chapitre a été conçu pour des mises à niveau depuis des systèmes sarge « purs » sans paquet de tierce partie. En particulier, il y a des problèmes connus avec des paquets de tierce partie installant des programmes sous /usr/X11R6/bin/ qui entraînent des problèmes lors des mises à jour en raison de la transition X.org (voir Transition de XFree86 vers X.Org, Section 5.2). Pour une meilleure fiabilité du processus de mise à niveau, vous pouvez supprimer ces paquets de tierce partie de votre système avant de commencer la mise à niveau.

Cette procédure suppose également que votre système a été mis à jour jusqu'à la dernière révision de sarge. Si vous ne l'avez pas fait ou si vous n'en êtes pas certain, veuillez suivre les instructions de Mettre à niveau votre système sarge, Section A.1.


4.2.1 Vérifier les actions en cours dans le gestionnaire de paquets

Dans certains cas, l'utilisation d'apt-get pour l'installation de paquets au lieu d'aptitude peut induire aptitude à considérer un paquet comme « unused » (inutilisé) et à le programmer pour suppression. En général, vous devriez vous assurer que le système est complètement à jour et « propre » avant de commencer la mise à niveau.

À cause de cela, vous devez commencer par vérifier s'il y a des actions en cours dans le gestionnaire de paquets aptitude. Si un paquet est programmé pour être supprimé ou mis à jour dans le gestionnaire des paquets, cela peut poser problème lors de la procédure de mise à niveau. Notez que la correction de cela n'est possible que si votre fichier sources.list pointe encore vers sarge; et pas vers stable ou etch ; voir Vérifier votre liste de sources, Section A.2.

Pour faire cela, vous devez lancer l'interface graphique d'aptitude et appuyer sur 'g' (« Go »). S'il affiche une action, vous devez la contrôler et soit l'annuler ou la terminer. Si aucune action n'est suggérée, il vous sera présenté un message indiquant « No packages are scheduled to be installed, removed, or upgraded » (« Il n'est prévu d'installer, mettre à jour ou enlever aucun paquet »).


4.2.2 Désactiver l'étiquetage apt

Si vous avez configuré apt pour installer certains paquets d'une distribution autre que stable (par exemple, de testing), il se peut que vous deviez changer votre configuration d'étiquetage apt (« APT pinning ») (stockée dans /etc/apt/preferences) pour permettre la mise à jour de paquets vers les versions de la nouvelle version stable. Vous trouverez plus d'informations sur l'étiquetage apt dans apt_preferences(5).


4.2.3 Vérification de l'état des paquets

Quelle que soit la méthode utilisée pour mettre à niveau, il est recommandé de tester d'abord l'état de tous les paquets et de vérifier que tous les paquets se trouvent dans un état permettant la mise à niveau. La commande suivante vous indiquera tous les paquets qui sont dans l'état « Half-Installed » ou « Failed-Config », ainsi que ceux qui sont dans un état d'erreur :

     # dpkg --audit

Vous pouvez aussi vérifier l'état de tous les paquets de votre système en utilisant dselect, aptitude, ou avec des commandes comme :

     # dpkg -l | pager

ou :

     # dpkg --get-selections "*" > ~/paquets-actuels.txt

Il est souhaitable d'enlever tous les blocages de paquets (on hold) avant de passer à la nouvelle version. Si un paquet essentiel pour la mise à jour est bloqué, la mise à jour va échouer.

Notez qu'aptitude utilise une méthode différente pour enregistrer les paquets qui sont bloqués de celle d'apt-get et dselect. Vous pouvez identifier les paquets bloqués pour aptitude avec :

     # aptitude search "~ahold" | grep "^.h"

Si vous désirez vérifier quels paquets étaient bloqués pour apt-get, il vous faudra utiliser :

     # dpkg --get-selections | grep hold

Si vous aviez modifié et recompilé un paquet localement, sans changer son nom et sans mettre d'époque (« epoch ») dans la version, vous devez le bloquer pour éviter qu'il ne soit mis à niveau.

Vous pouvez activer un blocage sur un paquet pour aptitude en utilisant :

     # aptitude hold nom_du_paquet

Remplacez hold par unhold pour débloquer un paquet.

Si vous devez corriger quelque chose, il est préférable de vous assurer que votre sources.list fait toujours référence à sarge comme expliqué dans Vérifier votre liste de sources, Section A.2.


4.2.4 Sources non officielles et rétroportages

Si vous avez des paquets non-Debian sur votre système, vous devriez être conscient que ceux-ci peuvent être supprimés pendant la mise à niveau à cause de dépendances conflictuelles. Si ces paquets ont été installés par l'ajout d'une archive de paquets supplémentaire dans votre /etc/apt/sources.list, vous devriez vérifier si cette archive propose également des paquets compilés pour etch et changer la ligne de source en conséquence en même temps que vos lignes de source pour les paquets Debian.

Certains utilisateurs peuvent avoir installé sur leur système sarge des versions non officielles rétroportées de paquets plus récentes que celles qui sont dans Debian. De tels paquets sont les plus susceptibles de poser problème lors d'une mise à niveau car ils peuvent entraîner un conflit de fichiers[6]. La section Problèmes possibles pendant une mise à niveau, Section 4.5.8 contient des informations sur la façon de gérer des conflits de fichiers s'ils se produisent.


4.3 Démarquer manuellement certains paquets

Pour empêcher aptitude de retirer certains paquets qui étaient installés grâce à des dépendances, vous devez les démarquer manuellement des paquets auto (automatiquement installés). Cela inclut OpenOffice et Vim pour les installations de bureau :

     # aptitude unmarkauto openoffice.org vim

et les images de noyau 2.6 si vous les avez installées en utilisant un méta-paquet de noyau :

     # aptitude unmarkauto $(dpkg-query -W 'kernel-image-2.6.*' | cut -f1)

Note : vous pouvez vérifier quels paquets sont marqués comme auto dans aptitude en exécutant :

     # aptitude search 'i~M <package name>'

4.4 Préparer les sources d'apt

Avant de commencer la mise à niveau, vous devez ajuster le fichier de configuration des listes de paquets d'apt, /etc/apt/sources.list.

Apt prendra en compte tout paquet qui peut être trouvé par chacune des lignes « deb » et installera le paquet ayant le numéro de version le plus élevé, en donnant la priorité aux premières lignes mentionnées (ainsi, dans le cas de plusieurs miroirs Debian, on indiquera d'abord un disque dur local, puis des cédéroms, puis les miroirs FTP et HTTP).

Une version peut souvent être référencée à la fois par son nom de code (par exemple, sarge, etch) et par son nom d'état (c.-à-d. oldstable, stable, testing, unstable). Se référer à une version par son nom de code a l'avantage que vous ne serez jamais surpris par une nouvelle version et c'est pour cette raison que cette approche est choisie ici. Cela veut évidemment dire que vous devrez surveiller vous-même les annonces des nouvelles versions. Si vous utilisez à la place les noms d'état, vous verrez simplement une grande quantité de mises à jour de paquets disponibles dès qu'une publication aura lieu.


4.4.1 Ajouter des sources Internet à apt

La configuration par défaut est faite pour une installation depuis les principaux serveurs de Debian sur Internet, mais vous pouvez modifier /etc/apt/sources.list pour utiliser d'autres miroirs, de préférence plus proches de vous au sens réseau du terme.

Les adresses des miroirs Debian HTTP et FTP se trouvent à http://www.debian.org/distrib/ftplist (regardez dans la section « liste complète des miroirs » — Full list of mirrors). Les miroirs HTTP sont en général plus rapides que les miroirs FTP.

Par exemple, supposons que votre miroir Debian le plus proche est http://mirrors.kernel.org/debian/. Si vous regardez ce miroir avec un navigateur web ou FTP, vous verrez que les répertoires principaux sont organisés comme ceci :

     http://mirrors.kernel.org/debian/dists/etch/main/binary-hppa/...
     http://mirrors.kernel.org/debian/dists/etch/contrib/binary-hppa/...

Pour utiliser ce miroir avec apt, vous ajoutez cette ligne à votre fichier sources.list :

     deb http://mirrors.kernel.org/debian etch main contrib

Notez que « dists » est ajouté implicitement, et les paramètres qui suivent le nom de version sont utilisés pour étendre le chemin à plusieurs répertoires.

Après avoir ajouté les nouvelles sources, commentez les lignes « deb » existantes dans le fichier sources.list en plaçant des signes # au début des lignes.


4.4.2 Ajouter des sources d'un miroir local à apt

Plutôt que d'utiliser des miroirs de paquets HTTP ou FTP, vous pouvez modifier /etc/apt/sources.list pour utiliser un miroir sur un disque local (éventuellement monté par NFS).

Par exemple, votre miroir de paquets peut être sous /var/ftp/debian/, et avoir des répertoires principaux tels que :

     /var/ftp/debian/dists/etch/main/binary-hppa/...
     /var/ftp/debian/dists/etch/contrib/binary-hppa/...

Pour utiliser ceci avec apt, ajoutez cette ligne à votre fichier sources.list :

     deb file:/var/ftp/debian etch main contrib

Notez que « dists » est ajouté implicitement, et les paramètres qui suivent le nom de version sont utilisés pour étendre le chemin à plusieurs répertoires.

Après avoir ajouté les nouvelles sources, commentez les lignes « deb » existantes dans le fichier sources.list en plaçant des signes # au début des lignes.


4.4.3 Ajouter des sources sur cédérom et dévédérom à apt

Si vous voulez utiliser seulement les cédéroms, commentez les lignes deb existantes dans le fichier sources.list en plaçant des # au début des lignes.

Assurez-vous de la présence d'une ligne dans /etc/fstab qui autorise le montage du cédérom au point de montage /cdrom (ce point de montage /cdrom est nécessaire pour utiliser apt-cdrom). Par exemple, si /dev/hdc est votre lecteur de cédérom, le fichier /etc/fstab devrait contenir une ligne comme celle-ci :

     /dev/hdc /cdrom auto defaults,noauto,ro 0 0

Remarquez qu'il ne doit pas y avoir d'espace entre les mots defaults,noauto,ro dans la quatrième colonne.

Pour vérifier que cela fonctionne, insérez un cédérom et essayez d'exécuter :

     # mount /cdrom       # montera le cédérom au point de montage /cdrom
     # ls -alF /cdrom     # devrait afficher le contenu de la racine du cédérom
     # umount /cdrom      # démontera le cédérom

Puis, lancez :

     # apt-cdrom add

pour chaque cédérom binaire Debian en votre possession, afin d'ajouter les données concernant chaque cédérom dans la base de données d'apt.


4.5 Paquets mis à jour

La façon recommandée pour faire une mise à niveau depuis des versions précédentes de Debian GNU/Linux est d'utiliser le gestionnaire de paquets aptitude. Ce programme prend des décisions plus sûres pour l'installation des paquets qu'apt-get.

N'oubliez pas de monter les partitions requises (notamment les partitions racine et /usr) en lecture et écriture, avec une commande de ce type :

     # mount -o remount,rw /point_de_montage

Puis, revérifiez que les entrées de source apt (dans /etc/apt/sources.list) se réfèrent soit à « etch » soit à « stable ». Il ne devrait y avoir aucune source pointant vers sarge. Note : les lignes de source pour un cédérom se réfèrent souvent à « unstable » ; bien que cela soit trompeur, vous ne devriez pas les changer.


4.5.1 Enregistrer la session

Il est fortement recommandé d'utiliser le programme /usr/bin/script pour enregistrer une transcription de la session de mise à niveau. Ainsi, si un problème se produit, vous aurez un enregistrement de ce qui s'est produit, et vous pourrez fournir, s'il le faut, les informations exactes pour un rapport de bogue. Pour démarrer un enregistrement, tapez :

     # script -t -a  2>~/mise-a-niveau-etch.time ~/mise-a-niveau-etch.typescript

ou équivalent. Souvenez-vous de ne pas mettre le fichier d'enregistrement dans un répertoire temporaire tel que /tmp ou /var/tmp (les fichiers de ces répertoires peuvent être détruits pendant la mise à niveau ou pendant un redémarrage).

Le fichier d'enregistrement vous permettra également de revoir les informations qui ont défilé hors de l'écran. Basculez simplement sur la deuxième console (en utilisant Alt-F2) et, après la connexion, utilisez less -R ~root/mise-a-niveau-etch.typescript pour voir le fichier.

Après avoir terminé la mise à niveau, vous pouvez stopper l'enregistrement en entrant exit à l'invite de commandes.

Si vous avez utilisé l'option -t pour script, vous pouvez utiliser le programme scriptreplay pour rejouer la session entière :

     # scriptreplay ~/mise-a-niveau-etch.time 2>~/mise-a-niveau-etch.typescript

4.5.2 Mettre à jour la liste des paquets

La liste des paquets disponibles pour la nouvelle version doit tout d'abord être récupérée. Cela est réalisé en exécutant :

     # aptitude update

La première fois que cette commande est exécutée, les nouvelles sources afficheront des avertissements liés à la disponibilité des sources. Ces avertissements sont anodins et ne réapparaîtront pas si vous exécutez à nouveau la commande.


4.5.3 Assurez-vous d'avoir suffisamment d'espace disque pour la mise à niveau

Vous devez vous assurer avant de faire la mise à niveau de votre système que vous avez suffisamment d'espace disque comme décrit dans Mettre à jour le reste du système, Section 4.5.6. Tout d'abord, tous les paquets nécessaires à l'installation récupérés du réseau sont stockés dans /var/cache/apt/archives (et dans le sous-répertoire partial/ pendant le téléchargement), vous devez donc vous assurer d'avoir suffisamment de place sur la partition du système de fichiers contenant /var/ pour télécharger les paquets qui seront installés sur votre système. Après le téléchargement, vous aurez probablement encore besoin de plus d'espace disque sur les autres partitions de système de fichiers pour pouvoir installer à la fois les paquets mis à jour (qui peuvent contenir des binaires plus gros ou davantage de données) et les nouveaux paquets qui sont tirés par la mise à niveau. Si votre système ne dispose pas de suffisamment d'espace disque, il se peut que vous vous retrouviez avec une mise à niveau incomplète qui pourrait être délicate à récupérer.

Les programmes aptitude et apt peuvent vous afficher des informations détaillées sur l'espace disque nécessaire pour l'installation. Vous pouvez voir cette estimation avant d'effectuer la vraie mise à niveau avec la commande :

     # aptitude -y -s -f --with-recommends dist-upgrade
     [ ... ]
     XXX paquets mis à jour, XXX nouvellement installés, XXX à enlever et XXX non mis à jour.
     Il est nécessaire de télécharger xx,xMo d'archives. Après dépaquetage, AAAMo seront utilisés.
     Charger/installer/enlever des paquets.

[7]

Si vous n'avez pas assez d'espace disque pour la mise à niveau, assurez-vous de libérer assez d'espace disque auparavant. Vous pouvez :


4.5.4 Mise à niveau minimale du système

En raison de certains conflits de paquets nécessaires entre sarge et etch, exécuter aptitude dist-upgrade directement va souvent supprimer un grand nombre de paquets que vous voulez garder. C'est pourquoi nous recommandons un processus de mise à niveau en deux étapes, tout d'abord une mise à niveau minimale pour résoudre ces conflits, puis un dist-upgrade complet.

Exécutez en premier

     # aptitude upgrade

Cela a pour effet de mettre à jour les paquets qui peuvent l'être sans nécessiter que d'autres paquets soient supprimés ou installés.

Puis, continuez la mise à niveau minimale avec :

     # aptitude install initrd-tools

Cette étape va mettre automatiquement à jour les paquets libc6 et locales et va installer les bibliothèques de prise en charge de SELinux (libselinux1). À ce moment, certains services en fonctionnement seront redémarrés, comprenant xdm, gdm et kdm. En conséquence, les sessions locales X seront déconnectées.

L'étape suivante est variable selon l'ensemble de paquets que vous avez installé. Ces notes de publication donnent des conseils généraux sur la méthode à utiliser, mais en cas de doute, il est recommandé d'examiner les suppressions de paquets proposées par chacune des méthodes avant de les effectuer réellement.

Certains paquets courants qui devraient être supprimés incluent base-config, hotplug, xlibs, netkit-inetd, python2.3, xfree86-common, et xserver-common. Pour une liste plus complète des paquets obsolètes dans etch, voir Paquets obsolètes, Section 4.10.


4.5.4.1 Mettre à niveau un système de bureau

Ce chemin de mise à niveau a été vérifié pour fonctionner sur des systèmes avec la tâche desktop de sarge installée. Il s'agit probablement de la méthode qui donne les meilleurs résultats sur les systèmes avec la tâche desktop installée ou avec les paquets gnome ou kde installés.

Ce n'est probablement pas la bonne méthode à utiliser si vous n'avez pas déjà les paquets libfam0c102 et xlibmesa-glu d'installés :

     # dpkg -l libfam0c102 | grep ^ii
     # dpkg -l xlibmesa-glu | grep ^ii

Si vous avez un système de bureau complet, exécutez :

     # aptitude install libfam0 xlibmesa-glu

4.5.4.2 Mise à niveau d'un système avec certains paquets X installés

Les systèmes avec certains paquets X installés, mais pas la tâche desktop complète, nécessitent une méthode différente. Cette méthode s'applique en général aux systèmes avec le paquet xfree86-common installé, y compris certains systèmes serveur ayant les tâches serveur du paquet tasksel installés car certaines de ces tâches incluent des outils de gestion graphiques. Il s'agit probablement de la bonne méthode à utiliser sur les systèmes faisant fonctionner X, mais n'ayant pas la tâche desktop complète d'installée.

     # dpkg -l xfree86-common | grep ^ii

En premier, vérifiez si vous avez les paquets libfam0c102 et xlibmesa-glu d'installés.

     # dpkg -l libfam0c102 | grep ^ii
     # dpkg -l xlibmesa-glu | grep ^ii

Si vous n'avez pas le paquet libfam0c102 d'installé, n'incluez pas le paquet libfam0 dans la ligne de commande suivante. Si vous n'avez pas le paquet xlibmesa-glu d'installé, ne l'incluez pas dans la ligne de commande suivante. [8]

     # aptitude install x11-common libfam0 xlibmesa-glu

Notez que l'installation du paquet libfam0 installera également « File Alteration Monitor » (fam) ainsi que le « RPC portmapper » (portmap) s'ils ne sont pas déjà disponibles sur votre système. Chacun de ces paquets activera un nouveau service réseau sur votre système bien qu'ils puissent tous deux être configurés pour n'être lié qu'avec le périphérique réseau de bouclage (interne).


4.5.4.3 Mise à niveau d'un système sans prise en charge de X installée

Sur un système sans X, aucune commande aptitude install supplémentaire ne devrait être nécessaire et vous pouvez passer à l'étape suivante.


4.5.5 Mettre à jour le noyau

La version du paquet udev dans etch ne gère pas les versions de noyau avant 2.6.15 (ce qui inclut les noyaux 2.6.8 de sarge) et la version du paquet udev dans sarge ne fonctionnera pas correctement avec des noyaux récents. De plus, l'installation de la version du paquet udev d'etch va forcer la suppression du paquet hotplug utilisé par les noyaux Linux 2.4.

En conséquence, le paquet de noyau précédent ne démarrera probablement pas correctement après cette mise à jour. De façon similaire, il existe une fenêtre de temps au cours de laquelle udev est mis à jour, mais pas le dernier noyau. Si le système était redémarré à ce moment, au milieu de la mise à jour, il pourra ne pas être amorçable à cause de pilotes qui ne seraient pas détectés et chargés correctement (voir Préparer un environnement sain pour la mise à niveau, Section 4.1.4 pour des recommandations sur la préparation à cette possibilité si vous effectuez une mise à niveau à distance).

Sauf si votre système a la tâche desktop d'installée ou d'autres paquets qui entraîneraient des suppressions d'un nombre inacceptable de paquets, il est donc recommandé de mettre à jour le noyau à ce moment.

Pour effectuer cette mise à jour du noyau, exécutez :

     # aptitude install linux-image-2.6-variante

Voir Installer un méta-paquet de noyau, Section 4.6.1 pour de l'aide sur la détermination de la variante du paquet de noyau que vous devriez installer.

Pour les systèmes de bureau, il est malheureusement impossible de garantir que le nouveau paquet de noyau soit installé immédiatement après l'installation de la nouvelle version d'udev, il existe donc un intervalle de temps de durée inconnue pendant lequel votre système n'aura pas de noyau installé ayant une prise en charge hotplug complète. Voir Mettre à jour le noyau et les paquets liés, Section 4.6 pour plus d'informations sur la configuration de votre système pour qu'il ne dépende pas de hotplug au démarrage.


4.5.6 Mettre à jour le reste du système

Vous êtes maintenant prêt à continuer avec la partie principale de la mise à niveau. Exécutez :

     # aptitude dist-upgrade

Ceci effectuera une mise à jour complète du système, c.-à-d. installera les versions les plus récentes de tous les paquets, et résoudra tous les changements possibles de dépendances entre paquets des différentes versions. Si nécessaire, cela installera de nouveaux paquets (habituellement de nouvelles versions de bibliothèques, ou des paquets ayant changé de nom), et retirera les paquets obsolètes en conflit.

Lorsque la mise à jour se fait à partir d'un ensemble de cédéroms, on vous demandera d'insérer d'autres cédéroms à plusieurs moments de la mise à niveau. Vous pourriez devoir insérer plusieurs fois le même cédérom. Cela est dû aux relations entre paquets répartis sur plusieurs cédéroms.

Les paquets déjà installés ayant une nouvelle version, mais qui ne peuvent être installés sans modifier l'état d'un autre paquet, seront laissés dans leur version actuelle (et affichés comme retenu — held back). Cela peut être résolu soit en utilisant aptitude et en choisissant d'installer ces paquets, soit en essayant aptitude -f install paquet.


4.5.7 Récupérer les signatures de paquets

Après la mise à niveau, avec la nouvelle version d'apt, vous pouvez maintenant mettre à jour les informations des paquets, ce qui inclut le nouveau mécanisme de vérification des signatures des paquets :

     # aptitude update

La mise à niveau aura déjà récupéré et activé les clés de signature pour les archives de paquets Debian. Si vous ajoutez d'autres sources de paquets (non officielles), apt affichera des avertissements liés à son incapacité à vérifier que les paquets téléchargés depuis celles-ci sont légitimes et n'ont pas été altérés. Pour plus d'informations, veuillez voir Gestion de paquets, Section 2.1.1.

Vous pourrez remarquer que, comme vous utilisez la nouvelle version d'apt, il téléchargera des fichiers de différences de paquets (pdiff) au lieu de la liste complète des index de paquets. Pour plus d'information sur cette fonctionnalité, veuillez voir Téléchargements plus lents des fichiers d'index de paquets APT, Section 5.1.3.


4.5.8 Problèmes possibles pendant une mise à niveau

Si une opération utilisant aptitude, apt-get ou dpkg échoue avec l'erreur suivante :

     E: Dynamic MMap ran out of room

l'espace de cache par défaut est insuffisant. Vous pouvez résoudre cela soit en enlevant ou en commentant des lignes dont vous n'avez pas besoin dans /etc/apt/sources.list, soit en augmentant la taille du cache. La taille du cache peut être augmentée en positionnant APT::Cache-Limit dans /etc/apt/apt.conf. La commande suivante le positionne à une valeur qui devrait être suffisante pour la mise à niveau :

     # echo 'APT::Cache-Limit "12500000";' >> /etc/apt/apt.conf

Cela suppose que vous n'avez pas déjà positionné cette variable dans ce fichier.

Il est parfois nécessaire d'activer l'option d'apt APT::Force-LoopBreak pour pouvoir temporairement retirer un paquet essentiel à cause de boucles « Conflicts/Pre-Depends ». Aptitude vous alertera à ce propos et interrompra la mise à niveau. Vous pouvez contourner ce problème en passant l'option -o APT::Force-LoopBreak=1 sur la ligne de commande d'aptitude.

Il est possible que la structure de dépendances d'un système soit tellement défectueuse qu'elle requiert une intervention manuelle. Habituellement, cela signifie qu'il faut utiliser aptitude ou :

     # dpkg --remove nom_du_paquet

pour éliminer certains des paquets en cause, ou :

     # aptitude -f install
     # dpkg --configure --pending

Dans certains cas extrêmes, vous pourriez devoir forcer une réinstallation à l'aide d'une commande comme :

     # dpkg --install /chemin/vers/nom_du_paquet.deb

Les conflits de fichiers ne devraient pas se produire si vous mettez à niveau depuis un système sarge « pur », mais ils peuvent se produire si vous avez des rétroportages non officiels d'installés. Un conflit de fichiers entraînera une erreur de ce type :

     Préparation du remplacement de <paquet-toto> (en utilisant <fichier-paquet-toto>) ...
     dpkg: erreur de traitement de <paquet-toto> (--install):
      tentative de remplacement de « <un-nom-de-fichier> »,
      qui appartient aussi au paquet <paquet-titi>
     dpkg-deb: sous-processus paste tué par le signal (Broken pipe)
      Des erreurs ont été rencontrées pendant l'exécution :
      <paquet-toto>

Vous pouvez tenter de résoudre un conflit de fichiers en forçant la suppression du paquet mentionné sur la dernière ligne du message d'erreur :

     # dpkg -r --force-depends nom_du_paquet

Après cela, vous devriez être en mesure de continuer la mise à niveau, en utilisant les commandes d'aptitude précédemment décrites.

Durant la mise à niveau, on vous posera des questions pour configurer ou reconfigurer de nombreux paquets. Quand on vous demandera si des fichiers des répertoires /etc/init.d ou /etc/terminfo ou le fichier /etc/manpath.config doivent être remplacés par la version du responsable du paquet, il est généralement nécessaire de répondre « oui » pour assurer la cohérence du système. Vous pouvez toujours revenir aux versions précédentes, puisqu'elles sont sauvegardées avec une extension .dpkg-old.

Si vous n'êtes pas certain de ce qu'il faut faire, notez le nom du paquet ou du fichier et examinez le problème plus tard. Vous pouvez chercher dans le fichier d'enregistrement pour revoir les informations qui étaient à l'écran lors de la mise à niveau.


4.6 Mettre à jour le noyau et les paquets liés

Cette section explique comment mettre à jour votre noyau et identifie des problèmes potentiels liés à cette mise à jour. Vous pouvez soit installer l'un des paquets linux-image-* fournis dans Debian ou compiler un noyau personnalisé à partir des sources.

Veuillez noter que beaucoup d'informations dans cette section sont basées sur l'hypothèse que vous utilisez l'un des noyaux modulaires de Debian, avec les paquets initramfs-tools et udev. Si vous choisissez d'utiliser un noyau personnalisé qui ne nécessite pas d'initrd ou si vous utilisez un générateur d'initrd différent, certaines informations peuvent ne pas vous concerner.

Veuillez noter que si udev n'est pas installé sur votre système, il est toujours possible d'utiliser hotplug pour la détection matérielle.


4.6.1 Installer un méta-paquet de noyau

Quand vous faites une mise à niveau de sarge vers etch, il est fortement recommandé d'installer un nouveau méta-paquet linux-image-2.6-*. Ce paquet peut être installé automatiquement par le processus de mise à niveau. Vous pouvez vérifier cela en exécutant :

     # dpkg -l "linux-image*" | grep ^ii

Si cela n'affiche rien, vous devrez alors installer un paquet linux-image manuellement. Pour voir la liste des méta-paquets linux-image-2.6 disponibles, exécutez :

     # apt-cache search linux-image-2.6- | grep -v transition

Si vous ne savez pas quel paquet sélectionner, exécutez uname -r et recherchez un paquet avec un nom similaire. Par exemple, si vous voyez « 2.4.27-3-686 », il est recommandé d'installer linux-image-2.6-686. Vous pouvez également utiliser apt-cache pour voir une description longue de chaque paquet pour vous aider à choisir le meilleur disponible. Par exemple :

     # apt-cache show linux-image-2.6-686

Vous pouvez alors installer le paquet choisi en utilisant la commande aptitude install. Une fois ce nouveau noyau installé, vous devriez redémarrer dès que possible afin de profiter des améliorations fournies par la nouvelle version du noyau.

Pour les plus aventureux, il existe un moyen facile de compiler votre propre noyau sur Debian GNU/Linux. Installez le paquet kernel-package et lisez la documentation dans /usr/share/doc/kernel-package.


4.6.2 Mettre à jour depuis un noyau 2.6

Si vous utilisez actuellement un noyau de la série 2.6 de sarge, cette mise à jour aura lieu automatiquement après la mise à niveau complète des paquets du système (comme décrit dans Paquets mis à jour, Section 4.5).

Si possible, vous devriez mettre à jour le paquet de noyau séparément de la mise à niveau (dist-upgrade) principale pour réduire les risques d'avoir un système temporairement non amorçable. Voir Mettre à jour le noyau, Section 4.5.5 pour une description de ce processus. Notez que cela devrait être effectué uniquement après le processus de mise à niveau minimal décrit dans Mise à niveau minimale du système, Section 4.5.4.

Vous pouvez également procéder à cette étape si vous utilisez votre propre noyau personnalisé et que vous voulez utiliser le noyau disponible dans etch. Si votre version de noyau n'est pas prise en charge par udev, il vous est alors recommandé de le mettre à jour après la mise à niveau minimale. Si votre version est gérée par udev, vous pouvez sans inconvénient attendre d'avoir effectué la mise à niveau complète avant de faire la mise à jour du noyau.


4.6.3 Réordonnement de l'énumération des périphériques

etch inclut un mécanisme plus robuste de découverte du matériel que dans les versions précédentes. Cependant, ceci peut entraîner des changements dans l'ordre dans lequel les périphériques sont découverts sur votre système, ce qui peut modifier l'ordre dans lequel sont assignés les noms de périphériques. Par exemple, si vous avez des cartes réseau qui sont associées à deux pilotes différents, les périphériques auxquels eth0 et eth1 se réfèrent peuvent être inversés. Veuillez noter que le nouveau mécanisme implique que si, par exemple, vous changez des cartes réseau dans un système fonctionnant sous etch, le nouvel adaptateur recevra également un nouveau nom d'interface.

Pour les périphériques réseau, vous pouvez éviter ce réordonnement en utilisant des règles udev, plus spécifiquement, par les définitions dans /etc/udev/rules.d/z25_persistent-net.rules[9]. Vous pouvez également utiliser l'utilitaire ifrename pour associer des périphériques physiques à des noms spécifiques lors du démarrage. Voir ifrename(8) et iftab(5) pour plus d'informations. Les deux alternatives (udev et ifrename) ne doivent pas être utilisées en même temps.

Pour les périphériques de stockage, vous pouvez éviter ce réordonnement en utilisant initramfs-tools et en le configurant pour charger les modules des pilotes des périphériques de stockage dans le même ordre que celui dans lequel ils ont été actuellement chargés. Pour faire cela, identifiez l'ordre dans lequel les modules de stockage ont été chargés sur votre système en observant l'affichage de lsmod. lsmod liste les modules dans l'ordre inverse de celui dans lequel ils ont été chargés, c.-à-d., le premier module de la liste est le dernier module chargé. Veuillez noter que cela ne fonctionne que pour les périphériques que le noyau énumère dans un ordre stable (comme les périphériques PCI).

Cependant, supprimer et recharger des modules après le démarrage initial peut modifier cet ordre. Votre noyau peut également avoir certains pilotes liés statiquement et ces noms n'apparaîtront pas dans l'affichage de lsmod. Vous pouvez essayer de deviner le nom de ces pilotes et l'ordre de chargement en étudiant /var/log/kern.log ou l'affichage de dmesg.

Ajoutez ces noms de modules au fichier /etc/initramfs-tools/modules dans l'ordre dans lequel ils ont été chargés au démarrage. Certains noms de modules ont pu changer entre sarge et etch. Par exemple, sym53c8xx_2 est devenu sym53c8xx.

Vous devrez ensuite régénérer votre image initramfs en exécutant update-initramfs -u -k all.

Une fois que vous utilisez un noyau d'etch et udev, vous pouvez reconfigurer votre système pour accéder aux disques par un alias indépendant de l'ordre de chargement des pilotes. Ces alias résident dans la hiérarchie /dev/disk/.


4.6.4 Problèmes de minutage lors de l'amorçage

Si un initrd créé avec initramfs-tools est utilisé pour amorcer le système, dans certains cas, la création des fichiers de périphérique par udev peut se produire trop tard pour que les scripts d'amorçage puissent en tenir compte.

Les symptômes habituels sont que l'amorçage échouera car le système de fichiers racine ne pourra pas être monté et vous serez placé dans un shell de débogage, mais quand vous le vérifiez par la suite, tous les périphériques nécessaires seront présents dans /dev. Cela a été observé dans des cas où le système de fichiers racine est sur un disque USB ou sur du RAID, en particulier si lilo est utilisé.

Un contournement à ce problème est d'utiliser le paramètre d'amorçage rootdelay=9. Il se peut que vous deviez ajuster la valeur pour le délai (en seconde).


4.7 Choses à faire avant le prochain redémarrage

Lorsque aptitude dist-upgrade est terminé, la mise à niveau « formelle » est terminée, mais il reste quelques petites choses dont vous devriez vous occuper avant le prochain redémarrage.


4.7.1 Conversion depuis devfs

Les noyaux Debian n'incluent plus de prise en charge pour devfs, les utilisateurs de devfs doivent donc convertir leur système manuellement avant d'amorcer un noyau d'etch.

Si vous trouvez la chaîne « devfs » dans /proc/mounts, il est très probable que vous utilisez devfs. Tous les fichiers de configuration référençant des noms de style devfs devront être ajustés pour utiliser les noms de style udev. Les fichiers susceptibles de se référer à des noms de périphériques de style devfs incluent /etc/fstab, /etc/lilo.conf, /boot/grub/menu.lst et /etc/inittab.

Vous pouvez trouver plus d'informations sur ces problèmes potentiels dans le rapport de bogue 341152.


4.7.2 Pilotes peut-être absents de l'initrd

Les noyaux d'etch n'incluent pas encore une prise en charge complète de sysfs pour le bus HP natif. Le paquet initramfs-tools s'appuie sur ceci pour inclure des pilotes pour les contrôleurs de disque dans l'initrd. Si un pilote n'est pas inclus dans l'initrd, votre système peut échouer lors du démarrage.

Si votre système utilise le module lasi700, le module 53c700 ou le module zalon7xx pour accéder à vos disques durs, vous devrez inclure ce module dans /etc/initramfs-tools/modules et régénérer l'initrd avant de redémarrer votre système. L'initrd peut être régénéré avec :

     # update-initramfs -u -k all

4.7.3 Mise à jour de mdadm

mdadm a maintenant besoin d'un fichier de configuration pour assembler des tables MD (RAID) à partir du « ramdisk » initial. Veuillez vous assurer de lire et de suivre les instructions dans /usr/share/doc/mdadm/README.upgrading-2.5.3.gz après la mise à jour du paquet et avant le redémarrage. La dernière version de ce fichier est disponible à http://svn.debian.org/wsvn/pkg-mdadm/mdadm/trunk/debian/README.upgrading-2.5.3?op=file ; veuillez la consulter en cas de problème.


4.8 Préparations pour la prochaine version

Après la mise à niveau, il y a plusieurs choses que vous pouvez faire pour préparer la prochaine version.


4.9 Paquets dépréciés

Avec la publication de Lenny, un nombre important de paquets serveurs seront dépréciés, c'est pourquoi mettre à jour dès à présent vers les versions plus récentes de ces paquets vous épargnera des soucis lors de la mise à jour vers Lenny.

Cela inclut les paquets suivants :


4.10 Paquets obsolètes

Avec l'introduction de plusieurs milliers de nouveaux paquets, etch marque également la fin et le retrait de plus de deux mille anciens paquets présents dans sarge. Il n'est pas prévu de chemin de mise à jour pour ces paquets obsolètes. Bien que rien ne vous empêche de continuer à utiliser ces paquets si vous le désirez, le projet Debian va habituellement stopper le support de sécurité pour ceux-ci un an après la sortie d'etch[10] et ne fournira normalement pas d'autre support entre temps. Il vous est recommandé de les remplacer par un logiciel alternatif, s'il en existe.

Il y a plusieurs raisons pour lesquelles un paquet peut avoir été retiré de la distribution : il n'est plus maintenu en amont, il n'y a plus de responsable Debian intéressé par la maintenance du paquet, la fonctionnalité fournie par le paquet a été remplacée par un logiciel différent (ou une nouvelle version) ou il n'est plus considéré comme convenable pour etch en raison de ses bogues. Dans ce dernier cas, le paquet peut cependant toujours être présent dans la distribution « unstable ».

Détecter quels paquets sont « obsolètes » dans un système mis à niveau est facile car les interfaces de gestion des paquets les marqueront comme tel. Si vous utilisez aptitude, vous verrez une liste de ces paquets sous l'entrée « Paquets obsolètes ou créés localement ». Dselect fournit une section similaire, mais la liste présentée peut être différente. Si vous avez utilisé aptitude pour installer des paquets manuellement dans sarge, le programme aura gardé la trace de ces paquets installés manuellement et pourra marquer comme obsolètes les paquets tirés par les seules dépendances et qui ne sont plus nécessaires si un paquet est supprimé. À la différence de deborphan, aptitude ne marquera pas comme obsolètes des paquets que vous avez installés manuellement, au contraire de ceux qui ont été installés automatiquement par les dépendances.

Il existe des outils supplémentaires que vous pouvez utiliser pour trouver les paquets obsolètes comme deborphan, debfoster ou cruft. Deborphan est hautement recommandé, bien qu'il n'indique (dans le mode par défaut) que les bibliothèques obsolètes : les paquets dans les sections « libs » ou « oldlibs » qui ne sont utilisés par aucun autre paquet. Ne supprimez pas aveuglément les paquets que ces outils présentent, particulièrement si vous utilisez des options non standard aggressives, car ils sont susceptibles de produire des faux positifs. Il est hautement recommandé d'examiner manuellement les paquets suggérés à la suppression (c.-à-d. leurs contenu, taille et description) avant de les supprimer.

Le système de suivi des bogues de Debian fournit souvent des informations supplémentaires sur les raisons pour lesquelles un paquet a été retiré. Vous devriez consulter à la fois les comptes-rendus de bogue archivés pour le paquet lui-même et ceux du pseudo-paquet ftp.debian.org.


4.10.1 Paquets factices

Certains paquets de sarge ont été divisés en plusieurs paquets dans etch, souvent pour améliorer la maintenabilité du système. Pour faciliter le chemin de mise à jour dans de tels cas, etch fournit souvent des paquets « factices » (« dummy packages » en anglais) : des paquets vides qui ont le même nom que l'ancien paquet de sarge avec des dépendances entraînant l'installation des nouveaux paquets. Ces paquets factices sont considérés comme des paquets obsolètes après la mise à jour et peuvent être supprimés sans problème.

La plupart (mais pas toutes) des descriptions des paquets factices indiquent leur but. Cependant, les descriptions des paquets factices ne sont pas uniformes, vous pourriez donc trouver que deborphan avec les options de type --guess-* sont utiles pour les détecter sur votre système. Notez que certains paquets factices ne sont pas destinés à être supprimés après une mise à jour, mais ils sont utilisés pour déterminer quelle est la version actuellement disponible d'un programme.


[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ suivant ]


Notes de publication pour Debian GNU/Linux 4.0 (« etch »), PA-RISC

$Id: release-notes.fr.sgml,v 1.75 2008-01-20 23:45:15 fbothamy Exp $

Josip Rodin, Bob Hilliard, Adam Di Carlo, Anne Bezemer, Rob Bradford, Frans Pop (actuel), Andreas Barth (actuel), Javier Fernández-Sanguino Peña (actuel), Steve Langasek (actuel)
debian-doc@lists.debian.org
Traduction : Denis Barbier, Frédéric Bothamy (actuel) et les membres de debian-l10n-french