Notes de publication pour Debian GNU/Linux 4.0 (« etch »), Alpha ---------------------------------------------------------------- Josip Rodin, Bob Hilliard, Adam Di Carlo, Anne Bezemer, Rob Bradford, Frans Pop (actuel), Andreas Barth (actuel), Javier Ferna'ndez-Sanguino Pen~a (actuel), Steve Langasek (actuel) Traduction : Denis Barbier, Frédéric Bothamy (actuel) et les membres de debian-l10n-french $Id: release-notes.fr.sgml,v 1.75 2008/01/20 23:45:15 fbothamy Exp $ ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- Table des matières ------------------ 1. Introduction 1.1. Signaler des bogues sur ce document 1.2. Fournir des comptes-rendus de mise à niveau 1.3. Sources de ce document 2. Nouveautés de Debian GNU/Linux 4.0 2.1. Quoi de neuf dans la distribution ? 2.1.1. Gestion de paquets 2.1.2. Secure APT 2.1.3. debian-volatile est maintenant un service officiel 2.2. Améliorations du système 2.3. Changements majeurs liés au noyau 2.3.1. Changements dans l'empaquetage du noyau 2.3.2. Nouveaux utilitaires pour générer les initrd 2.3.3. Gestion dynamique de `/dev' et détection matérielle 3. Système d'installation 3.1. Quoi de neuf dans le système d'installation ? 3.1.1. Changements majeurs 3.1.2. Installation automatisée 3.2. Concours de popularité 4. Mise à jour depuis les versions précédentes 4.1. Actions nécessaires avant la mise à niveau 4.1.1. Sauvegarder toutes les données et informations de configuration 4.1.2. Informer les utilisateurs à l'avance 4.1.3. Préparations pour une récupération 4.1.4. Préparer un environnement sain pour la mise à niveau 4.1.5. La prise en charge des noyaux 2.2 a été abandonnée 4.2. Vérifier l'état du système 4.2.1. Vérifier les actions en cours dans le gestionnaire de paquets 4.2.2. Désactiver l'étiquetage apt 4.2.3. Vérification de l'état des paquets 4.2.4. Sources non officielles et rétroportages 4.3. Démarquer manuellement certains paquets 4.4. Préparer les sources d'apt 4.4.1. Ajouter des sources Internet à apt 4.4.2. Ajouter des sources d'un miroir local à apt 4.4.3. Ajouter des sources sur cédérom et dévédérom à apt 4.5. Paquets mis à jour 4.5.1. Enregistrer la session 4.5.2. Mettre à jour la liste des paquets 4.5.3. Assurez-vous d'avoir suffisamment d'espace disque pour la mise à niveau 4.5.4. Mise à niveau minimale du système 4.5.5. Mettre à jour le noyau 4.5.6. Mettre à jour le reste du système 4.5.7. Récupérer les signatures de paquets 4.5.8. Problèmes possibles pendant une mise à niveau 4.6. Mettre à jour le noyau et les paquets liés 4.6.1. Installer un méta-paquet de noyau 4.6.2. Mettre à jour depuis un noyau 2.6 4.6.3. Mettre à jour depuis un noyau 2.4 4.6.4. Réordonnement de l'énumération des périphériques 4.6.5. Problèmes de minutage lors de l'amorçage 4.7. Choses à faire avant le prochain redémarrage 4.7.1. Conversion depuis devfs 4.7.2. Mise à jour de mdadm 4.8. Préparations pour la prochaine version 4.9. Paquets dépréciés 4.10. Paquets obsolètes 4.10.1. Paquets factices 5. Problèmes à connaître pour etch 5.1. Problèmes potentiels 5.1.1. Problèmes avec des périphériques liés à udev 5.1.2. Certaines applications peuvent ne plus fonctionner avec un noyau 2.4 5.1.3. Certains sites du réseau ne peuvent pas être joints par TCP 5.1.4. Téléchargements plus lents des fichiers d'index de paquets APT 5.1.5. L'initialisation asynchrone du réseau peut conduire à un comportement imprévisible 5.1.6. Problème lors de l'utilisation de réseau sans fil sécurisé par WPA 5.1.7. Problèmes avec les caractères non-ASCII dans les noms de fichier 5.1.8. Arrêt de fonctionnement du son 5.2. Mettre à jour vers un noyau 2.6 5.2.1. Configuration du clavier 5.2.2. Configuration de la souris 5.2.3. Configuration du son 5.3. Transition de XFree86 vers X.Org 5.4. Absence de prise en charge des affichages 8 bits dans de nombreuses applications 5.5. Mise à jour d'exim vers exim4 5.6. Mise à jour d'apache 5.7. Mise à jour de Zope et Plone 5.8. Expansion des caractères génériques (« globbing ») avec GNU tar 5.9. NIS et Network Manager 5.10. Les configurations PHP non sécurisées sont obsolètes 5.11. État de la sécurité des produits Mozilla 5.12. Bureau KDE 5.13. Changements et gestion du bureau GNOME 5.14. Éditeur par défaut 5.15. Message du jour 5.16. Pas de gestion par défaut pour l'Unicode dans emacs21* 6. Plus d'informations sur Debian GNU/Linux 6.1. Lectures pour aller plus loin 6.2. Obtenir de l'aide 6.2.1. Listes de diffusion 6.2.2. Chat (IRC) 6.3. Signaler les bogues 6.4. Contribuer à Debian A. Gérer votre système sarge A.1. Mettre à niveau votre système sarge A.2. Vérifier votre liste de sources ------------------------------------------------------------------------------- 1. Introduction --------------- Les principaux objectifs de ces notes de publication sont d'informer les utilisateurs des changements majeurs dans cette version de la distribution Debian GNU/Linux, de fournir des informations sur la façon d'effectuer une mise à niveau depuis la version précédente vers cette version et enfin d'informer les utilisateurs des problèmes potentiels qu'ils pourraient rencontrer pendant la mise à niveau ou lors de l'utilisation de la version etch. Veuillez noter qu'il est impossible de lister tous les problèmes connus et c'est pourquoi une sélection a été faite selon le nombre d'utilisateurs concernés et l'impact des problèmes. La version la plus récente de ce document est toujours disponible à http://www.debian.org/releases/stable/releasenotes. Si la version que vous lisez date de plus d'un mois[1], vous devriez peut-être télécharger la dernière version. Veuillez noter que nous ne supportons et documentons que les mises à jour depuis la précédente version de Debian (dans ce cas, la mise à jour depuis sarge). Si vous devez effectuer une mise à jour depuis une version antérieure, nous vous suggérons de lire les éditions précédentes de ces notes de publication et de commencer par faire une mise à jour vers sarge. [1] Tel qu'indiqué sur la première page de la version PDF et dans le pied-de-page de la version en ligne HTML. 1.1. Signaler des bogues sur ce document ---------------------------------------- Nous avons tenté de tester toutes les différentes étapes de mise à jour décrites dans ce document et nous avons essayé d'anticiper tous les problèmes potentiels que peuvent rencontrer nos utilisateurs. Cependant, si vous pensez avoir trouvé un bogue dans cette documentation (une information incorrecte ou manquante), merci de remplir un rapport de bogue dans le système de suivi des bogues (http://bugs.debian.org/) sur le paquet `release-notes'. 1.2. Fournir des comptes-rendus de mise à niveau ------------------------------------------------ Nous accueillons toutes les informations de nos utilisateurs liées aux mises à niveau depuis sarge vers etch. Si vous désirez partager des informations, veuillez créer un rapport de bogue dans le système de suivi des bogues (http://bugs.debian.org/) sur le paquet `upgrade-reports' avec vos résultats. Nous vous demandons de compresser tous les attachements inclus (en utilisant `gzip'). Veuillez fournir les informations suivantes lors de l'envoi de votre compte-rendu de mise à niveau : * l'état de votre base de données des paquets avant et après la mise à niveau : la base de données d'état de `dpkg' disponible à `/var/lib/dpkg/status' et les informations d'état des paquets d'`aptitude' disponibles à `/var/lib/aptitude/pkgstates'. Vous devriez en faire une sauvegarde avant la mise à niveau comme décrit dans Section 4.1.1, `Sauvegarder toutes les données et informations de configuration', mais vous pouvez également trouver des sauvegardes de ces informations dans `/var/backups'. * les fichiers journaux de session créés avec `script', comme décrit dans Section 4.5.1, `Enregistrer la session' ; * vos fichiers journaux d'`aptitude', disponibles dans `/var/log/aptitude'. Note : vous devriez prendre le temps de parcourir les fichiers journaux et de supprimer toute information sensible ou/et confidentielle avant de les inclure dans un rapport de bogue car ces informations seront publiées dans une base de données publique. 1.3. Sources de ce document --------------------------- Ce document utilise `debiandoc-sgml'. Les sources des notes de publication sont disponibles dans le dépôt CVS du _Projet de documentation Debian_. Vous pouvez utiliser l'interface web (http://cvs.debian.org/ddp/manuals.sgml/release-notes/?root=debian-doc) pour accéder aux fichiers individuellement par le web et pour voir les changements. Pour plus d'informations sur le moyen d'accéder au dépôt CVS, veuillez consulter les pages CVS du Projet de documentation Debian (http://www.debian.org/doc/cvs). ------------------------------------------------------------------------------- 2. Nouveautés de Debian GNU/Linux 4.0 ------------------------------------- Cette version ajoute la prise en charge officielle de l'architecture AMD64 qui fournit le support pour les processeurs 64 bits d'Intel (EM64T) et d'Amd (AMD64). Lors de la publication précédente, Debian GNU/Linux 3.1 (« Sarge »), une version non officielle de ce portage était disponible. La prise en charge officielle pour l'architecture Motorola 680x0 (« m68k ») a été abandonnée car elle ne répondait pas aux critères fixés par les responsables de publication Debian. Les plus importantes raisons pour ce retrait sont la faible performance et la prise en charge limitée en amont pour les composants essentiels de la chaîne de compilation. Cependant, le portage devrait rester actif et disponible à l'installation même en ne faisant pas partie de la publication stable officielle. En conséquence, voici ci-dessous la liste des architectures officiellement prises en charge pour Debian GNU/Linux etch : * Intel x86 (« i386 ») * Alpha (« alpha ») * SPARC (« sparc ») * PowerPC (« powerpc ») * ARM (« arm ») * MIPS (« mips » (gros-boutiste --- _big endian_ en anglais) et « mipsel » (petit-boutiste --- _little endian_ en anglais)) * Intel Itanium (« ia64 ») * HP PA-RISC (« hppa ») * S/390 (« s390 ») * AMD64 (« amd64 ») Vous pouvez en savoir plus sur l'état des portages et les informations spécifiques à chaque portage en lisant les pages web sur les portages Debian (http://www.debian.org/ports/alpha/). 2.1. Quoi de neuf dans la distribution ? ---------------------------------------- Cette nouvelle version de Debian est fournie avec plus de logiciels que la version précédente, sarge ; la distribution inclut plus de 6500 nouveaux paquets, pour un total de plus de 18200 paquets. La plupart des logiciels de la distribution ont été mis à jour : plus de 10700 paquets logiciels (ce qui représente 68 % des paquets de la distribution sarge). Un nombre significatif de paquets (plus de 3500, 23 % des paquets de sarge) ont également été supprimés de la distribution pour diverses raisons. Vous ne verrez pas de mise à jour pour ces paquets et ils seront indiqués comme « obsolètes » dans les interfaces de gestion des paquets. Lors de cette version, Debian GNU/Linux passe de XFree86 à la version 7.1 de X.Org qui inclut la prise en charge d'un nombre plus important de matériels et une meilleure autodétection. Elle gère également Compiz qui est l'un des premiers gestionnaires de fenêtres de composition (« compositing ») pour le système X Window sachant tirer avantage de l'accélération OpenGL pour les cartes graphiques prises en charge. Debian GNU/Linux fournit à nouveau plusieurs applications et environnements de bureau. Entre autres, sont maintenant inclus GNOME 2.14[1], KDE 3.5.5a et Xfce 4.4. Des applications de productivité ont également été mises à jour comme les suites bureautiques OpenOffice.org 2.0.4a et KOffice 1.6 ainsi que GNUcash 2.0.5, GNUmeric 1.6.3 et Abiword 2.4.6 Les mises à jour d'autres applications incluent celles d'Evolution 2.6.3 et de Gaim 2.0. La suite Mozilla a également été mise à jour avec un renommage des principaux programmes : `iceweasel' (version 2.0.0.2) est la version démarquée du navigateur web `Firefox' et `icedove' (version 1.5) est la version démarquée du client de messagerie `Thunderbird'. Parmi de nombreuses autres mises à jour, cette version inclut également celles des logiciels suivants : * la bibliothèque C GNU, version 2.3.6 ; * la collection de compilateur GNU (GCC) 4.1 comme compilateur par défaut ; * les interpréteurs de langage : Python 2.4, PHP 5.2 ; * les logiciels serveurs : * serveurs de messagerie : Exim 4.63 (le serveur de messagerie par défaut pour les nouvelles installations), Postfix 2.3, Courier 0.53, Cyrus 2.2 ; * serveurs web : Apache 2.2, fnord 1.10 ; * serveurs de bases de données : MySQL 5.0.32, PostgreSQL 8.1 ; * le serveur OpenSSH, version 4.3 ; * serveurs de noms (DNS) : Bind 9.3, maradns 1.2 ; * serveur d'annuaire : OpenLDAP 2.3. La distribution Debian GNU/Linux officielle est maintenant livrée sur 19 à 23 cédéroms binaires avec un nombre équivalent de cédéroms de sources. Une version DVD de la distribution est également disponible. [1] Avec quelques modules de GNOME 2.16. 2.1.1. Gestion de paquets ------------------------- `Aptitude' est le programme préférentiel pour la gestion des paquets en console. Il gère la plupart des opérations en ligne de commande d'`apt-get' et il a été démontré qu'il résout mieux les dépendances entre paquets qu'`apt-get'. Si vous utilisez toujours `dselect', vous devriez changer pour `aptitude' comme interface officielle de gestion des paquets. Pour etch, un mécanisme avancé de résolution de conflits a été implémenté dans `aptitude' qui tentera de trouver la meilleure solution si des conflits sont détectés en raison de changements dans les dépendances entre paquets. 2.1.2. Secure APT ----------------- _Secure APT_ est maintenant disponible dans etch. Cette fonctionnalité ajoute une sécurité supplémentaire aux systèmes Debian GNU/Linux par la gestion de cryptographie forte et de signatures numériques pour valider les paquets téléchargés. Cette version inclut l'outil `apt-key' pour ajouter de nouvelles clés au trousseau de clés d'apt qui ne comporte par défaut que la clé de signature de l'archive Debian actuelle, fournie dans le paquet `debian-archive-keyring'. Dans sa configuration par défaut, `apt' émettra un avertissement si des paquets sont téléchargés depuis des sources non authentifiées. Des versions futures pourraient forcer la vérification de tous les paquets avant de les télécharger. Les administrateurs de sources apt non officielles sont encouragés à générer une clé de chiffrage et à signer leurs fichiers Release, ainsi qu'à fournir un moyen sécurisé de distribuer leurs clés publiques. Pour plus d'informations, veuillez lire la page de manuel apt(8), le chapitre La signature de paquet dans Debian (http://www.debian.org/doc/manuals/securing-debian-howto/ch7#s-deb-pack-sign) du _Manuel de sécurisation de Debian_ et le wiki Debian (http://wiki.debian.org/SecureApt). Une autre fonctionnalité ajoutée à `apt' est la capacité à ne télécharger que les changements dans les fichiers `Packages' depuis votre dernière mise à jour. Vous pouvez trouver plus d'informations sur cette fonctionnalité dans Section 5.1.4, `Téléchargements plus lents des fichiers d'index de paquets APT'. 2.1.3. debian-volatile est maintenant un service officiel --------------------------------------------------------- Le service _debian-volatile_ introduit en tant que service non officiel dans la distribution sarge est maintenant devenu un service officiel Debian GNU/Linux. Cela veut dire qu'il utilise maintenant une adresse `.debian.org'[1]. Veuillez vous assurer de mettre à jour votre fichier `/etc/apt/sources.list' en conséquence si vous utilisiez déjà ce service. _debian-volatile_ permet aux utilisateurs de mettre à jour facilement des paquets stables contenant des informations qui deviennent rapidement obsolètes. Ce service peut inclure, par exemple, une liste de signatures de scanneur de virus ou un ensemble de modèles d'un filtre à pourriels. Pour obtenir plus d'informations ainsi qu'une liste des miroirs, veuillez consulter la page web (http://volatile.debian.org/) de l'archive. [1] L'ancienne adresse `volatile.debian.net' reste également valide pour le moment. 2.2. Améliorations du système ----------------------------- Il y a de nombreux changements dans la distribution au bénéfice des nouvelles installations d'etch, mais ceux-ci peuvent ne pas être appliqués automatiquement aux mises à niveau depuis sarge. Cette section fournit une vue d'ensemble des changements les plus pertinents. Réduction de la priorité des paquets de développement de base Un certain nombre de paquets de développement qui étaient auparavant de priorité _standard_ sont maintenant de priorité _optional_, ce qui veut dire qu'ils ne seront plus installés par défaut. Cela inclut le compilateur C/C++ standard, `gcc', ainsi que d'autres logiciels (`dpkg-dev', `flex', `make') et des entêtes de développement (`libc6-dev', `linux-kernel-headers'). Si vous désirez avoir ces paquets sur votre système, la façon la plus simple de les installer est d'installer le paquet `build-essential' qui va tirer la plupart d'entre eux. SELinux La priorité des paquets nécessaires pour la prise en charge de SELinux a été augmentée à _standard_. Cela veut dire qu'ils seront installés par défaut si vous choisissez la tâche Standard pendant l'installation. Pour les systèmes existants, vous pouvez installer SELinux avec : # aptitude install selinux-basics Veuillez noter que la prise en charge de SELinux _n'est pas_ activée par défaut. Vous pourrez trouver des informations sur la configuration et l'activation de SELinux dans le wiki Debian (http://wiki.debian.org/SELinux). Nouveau superdémon inet par défaut Le superdémon par défaut pour etch est `openbsd-inetd' au lieu de `netkit-inetd'. Il ne sera pas démarré si aucun service n'est configuré, ce qui est le cas par défaut. Le nouveau démon par défaut sera installé automatiquement lors de la mise à niveau. Changement du clone par défaut de `vi' La variante installée pour `vi' par défaut est une version compacte de `vim' (`vim-tiny') au lieu de `nvi'. Changements dans les fonctionnalités par défaut pour `ext2'/`ext3' Les nouveaux systèmes de fichiers ext2 et ext3 seront créés avec les fonctionnalités _dir_index_ et _resize_inode_ activées par défaut. La première fonctionnalité accélère les opérations sur les répertoires avec un grand nombre de fichiers ; la seconde permet de redimensionner un système de fichiers à chaud (c.-à-d. pendant qu'il est monté). Les utilisateurs effectuant la mise à niveau depuis sarge peuvent envisager d'ajouter le drapeau _dir_index_ manuellement en utilisant `tune2fs'[1] ; le drapeau _resize_inode_ ne peut pas être ajouté à un système de fichiers existant. Il est possible de vérifier quels drapeaux sont positionnés pour un système de fichiers en utilisant `dumpe2fs -h'. Le codage par défaut pour etch est l'UTF-8 Le codage pour les nouvelles installations Debian GNU/Linux est l'UTF-8. Un certain nombre d'applications seront également configurées pour utiliser l'UTF-8 par défaut. Les utilisateurs effectuant une mise à niveau vers etch et désirant basculer vers l'UTF-8 devront reconfigurer leur environnement et les définitions des locales. La valeur par défaut pour l'ensemble du système peut être changée en utilisant `dpkg-reconfigure locales' ; sélectionnez tout d'abord une locale UTF-8 pour votre pays et votre langue (par exemple, fr_FR.UTF-8 pour le français de France), puis positionnez celle-ci comme locale par défaut. Notez que cette bascule vers l'UTF-8 implique que vous devrez probablement convertir les fichiers existants de votre précédent codage (obsolète) vers l'UTF-8. Le paquet `utf8-migration-tool' contient un outil qui peut aider cette migration, cependant ce paquet n'est disponible que dans _unstable_ car il n'était pas prêt à temps pour etch. Il est fortement recommandé de faire une sauvegarde de vos données et de votre configuration avant d'utiliser cet outil. Notez que certaines applications peuvent ne pas fonctionner correctement dans un environnement UTF-8, principalement en raison de problèmes d'affichage. Le wiki Debian (http://wiki.debian.org/Sarge2EtchUpgrade) contient des informations supplémentaires sur les changements entre sarge et etch. [1] Le drapeau _filetype_ devrait déjà être positionné sur la plupart des systèmes de fichiers, excepté peut-être sur les systèmes installés avant sarge. 2.3. Changements majeurs liés au noyau -------------------------------------- Debian GNU/Linux 4.0 est livrée avec un noyau en version 2.6.18 pour toutes les architectures ; cette publication est encore principalement [1] compatible avec les noyaux 2.4, mais Debian ne fournit et ne prend plus en charge les paquets de noyau 2.4. Il y a eu des changements majeurs à la fois dans le noyau lui-même et dans l'empaquetage du noyau pour Debian. Certains de ces changements compliquent la procédure de mise à niveau et peuvent potentiellement entraîner des problèmes lors du redémarrage du système après la mise à niveau vers etch. Cette section fournit une vue d'ensemble des changements les plus importants ; les problèmes potentiels et des informations sur les moyens de les contourner sont inclus dans les chapitres suivants. Si vous utilisez actuellement un noyau 2.4, vous devriez lire attentivement Section 5.2, `Mettre à jour vers un noyau 2.6'. [1] Certains paquets individuels peuvent ne plus fonctionner correctement avec un noyau 2.4 ;voir Section 5.1.2, `Certaines applications peuvent ne plus fonctionner avec un noyau 2.4'. 2.3.1. Changements dans l'empaquetage du noyau ---------------------------------------------- Renommage des paquets de noyau Tous les paquets de noyau Linux ont été renommés de `kernel-*' en `linux-*' pour nettoyer l'espace de noms. Cela facilitera l'inclusion future de noyaux non-Linux dans Debian. Quand cela est possible, des paquets factices de transition dépendant des nouveaux paquets ont été fournis pour les paquets abandonnés. 2.3.2. Nouveaux utilitaires pour générer les initrd --------------------------------------------------- Les paquets d'image de noyau Debian pour Alpha nécessitent un initrd pour amorcer le système. À cause de changements dans le noyau, l'utilitaire utilisé pour générer les initrd dans sarge, `initrd-tools' ne peut plus être utilisé et est obsolète. Deux nouveaux utilitaires ont été développés pour le remplacer : `initramfs-tools' et `yaird'. Les concepts derrière ces deux utilitaires sont très différents ; une vue d'ensemble est disponible dans le wiki Debian (http://wiki.debian.org/InitrdReplacementOptions). Les deux génèrent un initrd en utilisant le système de fichiers _initramfs_ qui est une archive `cpio' compressée. L'utilitaire par défaut et recommandé est `initramfs-tools'. Mettre à jour vers un noyau d'_etch_ entraînera l'installation d'`initramfs-tools' par défaut. Si vous faites une mise à jour depuis un noyau 2.4 vers un noyau 2.6, vous devez utiliser `initramfs-tools'. Utiliser `yaird' fera échouer les installations de linux-image-2.6 quand celles-ci s'exécutent sur un noyau 2.2 ou 2.4. Le paquet `initrd-tools' est encore inclus dans etch car il est nécessaire pour les mises à niveau depuis sarge. Il sera abandonné pour la prochaine version. 2.3.3. Gestion dynamique de `/dev' et détection matérielle ---------------------------------------------------------- Les noyaux de etch ne fournissent plus de prise en charge pour `devfs'. Le remplaçant de `devfs' est `udev', une implémentation en espace utilisateur de devfs. `Udev' est une implémentation en espace utilisateur de devfs. Il est monté sur le répertoire `/dev/' et va peupler ce répertoire avec des périphériques gérés par le noyau. Il va également ajouter et supprimer des périphériques quand les modules noyau sont chargés et déchargés respectivement selon les événements générés par le noyau. `Udev' est beaucoup plus flexible que `devfs' et fournit des services utilisés par d'autres paquets comme `hal' (couche d'abstraction réseau). En association avec le noyau, `udev' s'occupe également de la détection matérielle et du chargement des modules pour les périphériques détectés. À cause de cela, il entre en conflit avec `hotplug'. Dans sarge, `discover' pouvait également être utilisé pour charger les modules pendant le processus d'amorçage, mais sa nouvelle versions dans etch ne fournit plus cette fonction. `discover' est également utilisé par X.Org pour détecter quel contrôleur graphique est présent dans le système. Si vous installez une image de noyau Debian, `udev' sera installé par défaut car `initramfs-tools' en dépend. Vous pouvez éviter l'installation d'`udev' en compilant un noyau non modulaire ou en utilisant un générateur d'initrd alternatif comme `yaird'. Cependant, `initramfs-tools' est le générateur d'initrd recommandé. ------------------------------------------------------------------------------- 3. Système d'installation ------------------------- L'installateur Debian est le système officiel d'installation pour Debian. Il offre une variété de méthodes d'installation. Les méthodes disponibles pour installer votre système dépendent de votre architecture. Les images de l'installateur pour etch peuvent être trouvées avec le manuel d'installation sur le site web Debian (http://www.debian.org/releases/stable/debian-installer/). Le manuel d'installation est également inclus sur le premier CD (ou DVD) de l'ensemble des CD (ou DVD) Debian officiels à : /doc/install/manual//index.html Vous pouvez également vouloir vérifier les errata (http://www.debian.org/releases/stable/debian-installer/index#errata) de l'installateur Debian pour une liste de problèmes connus. L'installateur ne peut être utilisé que pour l'installation sur des systèmes Alpha gérant la console SRM. Veuillez vous assurer de basculer votre système sur SRM avant de commencer l'installation. Si votre machine ne gère que la console AlphaBIOS/ARC, la façon recommandée d'installer etch est tout d'abord d'installer un système _Woody_ (minimal), puis de le mettre à niveau vers sarge et enfin vers etch. Pour plus d'informations sur les différentes consoles, veuillez lire les références sur les pages web du portage sur Alpha de Debian (http://www.debian.org/ports/alpha). 3.1. Quoi de neuf dans le système d'installation ? -------------------------------------------------- Il y a eu beaucoup de développements sur l'installateur Debian depuis sa première publication officielle avec sarge, ce qui a résulté en une meilleure prise en charge du matériel et plusieurs nouvelles fonctionnalités intéressantes. Dans ces notes de publication, nous ne listons que les changements majeurs dans l'installateur. Si vous êtes intéressé par un aperçu global des changements détaillés depuis sarge, veuillez consulter les annonces de publication pour les versions bêtas et candidates de publication d'etch dans l'historique des nouvelles (http://www.debian.org/devel/debian-installer/News/) du projet de l'installateur Debian. 3.1.1. Changements majeurs -------------------------- Pas de redémarrage pendant l'installation Auparavant, l'installation était séparée en deux parties : mettre en place le système de base et le rendre amorçable, suivi par un redémarrage et après celui-ci, l'exécution de `base-config' qui s'occupait de choses comme l'ajout des utilisateurs, la configuration du système de gestion des paquets et l'installation des paquets supplémentaires (en utilisant tasksel). Pour etch, la seconde étape a été intégrée dans l'installateur Debian lui-même. Cela comprend un certain nombre d'avantages dont une sécurité améliorée et le fait qu'après le redémarrage à la fin de l'installation, le nouveau système devrait déjà être configuré avec le bon fuseau horaire et si vous avez installé l'environnement de bureau, il lancera directement l'interface graphique utilisateur. Codage UTF-8 par défaut pour les nouveaux systèmes L'installateur configurera les systèmes pour qu'ils utilisent le codage UTF-8 plutôt que les anciens codages spécifiques à chaque langue (comme ISO-8859-1, EUC-JP ou KOI-8). Partitionnement plus flexible Il est maintenant possible de configurer des systèmes de fichiers sur un volume LVM en utilisant le partitionnement assisté. L'installateur est également capable de mettre un place des systèmes de fichiers chiffrés. En utilisant le partitionnement manuel, vous avez le choix entre `dm-crypt' et `loop-aes', en utilisant une phrase de passe ou une clé aléatoire et vous pouvez ajuster différentes autres options. En utilisant le partitionnement assisté, l'installateur créera une partition LVM chiffrée contenant tout autre système de fichiers (à l'exception de `/boot') en tant que volumes logiques. Mode de récupération (« rescue mode ») Vous pouvez utiliser l'installateur pour résoudre des problèmes avec votre système, par exemple quand il refuse de démarrer. Les premières étapes seront identiques à une installation classique, mais l'installateur ne proposera pas de lancer l'outil de partionnement. Au lieu de cela, il vous présentera un menu d'options de récupération. Le mode de récupération s'active en démarrant l'installateur avec `rescue' ou en ajoutant le paramètre de démarrage `rescue/enable=true'. Utilisation de sudo au lieu du compte root Pendant une installation en mode expert, vous pouvez choisir de ne pas configurer de compte root (celui-ci sera bloqué), mais à la place, de configurer `sudo' afin que le premier utilisateur puisse l'utiliser pour l'administration du système. Vérification cryptographique des paquets téléchargés Les paquets téléchargés avec l'installateur sont maintenant vérifiés cryptographiquement en utilisant `apt', ce qui rend plus difficile la compromission d'un système installé à partir du réseau. Configuration simplifiée du système de messagerie Si le « système standard » est installé, l'installateur va mettre en place une configuration de base du serveur de messagerie du système qui ne fournit que la distribution des courriels en local. Le serveur de messagerie ne sera pas disponible pour les autres systèmes connectés au même réseau. Si vous voulez configurer votre système pour gérer les messages distants par rapport à votre système (pour les émettre ou/et les recevoir), vous devrez configurer le système de messagerie après l'installation. Sélection du bureau Le système d'installation installera un bureau GNOME comme bureau par défaut si l'utilisateur en demande un. Cependant, les utilisateurs désirant installer des environnements de bureau alternatifs peuvent facilement le faire en ajoutant des paramètres d'amorçage : `tasks="standard, kde-desktop"' pour KDE et `tasks="standard, xfce-desktop"' pour Xfce. Veuillez noter que cela ne fonctionnera pas si vous faites l'installation à partir d'une image de CD complète sans installer de miroir réseau comme source supplémentaire de paquets ; cela fonctionnera à partir d'une image de DVD ou avec toute autre méthode d'installation. Des images de CD séparées installant l'environnement de bureau KDE ou Xfce par défaut sont également disponibles. Nouvelles langues Grâce aux très importants efforts des traducteurs, Debian peut maintenant être installée dans 47 langues en utilisant l'interface d'installation en mode texte. Cela fait six langues de plus que dans sarge. Les langues supplémentaires sont le biélorusse, l'espéranto, l'estonien, le kurde, le macédonien, le tagalog, le vietnamien et le wolof. En raison de l'absence de mise à jour des traductions, deux langues ont été abandonnées dans cette version : le persan et le gallois. Les utilisateurs ne désirant pas utiliser de locale peuvent maintenant choisir _C_ comme leur locale préférée lors de la sélection de la langue. Vous pourrez trouver plus d'informations sur la couverture de la langue dans la liste des langues de l'installateur Debian (http://d-i.alioth.debian.org/i18n-doc/languages.html). Sélection simplifiée de la localisation et du fuseau horaire La configuration de la langue, du pays et du fuseau horaire a été simplifiée pour réduire la quantité d'informations à fournir par l'utilisateur. L'installateur essaiera maintenant de deviner le pays du système et le fuseau horaire selon la langue sélectionnée ou il fournira une sélection limitée s'il ne le peut pas. L'utilisateur peut toujours choisir une combinaison exotique s'il le désire. Amélioration de la traduction globale du système La plupart des tâches d'internationalisation et de localisation gérées auparavant par l'outil `localization-config' sont maintenant incluses dans l'installateur Debian standard ou dans les paquets eux-mêmes. Cela veut dire que la sélection d'une langue va automatiquement installer des paquets nécessaires pour cette langue (dictionnaires, documentation, polices, etc.) pour les environnements standard et de bureau. La configuration qui n'est plus gérée automatiquement inclut la configuration de la taille du papier et certains paramètres avancés de clavier de X Window pour certaines langues. Veuillez noter que certains paquets de langue spécifiques ne seront installés automatiquement que s'ils sont disponibles pendant l'installation. 3.1.2. Installation automatisée ------------------------------- Un grand nombre des changements mentionnés dans la section précédente impliquent également des changements dans la gestion de l'installateur des installations automatisées par l'utilisation de fichiers de préconfiguration. Cela veut dire que si vous aviez des fichiers de préconfiguration existants fonctionnant avec l'installateur de sarge, vous ne devez pas vous attendre à ce qu'ils fonctionnent avec le nouvel installateur sans modifications. La bonne nouvelle est que le manuel d'installation (http://www.debian.org/releases/stable/installmanual) comprend maintenant une annexe séparée avec une documentation complète sur l'utilisation de la préconfiguration. L'installateur d'etch introduit plusieurs fonctionnalités intéressantes permettant une automatisation plus complète et plus facile des installations. Il ajoute également une gestion pour le partitionnement avancé utilisant RAID, LVM et LVM chiffré. Veuillez vous reporter à la documentation pour les détails. 3.2. Concours de popularité --------------------------- Le système d'installation proposera à nouveau d'installer le paquet `popularity-contest'. Ce paquet n'était pas installé par défaut dans sarge, mais il l'était dans les versions précédentes. `Popularity-contest' fournit au projet Debian des informations précieuses pour savoir quels paquets de la distribution sont réellement utilisés. Cette information est principalement utilisée pour décider de l'ordre dans lequel les paquets sont placés sur les cédéroms d'installation, mais elle est également souvent consultée par les développeurs Debian pour décider ou non de l'adoption d'un paquet qui n'a plus de responsable. Les informations de `popularity-contest' sont traitées automatiquement. Nous apprécierions que vous participiez au sondage officiel, contribuant ainsi à l'amélioration de Debian. ------------------------------------------------------------------------------- 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 Chapitre 5, `Problèmes à connaître pour etch'. 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 Section 4.6.4, `Réordonnement de l'énumération des périphériques') 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 (http://www.debian.org/releases/stable/installmanual) et la FAQ de l'installateur Debian (http://wiki.debian.org/DebianInstaller/FAQ). 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[1] 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. [1] Cette fonctionnalité peut être désactivée en ajoutant le paramètre `panic=0' à vos paramètres d'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 Section 5.3, `Transition de XFree86 vers X.Org'). 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 Section A.1, `Mettre à niveau votre système sarge'. 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 Section A.2, `Vérifier votre liste de sources'. 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 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 Section A.2, `Vérifier votre liste de sources'. 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[1]. La section Section 4.5.8, `Problèmes possibles pendant une mise à niveau' contient des informations sur la façon de gérer des conflits de fichiers s'ils se produisent. [1] Le système de gestion des paquets de Debian ne permet normalement pas qu'un paquet supprime ou remplace un fichier appartenant à un autre paquet sauf si celui-ci est prévu pour remplacer le paquet. 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 ' 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-alpha/... http://mirrors.kernel.org/debian/dists/etch/contrib/binary-alpha/... 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-alpha/... /var/ftp/debian/dists/etch/contrib/binary-alpha/... 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 / 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 Section 4.5.6, `Mettre à jour le reste du système'. 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. [1] 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 : * supprimer des paquets qui ont été téléchargés pour installation auparavant (dans `/var/cache/apt/archive'). Nettoyer le cache des paquets en exécutant `apt-get clean' ou `aptitude clean' supprimera tous les fichiers de paquet téléchargés auparavant ; * supprimer d'anciens paquets que vous n'utilisez plus. Si vous avez installé `popularity-contest', vous pouvez utiliser `popcon-largest-unused' pour lister les paquets que vous n'utilisez pas et qui occupent le plus de place. Vous pouvez également utiliser `deborphan' ou `debfoster' pour trouver les paquets obsolètes (voir Section 4.10, `Paquets obsolètes') ; * supprimer les paquets qui prennent trop de place et qui ne sont pas actuellement nécessaires (vous pourrez toujours les réinstaller après la mise à niveau). Vous pouvez lister les paquets prenant le plus d'espace disque avec `dpigs' (disponible dans le paquet `debian-goodies') ou avec `wajig' (en exécutant `wajig size'). Sinon, vous pouvez lancer `aptitude' en « mode visuel » et trouver les paquets obsolètes dans la section « Obsolete and Locally Created Packages » (« Paquets obsolètes ou créés localement ») ; * déplacer temporairement vers un autre système les journaux système résidant sous`/var/log/' (ou les supprimer définitivement). [1] Exécuter cette commande au début du processus de mise à niveau peut provoquer une erreur pour les raisons décrites dans les sections suivantes. Dans ce cas, vous devez attendre d'avoir effectuer la mise à niveau minimale du système comme décrit dans Section 4.5.4, `Mise à niveau minimale du système' et d'avoir mis à jour votre noyau comme décrit dans Section 4.5.5, `Mettre à jour le noyau' avant d'exécuter cette commande pour estimer l'espace disque nécessaire. 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 Section 4.10, `Paquets obsolètes'. 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. [1] # aptitude install x11-common 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). [1] Cette commande déterminera si vous avez besoin d'installer libfam0 et xlibmesa-glu et les sélectionnera automatiquement pour vous : # aptitude install x11-common \ $(dpkg-query --showformat '${Package} ${Status}\n' -W libfam0c102 xlibmesa-glu \ | grep 'ok installed$' | sed -e's/ .*//; s/c102//') 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 Section 4.1.4, `Préparer un environnement sain pour la mise à niveau' 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- Voir Section 4.6.1, `Installer un méta-paquet de noyau' 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 Section 4.6, `Mettre à jour le noyau et les paquets liés' 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 '. 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 Section 2.1.1, `Gestion de paquets'. 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 Section 5.1.4, `Téléchargements plus lents des fichiers d'index de paquets APT'. 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 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 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 <> (en utilisant <>) ... dpkg: erreur de traitement de <> (--install): tentative de remplacement de « <> », qui appartient aussi au paquet <> dpkg-deb: sous-processus paste tué par le signal (Broken pipe) Des erreurs ont été rencontrées pendant l'exécution : <> 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 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. Si vous utilisez actuellement un noyau 2.4, vous devriez également lire attentivement Section 5.2, `Mettre à jour vers un noyau 2.6'. 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 Section 4.5, `Paquets mis à jour'). 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 Section 4.5.5, `Mettre à jour le noyau' pour une description de ce processus. Notez que cela devrait être effectué uniquement après le processus de mise à niveau minimal décrit dans Section 4.5.4, `Mise à niveau minimale du système'. 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. Mettre à jour depuis un noyau 2.4 ---------------------------------------- Si vous avez un noyau 2.4 d'installé et que votre système s'appuie sur `hotplug' pour la détection du matériel, vous devriez en premier effectuer une mise à jour vers un noyau de la série 2.6 de sarge avant de tenter de faire la mise à niveau du système. Assurez-vous que le noyau 2.6 démarre votre système et que tout votre matériel est correctement détecté avant de faire la mise à niveau. Le paquet `hotplug' est supprimé du système (en faveur d'`udev') lors de la mise à niveau complète du système. Si vous faites pas la mise à jour du noyau avant cela, votre système peut ne plus redémarrer correctement à ce moment. Une fois que vous avez fait la mise à jour vers un noyau de la série 2.6 de sarge, vous pouvez faire une mise à jour du noyau comme décrit à Section 4.6.2, `Mettre à jour depuis un noyau 2.6'. Si votre système ne s'appuie pas sur `hotplug'[1], vous pouvez différer la mise à jour du noyau pour la faire après avoir fait la mise à niveau complète du système, comme décrit dans Section 4.5.6, `Mettre à jour le reste du système'. Une fois que votre système a été mis à niveau, vous pouvez ensuite exécuter la commande suivante (en remplaçant __ dans le nom du paquet de noyau par celui le plus approprié pour votre système) : # aptitude install linux-image-2.6- [1] Vous pouvez avoir les modules noyau nécessaires à votre système chargés statiquement par une configuration appropriée de `/etc/modules' 4.6.4. 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'[1]. 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/'. [1] Les règles de ce fichier sont générées automatiquement par le script `/etc/udev/rules.d/z45_persistent-net-generator.rules' pour avoir des noms persistants pour les interfaces réseau. Supprimez ce lien symbolique pour désactiver le nommage persistant des périphériques par `udev'. 4.6.5. 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 (http://bugs.debian.org/341152). 4.7.2. 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. * Si vous utilisez `grub', éditez `/etc/kernel-img.conf' et ajustez l'emplacement du programme `update-grub' en changeant `/sbin/update-grub' en `/usr/sbin/update-grub'. * Si le méta-paquet image du nouveau noyau a été tiré comme dépendance de l'ancien, il sera marqué comme ayant été installé automatiquement, ce qui devrait être corrigé : # aptitude unmarkauto $(dpkg-query -W 'linux-image-2.6-*' | cut -f1) * Supprimez les méta-paquets de noyau de sarge en exécutant : # aptitude purge kernel-image-2.6- * Déplacez toutes les options de configuration de `/etc/network/options' dans `/etc/sysctl.conf'. Veuillez lire `/usr/share/doc/netbase/README.Debian' pour plus de détails. * Supprimez tous les paquets obsolètes et non utilisés comme décrit dans Section 4.10, `Paquets obsolètes'. Vous devriez contrôler les fichiers de configuration qu'ils utilisent et envisager de purger les paquets pour supprimer leurs fichiers de configuration. 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 : * apache (1.x), remplacé par apache2 * bind8, remplacé par bind9 * php4, remplacé par php5 * postgresql-7.4, remplacé par postgresql-8.1 * exim 3, remplacé par exim4 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[1] 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 (http://bugs.debian.org/) 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 (http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=ftp.debian.org&archive=yes). [1] Ou aussi longtemps qu'il n'y a pas de nouvelle version pendant cet intervalle de temps. Il n'y a typiquement qu'au plus deux versions stables de supportées à tout moment. 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. ------------------------------------------------------------------------------- 5. Problèmes à connaître pour etch ---------------------------------- 5.1. Problèmes potentiels ------------------------- Parfois, des changements ont des effets de bord que nous ne pouvons pas raisonnablement éviter ou nous exposons des bogues à un autre endroit. Nous documentons ici les problèmes dont nous sommes au courant. Veuillez également lire les errata, la documentation des paquets concernés, les rapports de bogue et les autres sources d'informations mentionnées dans Section 6.1, `Lectures pour aller plus loin'. 5.1.1. Problèmes avec des périphériques liés à udev --------------------------------------------------- Bien que le paquet `udev' ait été testé de façon poussée, vous pouvez rencontrer des problèmes mineurs avec certains périphériques qui devront être corrigés. Les problèmes les plus courants sont des changements de permissions et/ou de propriétaire d'un périphérique. Dans certains cas, un périphérique peut ne pas être créé par défaut (par exemple, `/dev/video' et `/dev/radio'). `Udev' fournit des mécanismes de configuration pour gérer ces problèmes. Voir udev(8) et `/etc/udev' pour plus d'informations. 5.1.2. Certaines applications peuvent ne plus fonctionner avec un noyau 2.4 --------------------------------------------------------------------------- Certaines applications dans etch peuvent ne plus fonctionner avec un noyau 2.4, par exemple parce qu'elles nécessitent la gestion `epoll()' qui n'est pas disponible dans les noyaux 2.4. De telles applications peuvent ne pas fonctionner du tout ou ne pas fonctionner correctement tant que le système n'aura pas été redémarré avec un noyau 2.6. Un exemple est le serveur mandataire (« proxy ») `squid'. 5.1.3. Certains sites du réseau ne peuvent pas être joints par TCP ------------------------------------------------------------------ Depuis le noyau 2.6.17, Linux utilise l'ajustement dynamique des fenêtres TCP (« TCP window scaling ») qui est spécifié dans la RFC 1323 d'une façon agressive. Certains serveurs ont un comportement défectueux et annonce des tailles de fenêtres erronées pour eux-même. Veuillez consulter les rapports de bogues 381262 (http://bugs.debian.org/381262), 395066 (http://bugs.debian.org/395066) et #401435 (http://bugs.debian.org/401435) pour plus d'informations. Il existe habituellement deux contournements pour ces problèmes : soit réduire la taille maximum autorisée des fenêtres TCP à une valeur plus petite (le contournement préféré), soit désactiver complètement l'ajustement dynamique des fenêtres TCP (contournement déconseillé). Voir les commandes exemples dans la page des errata de l'installateur Debian (http://www.debian.org/devel/debian-installer/errata). 5.1.4. Téléchargements plus lents des fichiers d'index de paquets APT --------------------------------------------------------------------- Par défaut, la version d'etch d'`apt' utilise une nouvelle méthode pour mettre à jour les fichiers d'index de paquets APT (quand vous exécutez `aptitude update') qui ne télécharge que les fichiers de différences (au lieu du fichier d'index de paquets complet) appelée `pdiff'. Cette nouvelle fonctionnalité devrait utiliser moins de bande passante et être plus rapide pour la plupart des systèmes. Malheureusement, elle peut également avoir l'effet inverse de rendre les mises à jour plus lentes sur les systèmes avec une connexion réseau rapide (ou un miroir très proche) et qui sont peu fréquemment mis à jour, car cela peut prendre plus de temps au système de fusionner les fichiers de différences que de télécharger l'index de paquets complet. Il est possible de désactiver cette fonctionnalité en ajoutant `Acquire::Pdiffs "false";' au fichier de configuration `/etc/apt/apt.conf'. Ce changement concerne principalement les utilisateurs des branches _unstable_ et _testing_ de Debian GNU/Linux en raison de la nature changeante de ces archives. Les utilisateurs de etch remarqueront principalement cette fonctionnalité lors de la mise à jour de l'état des paquets pour l'archive de sécurité. 5.1.5. L'initialisation asynchrone du réseau peut conduire à un comportement imprévisible ---------------------------------------------------------------------------- Sur les systèmes utilisant `udev' pour charger les pilotes des interfaces réseau, il est possible en raison de la nature asynchrone d'`udev' que le pilote réseau ne soit pas chargé avant l'exécution de `/etc/init.d/networking' lors du démarrage du système. Bien que l'inclusion de `allow-hotplug' dans `/etc/network/interfaces' (en plus de `auto') garantira que l'interface réseau sera activée une fois qu'elle sera disponible, il n'est pas garanti que cela sera terminé avant que la séquence de démarrage commence à lancer les services réseau dont certains peuvent ne pas se comporter correctement en l'absence d'interface réseau. 5.1.6. Problème lors de l'utilisation de réseau sans fil sécurisé par WPA ------------------------------------------------------------------------- Dans sarge, le paquet `wpasupplicant' package était configuré comme un service système par `/etc/default/wpasupplicant' et un fichier `/etc/wpasupplicant.conf' fourni par l'utilisateur. Dans etch, `/etc/init.d/wpasupplicant' a été abandonné et le paquet Debian s'intègre maintenant avec `/etc/network/interfaces', de façon semblable à d'autres paquets comme `wireless-tools'. Cela veut dire que `wpasupplicant' ne fournit plus directement de service système. Pour des informations sur la configuration de `wpasupplicant', veuillez vous référer à `/usr/share/doc/wpasupplicant/README.modes.gz' qui donne des exemple pour le fichier `/etc/network/interfaces'. Des informations mises à jour sur l'utilisation du paquet `wpasupplicant' dans Debian peuvent être trouvées dans le wiki Debian (http://wiki.debian.org/WPA). 5.1.7. Problèmes avec les caractères non-ASCII dans les noms de fichier ----------------------------------------------------------------------- Monter des systèmes de fichiers vfat, ntfs ou iso9660 avec des fichiers incluant des caractères non-ASCII dans leurs noms de fichier peut entraîner des erreurs lors de l'utilisation des noms de fichier sauf si le montage est effectué avec l'option utf8. Une indication peut être l'erreur suivante : « Invalid or incomplete multibyte or wide character » (Caractère multi-octets ou étendu invalide ou incomplet). Une solution possible est d'utiliser `defaults,utf8' comme options de montage pour les systèmes de fichiers vfat, ntfs et iso9660 quand ils contiennent des noms de fichier avec des caractères non-ASCII. Veuillez noter que le noyau Linux ne gère pas les noms de fichier insensibles à la casse pour vfat quand l'option `utf8' est utilisée. 5.1.8. Arrêt de fonctionnement du son ------------------------------------- Dans de rares cas, le son peut ne plus fonctionner correctement après la mise à niveau. Si cela se produit, veuillez suivre la liste de vérification ALSA : exécutez `alsaconf' en tant qu'utilisateur root, ajoutez votre utilisateur au groupe `audio', utilisez alsamixer et assurez-vous que les niveaux sont activés et ne sont pas muets, assurez-vous qu'arts et esound sont arrêtés, assurez-vous que les modules OSS ne sont pas chargés, assurez-vous que les haut-parleurs sont allumés, vérifiez si la commande `cat /dev/urandom > /dev/dsp/' fonctionne pour l'utilisateur root. 5.2. Mettre à jour vers un noyau 2.6 ------------------------------------ La série de noyaux 2.6 contient des changements majeurs par rapport à la série 2.4. Des modules ont changé de noms et beaucoup de pilotes ont été partiellement et parfois presque complètement réécrits. La mise à jour vers un noyau 2.6 à partir d'une version précédente n'est donc pas un processus à prendre à la légère. Cette section a pour objectif de vous prévenir de certains problèmes que vous pourriez rencontrer. Si vous compilez votre propre noyau à partir des sources, assurez-vous d'installer `module-init-tools' avant de redémarrer avec le noyau 2.6. Ce paquet remplace `modutils' pour les noyaux 2.6. Si vous installez l'un des paquets `linux-image' de Debian, ce paquet sera installé automatiquement grâce aux dépendances. Si vous utilisez _LVM_, vous devriez également installer `lvm2' avant de redémarrer car le noyau 2.6 ne gère pas directement LVM1. Pour accéder aux volumes LVM1, la couche de compatibilité de `lvm2' (le module dm-mod) est utilisée. Vous pouvez laisser `lvm10' installé ; le script d'initialisation détectera quel noyau est utilisé et exécutera la version appropriée. Si vous avez des entrées dans le fichier `/etc/modules' (la liste des modules à charger pendant le démarrage du sytème), soyez conscient que certains noms de module ont pu changer. Si cela se produit, vous devrez mettre ce fichier à jour avec les nouveaux noms des modules. Une fois que vous avez installé votre noyau 2.6, mais avant de redémarrer, assurez-vous d'avoir une méthode de récupération. Assurez-vous tout d'abord que la configuration du chargeur d'amorçage possède des entrées pour le nouveau noyau et pour l'ancien et fonctionnel noyau 2.4. Vous devriez également vous assurer d'avoir une disquette ou un cédérom de récupération sous la main au cas où une mauvaise configuration de votre chargeur d'amorçage vous empêcherait d'amorcer l'ancien noyau. 5.2.1. Configuration du clavier ------------------------------- Le changement le plus profond dans les noyaux 2.6 est un changement fondamental dans la couche d'entrée. Ce changement rend tous les claviers visibles comme des claviers PC « normaux ». Cela veut dire que si vous avez un type différent de clavier sélectionné (par exemple, un clavier USB-MAC ou un clavier Sun), il est très probable que vous obteniez un clavier non fonctionnel après le redémarrage avec le nouveau noyau 2.6. Si vous pouvez vous connecter par SSH à la machine depuis un autre système, vous pouvez résoudre ce problème en exécutant `dpkg-reconfigure console-data', en choisissant l'option « Choisir un codage clavier dans la liste complète » (ou « Select keymap from full list » en anglais) et en sélectionnant un clavier « pc ». Si votre clavier de console est concerné, vous devrez probablement également reconfigurer votre clavier pour le système de fenêtrage X (« X Window System »). Vous pouvez faire cela soit en exécutant `dpkg-reconfigure xserver-xorg', soit en éditant `/etc/X11/xorg.conf' directement. N'oubliez pas de lire la documentation indiquée dans Section 4.7, `Choses à faire avant le prochain redémarrage'. Notez que si vous utilisez un clavier USB, celui-ci peut être configuré soit comme un clavier PC « normal », soit comme un clavier USB-MAC. Dans le premier cas, vous ne serez pas concerné par ce problème. 5.2.2. Configuration de la souris --------------------------------- À nouveau, à cause de changement dans la couche d'entrée du noyau, il se peut que vous deviez reconfigurer le système de fenêtrage X et `gpm' si votre souris ne fonctionne pas après avoir fait une mise à jour vers un noyau 2.6. La cause la plus probable est que le périphérique recevant les données de la souris a changé. Il se peut également que vous deviez charger différents modules. 5.2.3. Configuration du son --------------------------- Pour la série des noyaux 2.6, les pilotes de son ALSA sont recommandés par rapport aux pilotes de son OSS plus anciens. Les pilotes de son ALSA sont fournis en tant que modules par défaut. Pour que le son fonctionne, les modules ALSA appropriés pour votre matériel de son doivent être chargés. En général, cela se produit automatiquement si vous avez, en plus du paquet `alsa-base', soit le paquet `hotplug', soit le paquet `discover' d'installé. Le paquet `alsa-base' va marquer les modules OSS pour empêcher `hotplug' et `discover' de les charger. Si vous avez des modules OSS listés dans `/etc/modules', vous devriez les supprimer. 5.3. Transition de XFree86 vers X.Org ------------------------------------- La transition vers X.Org implique des changements structurels. Si tous les paquets installés proviennent de Debian et sont également inclus dans _etch_, la mise à jour devrait se passer sans problème. Cependant, l'expérience a montré qu'il y a quelques changements à connaître car ils peuvent potentiellement poser problème lors de la mise à jour. Le changement le plus important est que `/usr/X11R6/bin' a été éliminé et ne reste que comme lien symbolique vers `/usr/bin'. Cela veut dire que le répertoire doit être vide au moment de l'installation des nouveaux paquets. Ceux-ci entrent en conflit avec la plupart des paquets qui utilisaient `/usr/X11R6/bin', mais dans certains cas, une action manuelle peut être nécessaire. Veuillez vous rappeler de ne pas faire la mise à niveau de la distribution depuis une session X. Au cas où la mise à jour échoue pendant l'installation de X.Org, vous devriez vérifier si des fichiers sont encore présents dans `/usr/X11R6/bin'. Vous pouvez ensuite utiliser `dpkg -S' pour trouver quel paquet Debian a installé ce fichier (si ce dernier appartient à un paquet) et supprimer de tels paquets avec `dpkg --remove'. Vous devriez noter les paquets supprimés afin de pouvoir installer par la suite des paquets de remplacement. Avant de continuer la mise à jour, tous les fichiers dans `/usr/X11R6/bin' doivent être retirés. Veuillez lire http://wiki.debian.org/Xorg69To7 pour plus de détails et d'autres problèmes. Si vous rencontrez des problèmes avec X.Org après avoir redémarré, il peut être utile de relancer le serveur de polices avec la commande `/etc/init.d/xfs restart'. Cela se produit car `/etc/X11/fs/xfs.options' contient une ligne avec `no-restart-on-upgrade', mais des chemins de police ont changé. 5.4. Absence de prise en charge des affichages 8 bits dans de nombreuses applications ---------------------------------------------------------------------------- Après la mise à jour de X.Org et des dernières bibliothèques, les terminaux X qui peuvent seulement représenter des couleurs sur une profondeur de 8 bits ne fonctionneront pas. Cela est dû au fait que la bibliothèque graphique vectorielle 2D Cairo (`libcairo2') ne possède pas de prise en charge de pseudo-couleurs 8 bits. Cette bibliothèque est utilisée par les bureaux GNOME et Xfce ainsi que par de nombreuses applications compilées avec la boîte à outils Gtk2+, comme `abiword'. Les systèmes connus pour être concernés par ce problème incluent certaines machines Sun et des terminaux X de Tektronix, NCD, IBM, ainsi que quelques autres systèmes de fenêtrage X distants. Si possible, vous devriez configurer ces terminaux pour qu'ils utilisent des couleurs 16 bits. Des informations complémentaires sont disponibles dans le bogue 4945 (https://bugs.freedesktop.org/show_bug.cgi?id=4945) de Freedesktop. 5.5. Mise à jour d'exim vers exim4 ---------------------------------- L'un des paquets rendu obsolète par la publication d'_etch_ est le serveur de messagerie (« Mail Transfer Agent » ou MTA) `exim'. Il a été remplacé par le paquet `exim4' qui est entièrement nouveau. `Exim' (version 3.xx) n'est plus maintenu en amont depuis plusieurs années et Debian a également arrêté la prise en charge de cette version. Si vous utilisez encore `exim' 3.xx, veuillez mettre à jour manuellement votre installation d'`exim' vers `exim4'. Comme `exim4' faisait déjà partie de _sarge_, vous pouvez choisir de faire la mise à jour sur votre système _sarge_ avant la mise à niveau générale vers _etch_ ou après la mise à niveau vers _etch_ à votre convenance. N'oubliez pas que votre paquet `exim' ne sera pas mis à jour et qu'il ne sera plus pris en charge au niveau sécurité avec la fin de la prise en charge de _sarge_. Notez qu'en fonction de votre configuration de `debconf', il se peut qu'aucune question de configuration ne vous soit posée pendant l'installation du paquet `exim4'. Si c'est le cas, le système utilisera par défaut une configuration de « distribution locale ». La reconfiguration est possible avec la commande `dpkg-reconfigure exim4-config'. Les paquets `exim4' dans Debian sont documentés de façon complète. La page d'accueil dans le wiki Debian est http://wiki.debian.org/PkgExim4 et le fichier README peut être trouvé à http://pkg-exim4.alioth.debian.org/README/README.Debian.html ainsi que dans les paquets. Le fichier README contient un chapitre à propos de l'empaquetage qui explique les différentes variantes de paquets que nous proposons, il contient également un chapitre sur la mise à jour depuis `exim' 3, qui vous aidera à effectuer la transition. 5.6. Mise à jour d'apache ------------------------- Apache a été mis à jour vers la version 2.2. Bien que cela ne devrait pas avoir d'impact pour l'utilisateur standard, il existe quelques problèmes potentiels à connaître. http://httpd.apache.org/docs/2.2/upgrading.html contient les changements effectués en amont. Veuillez lire cette page et vous rappeler en particulier ces points : * tous les modules doivent être recompilés ; * les modules d'autorisation doivent être triés à nouveau et renommés ; * quelques options de configuration ont été renommés. Parmi les changements spécifiques à Debian, la chaîne SSL n'est plus définie car ssl est maintenant pris en charge par le paquet par défaut. Si vous utilisez le MPM ITK expérimental (du paquet `apache2-mpm-itk'), le module cgi ne sera pas correctement activé par défaut. Pour l'activer correctement, vous devrez manuellement désactiver `mod_cgid' et activer `mod_cgi' : # cd /etc/apache2/mods-enabled # rm cgid.conf cgid.load # ln -s ../mods-available/cgi.load . # /etc/init.d/apache2 force-reload 5.7. Mise à jour de Zope et Plone --------------------------------- Zope et tous les produits liés à celui-ci ont été mis à jour. Un grand nombre de produits ont également été supprimés de la distribution (soit parce qu'ils étaient obsolètes, soit parce qu'ils étaient incompatibles avec les versions plus récentes de Zope, CMF ou Plone). Malheureusement, il n'existe pas de moyen simple et garanti pour mettre à jour un serveur complexe `zope' ou `plone'. Bien que Plone comprenne un outil de migration, l'expérience a montré que les migrations automatiques peuvent aisément échouer. Pour cette raison, il est recommandé aux utilisateurs de configurer leur système pour qu'ils puissent continuer à exécuter l'installation de sarge de Zope/Plone en même temps que les nouvelles versions d'etch tout en testant la migration. Le moyen le plus simple et le plus sur de faire cela est de faire une copie de votre système sarge sur un autre disque dur ou une autre partition, puis de mettre à jour uniquement l'une des deux copies. Vous pouvez ensuite utiliser `chroot' pour exécuter la version de sarge en parallèle avec la vesion de etch. Il n'est pas possible d'avoir l'ancienne et la nouvelle versions de Zope/Plone installées en même temps sur un système etch, en partie car les anciens paquets dépendent de `python2.3' qui ne peut pas être installé en même temps que `python2.4'. 5.8. Expansion des caractères génériques (« globbing ») avec GNU tar -------------------------------------------------------------------- Les précédentes versions de GNU `tar' supposaient une expansion des caractères génériques de style shell lors de l'extraction ou du listage d'une archive. Par exemple : tar xf foo.tar '*.c' extrayait tous les fichiers dont le nom se termine par « .c ». Ce comportement n'était pas documenté et était incompatible avec les implémentations traditionnelles de `tar'. C'est pourquoi, à partir de la version 1.15.91, GNU `tar' n'utilise plus d'expansion par défaut. Par exemple, l'invocation ci-dessus est maintenant interprétée comme une demande d'extraction de l'archive d'un fichier appelé « *.c ». Voir `/usr/share/doc/tar/NEWS.gz' pour plus d'informations. 5.9. NIS et Network Manager --------------------------- La version de `ypbind' incluse avec `nis' pour etch contient la prise en charge pour Network Manager. Cette prise en charge entraîne `ypbind' à désactiver la fonctionnalité client NIS quand Network Manager signale que l'ordinateur est déconnecté du réseau. Comme Network Manager indiquera habituellement que l'ordinateur est déconnecté quand il n'est pas utilisé, les utilisateurs NIS avec des systèmes client NIS devraient s'assurer que la prise en charge Network Manager est désactivée sur ces systèmes. Cela peut être fait soit en désinstallant le paquet `network-manager', soit en éditant `/etc/default/nis' pour ajouter `-no-dbus' à `YPBINDARGS'. L'utilisation de `-no-dbus' est l'option par défaut pour les nouvelles installations de Debian, mais cela ne l'était pas dans les publications précédentes. 5.10. Les configurations PHP non sécurisées sont obsolètes ---------------------------------------------------------- Pendant plusieurs années, activer le paramètre de configuration `register_globals' dans PHP était connu pour être non sécurisé et dangereux et cette option a été désactivée par défaut depuis un certain temps. Cette configuration est maintenant finalement obsolète sur les systèmes Debian car trop dangereuse. Le même comportement s'applique pour des failles dans safe_mode et open_basedir qui ne sont également plus maintenus depuis un certain temps. À partir de cette version, l'équipe de sécurité Debian ne fournit pas de prise en charge de sécurité pour un certain nombre de configurations PHP qui sont connues comme étant non sécurisées. Et plus important, les problèmes provenant du fait que le paramètre de configuration `register_globals' est activé ne sont plus corrigés. Si vous utilisez d'anciennes applications qui nécessitent `register_globals', activez-le pour les chemins respectifs uniquement, par exemple, grâce au fichier de configuration d'Apache. Plus d'informations sont disponibles dans le fichier `README.Debian.security' du répertoire de documentation de PHP (`/usr/share/doc/php4', `/usr/share/doc/php5'). 5.11. État de la sécurité des produits Mozilla ---------------------------------------------- Les programmes Mozilla `firefox' et `thunderbird' (remarquées dans Debian en `iceweasel' et `icedove' respectivement) sont des outils importants pour beaucoup d'utilisateurs. Malheureusement, la règle de sécurité des développeurs amont est de demander aux utilisateurs de mettre à jour avec les nouvelles versions amont, ce qui entre en conflit avec la règle de Debian de ne pas fournir de changements fonctionnels importants dans les mises à jour de sécurité. Nous ne pouvons pas le prédire aujourd'hui, mais il se peut que pendant la durée de vie d'etch, l'équipe de sécurité de Debian arrive à un point où la prise en charge des produits Mozilla ne soit plus possible et qu'elle annonce alors la fin de la prise en charge de sécurité pour les produits Mozilla. Vous devriez prendre cela en compte lors du déploiement de Mozilla et considérer des alternatives dans Debian si l'absence de prise en charge de sécurité vous poserait problème. 5.12. Bureau KDE ---------------- La gestion des médias KDE a changé dans la version disponible dans etch de l'utilisation de `device:/' à `media:/'. Certains fichiers de configuration utilisateur peuvent avoir stocké des liens `device:/' qui doivent être adaptés. En particulier, `~/.kde/share/apps/konqsidebartng/virtual_folders/services' contient cette référence et peut être supprimé sans inconvénient car il ne sera pas créé lors de l'ajout de nouveaux utilisateurs. Il y a eu beaucoup de changements dans l'environnement de bureau KDE depuis la version livrée dans sarge jusqu'à la version dans etch, vous pouvez trouver plus d'informations dans les notes de publication de KDE 3.5 (http://www.kde.org/announcements/announce-3.5.php). 5.13. Changements et gestion du bureau GNOME -------------------------------------------- Si vous utilisiez le bureau GNOME dans sarge, vous ne bénéficierez pas de certains changements introduits dans la configuration par défaut dans Debian pour etch. Dans certains cas extrêmes, le bureau GNOME peut ne pas gérer correctement votre ancienne configuration et peut ne pas se comporter correctement. Si vous n'avez pas investi lourdement dans la configuration de votre bureau GNOME, vous pouvez renommer le répertoire `.gconf' dans le répertoire personnel utilisateur avec un nom différent (comme `.gconf.old') afin qu'il soit recréé, avec la configuration par défaut pour etch, lors du démarrage d'une nouvelle session. Avec la publication d'etch, Debian ne contient plus de paquet pour la plupart de la version 1 obsolète de GNOME, bien que certains paquets aient été conservés pour prendre en charge certains paquets Debian qui n'ont pas encore été mis à jour pour GNOME 2. Les paquets pour GTK1.2 restent complètement maintenus. Il y a eu beaucoup de changements dans l'environnement de bureau GNOME depuis la version livrée dans sarge jusqu'à la version dans etch, vous pouvez trouver plus d'informations dans les notes de publication de GNOME 2.14 (http://www.gnome.org/start/2.14/notes/en/). 5.14. Éditeur par défaut ------------------------ Si vous utilisiez `vim' comme éditeur par défaut, celui-ci peut être remplacé par `nano' pendant la mise à niveau. Les administrateurs désirant changer l'éditeur par défaut pour tous les utilisateurs devront mettre à jour le système des alternatives en utilisant : # update-alternatives --config editor Les utilisateurs désirant changer leur éditeur par défaut peuvent définir la variable d'environnement _EDITOR_ en insérant les lignes suivantes dans leur fichier profile : EDITOR=vi export EDITOR alias editor=$EDITOR 5.15. Message du jour --------------------- Le fichier `/etc/motd' est maintenant un lien symbolique vers `/var/run/motd' qui est reconstruit par `/etc/init.d/bootmisc.sh' à partir d'un modèle, `/etc/motd.tail', lors de chaque redémarrage. Cela veut dire que les changements effectués sur le fichier `/etc/motd' seront perdus. Les changements réalisés sur le fichier `/etc/motd.tail' ne sont pas appliqués automatiquement sur le fichier `/etc/motd' sauf lors du redémarrage. De plus, la variable EDITMOTD du fichier `/etc/default/rcS' n'a plus aucun effet. Si vous désirez désactiver la mise à jour du message du jour ou si vous voulez maintenir votre propre contenu pour le message du jour, il vous suffit de faire pointer le lien symbolique `/etc/motd' vers un fichier différent comme `/etc/motd.static' et d'effectuer vos changements dans ce dernier fichier. 5.16. Pas de gestion par défaut pour l'Unicode dans emacs21* ------------------------------------------------------------ Emacs21 et emacs21-nox ne sont pas configurés par défaut pour utiliser l'Unicode. Pour obtenir plus d'informations ainsi qu'un contournement, veuillez consulter le bogue n°419490 (http://bugs.debian.org/419490). ------------------------------------------------------------------------------- 6. Plus d'informations sur Debian GNU/Linux ------------------------------------------- 6.1. Lectures pour aller plus loin ---------------------------------- En dehors de ces notes de publication et du guide d'installation, de la documentation supplémentaire sur Debian GNU/Linux est disponible sur le projet de documentation Debian (DDP), dont le but est de créer de la documentation de qualité pour les utilisateurs et développeurs Debian. Des documents comprenant la référence Debian, le guide du nouveau responsable Debian, la FAQ Debian et bien plus sont disponibles. Pour tous les détails concernant les ressources disponibles, veuillez consulter le site web du DDP (http://www.debian.org/doc/ddp). La documentation de chaque paquet est installée dans `/usr/share/doc/'. Celle-ci peut contenir les informations concernant le copyright, les détails spécifiques à Debian et toute la documentation d'origine. 6.2. Obtenir de l'aide ---------------------- Il y a beaucoup de sources d'aide et de conseil possibles pour les utilisateurs de Debian, mais on ne devrait les utiliser que si la recherche dans la documentation a été vaine. Cette section fournit une courte introduction aux sources qui peuvent être utiles pour les nouveaux utilisateurs de Debian. 6.2.1. Listes de diffusion -------------------------- Les listes de diffusion les plus intéressantes pour les utilisateurs Debian sont les listes debian-user (en anglais), debian-user-french (en français) et les autres listes debian-user- (pour les autres langues). Pour plus d'informations sur ces listes et des détails sur la façon de s'y inscrire,