[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ suivant ]
Nous vous suggérons, avant la mise à niveau, de lire les informations de Problèmes à connaître pour etch, Chapitre 5. Ce chapitre couvre des problèmes potentiels non liés directement au processus de mise à niveau, mais qu'il pourrait être important de connaître avant de commencer.
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.
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.
En raison des nombreux changements dans le noyau entre sarge et etch en ce qui concerne les pilotes, la détection matérielle et le nommage et l'ordre des fichiers de périphérique, il existe un risque réel que vous rencontriez des problèmes lors du redémarrage de votre système après la mise à niveau. Un grand nombre des problèmes potentiels sont documentés dans ce chapitre et les suivants de ces notes de publication.
Pour cette raison, il est raisonnable de s'assurer que vous pourrez faire une récupération si votre système échouait au redémarrage ou, pour les systèmes gérés à distance, échouait lors de la mise en place du réseau.
Si vous effectuez une mise à niveau à distance par un lien ssh, il
est fortement recommandé de prendre toutes les précautions nécessaires pour
pouvoir accéder au serveur par un terminal série distant. Il est possible
qu'après la mise à jour du noyau et le redémarrage, les noms de quelques
périphériques soient changés (comme décrit dans Réordonnement de l'énumération des périphériques,
Section 4.6.4) et vous devrez corriger la configuration du système depuis
une console locale. Par ailleurs, si le système est redémarré accidentellement
au milieu de la mise à niveau, il est possible que vous deviez effectuer une
récupération en utilisant une console locale.
L'action la plus évidente à tenter est de redémarrer sur votre ancien noyau. Cependant, pour diverses raisons expliquées ailleurs dans ce document, il n'est pas garanti que cela fonctionnera.
Si cela échoue, vous aurez besoin d'une méthode alternative pour amorcer votre système afin de pouvoir y accéder et de le réparer. Une option est d'utiliser une image de récupération spéciale ou un CD autonome Linux (« Live CD ») Après avoir démarré à partir de ce support, vous devriez pouvoir monter votre système de fichiers racine et effectuer un chroot dans celui-ci pour investiguer et corriger le problème.
Une autre option que nous vous recommandons est d'utiliser le mode de
récupération (« rescue mode ) de l'installateur Debian d'etch.
L'avantage d'utiliser l'installateur est que vous pouvez choisir entre ses
nombreuses méthodes d'installation pour celle qui convient le mieux à votre
situation. Pour plus d'informations, veuillez consulter la section
« Réparer un système cassé » du chapitre 8 du manuel
d'installation et la FAQ de l'installateur
Debian.
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.
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.
Le processus de mise à niveau décrit dans ce chapitre a été conçu pour des
mises à niveau depuis des systèmes sarge « purs » sans paquet de
tierce partie. En particulier, il y a des problèmes connus avec des paquets de
tierce partie installant des programmes sous /usr/X11R6/bin/ qui
entraînent des problèmes lors des mises à jour en raison de la transition X.org
(voir Transition de XFree86 vers X.Org,
Section 5.3). Pour une meilleure fiabilité du processus de mise à niveau,
vous pouvez supprimer ces paquets de tierce partie de votre système avant de
commencer la mise à niveau.
Cette procédure suppose également que votre système a été mis à jour jusqu'à la dernière révision de sarge. Si vous ne l'avez pas fait ou si vous n'en êtes pas certain, veuillez suivre les instructions de Mettre à niveau votre système sarge, Section A.1.
Dans certains cas, l'utilisation d'apt-get pour l'installation de
paquets au lieu d'aptitude peut induire aptitude à
considérer un paquet comme « unused » (inutilisé) et à le programmer
pour suppression. En général, vous devriez vous assurer que le système est
complètement à jour et « propre » avant de commencer la mise à
niveau.
À cause de cela, vous devez commencer par vérifier s'il y a des actions en
cours dans le gestionnaire de paquets aptitude. Si un paquet est
programmé pour être supprimé ou mis à jour dans le gestionnaire des paquets,
cela peut poser problème lors de la procédure de mise à niveau. Notez que la
correction de cela n'est possible que si votre fichier
sources.list pointe encore vers sarge; et pas vers
stable ou etch ; voir Vérifier votre liste de sources,
Section A.2.
Pour faire cela, vous devez lancer l'interface graphique
d'aptitude et appuyer sur 'g' (« Go »). S'il affiche
une action, vous devez la contrôler et soit l'annuler ou la terminer. Si
aucune action n'est suggérée, il vous sera présenté un message indiquant
« No packages are scheduled to be installed, removed, or upgraded »
(« Il n'est prévu d'installer, mettre à jour ou enlever aucun
paquet »).
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).
Quelle que soit la méthode utilisée pour mettre à niveau, il est recommandé de tester d'abord l'état de tous les paquets et de vérifier que tous les paquets se trouvent dans un état permettant la mise à niveau. La commande suivante vous indiquera tous les paquets qui sont dans l'état « Half-Installed » ou « Failed-Config », ainsi que ceux qui sont dans un état d'erreur :
# dpkg --audit
Vous pouvez aussi vérifier l'état de tous les paquets de votre système en
utilisant dselect, aptitude, ou avec des commandes
comme :
# dpkg -l | pager
ou :
# dpkg --get-selections "*" > ~/paquets-actuels.txt
Il est souhaitable d'enlever tous les blocages de paquets (on hold) avant de passer à la nouvelle version. Si un paquet essentiel pour la mise à jour est bloqué, la mise à jour va échouer.
Notez qu'aptitude utilise une méthode différente pour enregistrer
les paquets qui sont bloqués de celle d'apt-get et
dselect. Vous pouvez identifier les paquets bloqués pour
aptitude avec :
# aptitude search "~ahold" | grep "^.h"
Si vous désirez vérifier quels paquets étaient bloqués pour
apt-get, il vous faudra utiliser :
# dpkg --get-selections | grep hold
Si vous aviez modifié et recompilé un paquet localement, sans changer son nom et sans mettre d'époque (« epoch ») dans la version, vous devez le bloquer pour éviter qu'il ne soit mis à niveau.
Vous pouvez activer un blocage sur un paquet pour aptitude en
utilisant :
# aptitude hold nom_du_paquet
Remplacez hold par unhold pour débloquer un paquet.
Si vous devez corriger quelque chose, il est préférable de vous assurer que
votre sources.list fait toujours référence à sarge comme expliqué
dans Vérifier votre liste de
sources, Section A.2.
Si vous avez des paquets non-Debian sur votre système, vous devriez être
conscient que ceux-ci peuvent être supprimés pendant la mise à niveau à cause
de dépendances conflictuelles. Si ces paquets ont été installés par l'ajout
d'une archive de paquets supplémentaire dans votre
/etc/apt/sources.list, vous devriez vérifier si cette archive
propose également des paquets compilés pour etch et changer la ligne de source
en conséquence en même temps que vos lignes de source pour les paquets Debian.
Certains utilisateurs peuvent avoir installé sur leur système sarge des versions non officielles rétroportées de paquets plus récentes que celles qui sont dans Debian. De tels paquets sont les plus susceptibles de poser problème lors d'une mise à niveau car ils peuvent entraîner un conflit de fichiers[6]. La section Problèmes possibles pendant une mise à niveau, Section 4.5.8 contient des informations sur la façon de gérer des conflits de fichiers s'ils se produisent.
Pour empêcher aptitude de retirer certains paquets qui étaient
installés grâce à des dépendances, vous devez les démarquer manuellement des
paquets auto (automatiquement installés). Cela inclut OpenOffice et
Vim pour les installations de bureau :
# aptitude unmarkauto openoffice.org vim
et les images de noyau 2.6 si vous les avez installées en utilisant un méta-paquet de noyau :
# aptitude unmarkauto $(dpkg-query -W 'kernel-image-2.6.*' | cut -f1)
Note : vous pouvez vérifier quels paquets sont marqués comme auto dans aptitude en exécutant :
# aptitude search 'i~M <package name>'
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.
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-mips/...
http://mirrors.kernel.org/debian/dists/etch/contrib/binary-mips/...
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.
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-mips/...
/var/ftp/debian/dists/etch/contrib/binary-mips/...
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.
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.
La façon recommandée pour faire une mise à niveau depuis des versions
précédentes de Debian GNU/Linux est d'utiliser le gestionnaire de paquets
aptitude. Ce programme prend des décisions plus sûres pour
l'installation des paquets qu'apt-get.
N'oubliez pas de monter les partitions requises (notamment les partitions
racine et /usr) en lecture et écriture, avec une commande de ce
type :
# mount -o remount,rw /point_de_montage
Puis, revérifiez que les entrées de source apt (dans
/etc/apt/sources.list) se réfèrent soit à
« etch » soit à « stable ». Il
ne devrait y avoir aucune source pointant vers sarge. Note : les lignes
de source pour un cédérom se réfèrent souvent à
« unstable » ; bien que cela soit trompeur, vous
ne devriez pas les changer.
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
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.
Vous devez vous assurer avant de faire la mise à niveau de votre système que
vous avez suffisamment d'espace disque comme décrit dans Mettre à jour le reste du système, Section 4.5.6.
Tout d'abord, tous les paquets nécessaires à l'installation récupérés du réseau
sont stockés dans /var/cache/apt/archives (et dans le
sous-répertoire partial/ pendant le téléchargement), vous devez
donc vous assurer d'avoir suffisamment de place sur la partition du système de
fichiers contenant /var/ pour télécharger les paquets qui seront
installés sur votre système. Après le téléchargement, vous aurez probablement
encore besoin de plus d'espace disque sur les autres partitions de système de
fichiers pour pouvoir installer à la fois les paquets mis à jour (qui peuvent
contenir des binaires plus gros ou davantage de données) et les nouveaux
paquets qui sont tirés par la mise à niveau. Si votre système ne dispose pas
de suffisamment d'espace disque, il se peut que vous vous retrouviez avec une
mise à niveau incomplète qui pourrait être délicate à récupérer.
Les programmes aptitude et apt peuvent vous afficher
des informations détaillées sur l'espace disque nécessaire pour l'installation.
Vous pouvez voir cette estimation avant d'effectuer la vraie mise à niveau avec
la commande :
# aptitude -y -s -f --with-recommends dist-upgrade
[ ... ]
XXX paquets mis à jour, XXX nouvellement installés, XXX à enlever et XXX non mis à jour.
Il est nécessaire de télécharger xx,xMo d'archives. Après dépaquetage, AAAMo seront utilisés.
Charger/installer/enlever des paquets.
[7]
Si vous n'avez pas assez d'espace disque pour la mise à niveau, assurez-vous de libérer assez d'espace disque auparavant. Vous pouvez :
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 Paquets obsolètes, Section
4.10) ;
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).
En raison de certains conflits de paquets nécessaires entre sarge et etch, exécuter aptitude dist-upgrade directement va souvent supprimer un grand nombre de paquets que vous voulez garder. C'est pourquoi nous recommandons un processus de mise à niveau en deux étapes, tout d'abord une mise à niveau minimale pour résoudre ces conflits, puis un dist-upgrade complet.
Exécutez en premier
# aptitude upgrade
Cela a pour effet de mettre à jour les paquets qui peuvent l'être sans nécessiter que d'autres paquets soient supprimés ou installés.
Puis, continuez la mise à niveau minimale avec :
# aptitude install initrd-tools
Cette étape va mettre automatiquement à jour les paquets libc6 et
locales et va installer les bibliothèques de prise en charge de
SELinux (libselinux1). À ce moment, certains services en
fonctionnement seront redémarrés, comprenant xdm, gdm
et kdm. En conséquence, les sessions locales X seront
déconnectées.
L'étape suivante est variable selon l'ensemble de paquets que vous avez installé. Ces notes de publication donnent des conseils généraux sur la méthode à utiliser, mais en cas de doute, il est recommandé d'examiner les suppressions de paquets proposées par chacune des méthodes avant de les effectuer réellement.
Certains paquets courants qui devraient être supprimés incluent
base-config, hotplug, xlibs,
netkit-inetd, python2.3, xfree86-common,
et xserver-common. Pour une liste plus complète des paquets
obsolètes dans etch, voir Paquets obsolètes, Section
4.10.
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
Les systèmes avec certains paquets X installés, mais pas la tâche
desktop complète, nécessitent une méthode différente. Cette
méthode s'applique en général aux systèmes avec le paquet
xfree86-common installé, y compris certains systèmes serveur ayant
les tâches serveur du paquet tasksel installés car certaines de
ces tâches incluent des outils de gestion graphiques. Il s'agit probablement
de la bonne méthode à utiliser sur les systèmes faisant fonctionner X, mais
n'ayant pas la tâche desktop complète d'installée.
# dpkg -l xfree86-common | grep ^ii
En premier, vérifiez si vous avez les paquets libfam0c102 et
xlibmesa-glu d'installés.
# dpkg -l libfam0c102 | grep ^ii
# dpkg -l xlibmesa-glu | grep ^ii
Si vous n'avez pas le paquet libfam0c102 d'installé, n'incluez pas
le paquet libfam0 dans la ligne de commande suivante. Si vous
n'avez pas le paquet xlibmesa-glu d'installé, ne l'incluez pas
dans la ligne de commande suivante. [8]
# aptitude install x11-common libfam0 xlibmesa-glu
Notez que l'installation du paquet libfam0 installera également
« File Alteration Monitor » (fam) ainsi que le
« RPC portmapper » (portmap) s'ils ne sont pas déjà
disponibles sur votre système. Chacun de ces paquets activera un nouveau
service réseau sur votre système bien qu'ils puissent tous deux être configurés
pour n'être lié qu'avec le périphérique réseau de bouclage (interne).
Sur un système sans X, aucune commande aptitude install supplémentaire ne devrait être nécessaire et vous pouvez passer à l'étape suivante.
La version du paquet udev dans etch ne gère pas les versions de
noyau avant 2.6.15 (ce qui inclut les noyaux 2.6.8 de sarge) et la
version du paquet udev dans sarge ne fonctionnera pas correctement
avec des noyaux récents. De plus, l'installation de la version du paquet
udev d'etch va forcer la suppression du paquet
hotplug utilisé par les noyaux Linux 2.4.
En conséquence, le paquet de noyau précédent ne démarrera probablement pas
correctement après cette mise à jour. De façon similaire, il existe une
fenêtre de temps au cours de laquelle udev est mis à jour, mais
pas le dernier noyau. Si le système était redémarré à ce moment, au milieu de
la mise à jour, il pourra ne pas être amorçable à cause de pilotes qui ne
seraient pas détectés et chargés correctement (voir Préparer un environnement sain pour la mise à
niveau, Section 4.1.4 pour des recommandations sur la préparation à cette
possibilité si vous effectuez une mise à niveau à distance).
Sauf si votre système a la tâche desktop d'installée ou d'autres paquets qui entraîneraient des suppressions d'un nombre inacceptable de paquets, il est donc recommandé de mettre à jour le noyau à ce moment.
Pour effectuer cette mise à jour du noyau, exécutez :
# aptitude install linux-image-2.6-variante
Voir Installer un méta-paquet de noyau, Section 4.6.1 pour de l'aide sur la détermination de la variante du paquet de noyau que vous devriez installer.
Pour les systèmes de bureau, il est malheureusement impossible de garantir que
le nouveau paquet de noyau soit installé immédiatement après l'installation de
la nouvelle version d'udev, il existe donc un intervalle de temps
de durée inconnue pendant lequel votre système n'aura pas de noyau installé
ayant une prise en charge hotplug complète. Voir Mettre
à jour le noyau et les paquets liés, Section 4.6 pour plus d'informations
sur la configuration de votre système pour qu'il ne dépende pas de hotplug au
démarrage.
Vous êtes maintenant prêt à continuer avec la partie principale de la mise à niveau. Exécutez :
# aptitude dist-upgrade
Ceci effectuera une mise à jour complète du système, c.-à-d. installera les versions les plus récentes de tous les paquets, et résoudra tous les changements possibles de dépendances entre paquets des différentes versions. Si nécessaire, cela installera de nouveaux paquets (habituellement de nouvelles versions de bibliothèques, ou des paquets ayant changé de nom), et retirera les paquets obsolètes en conflit.
Lorsque la mise à jour se fait à partir d'un ensemble de cédéroms, on vous demandera d'insérer d'autres cédéroms à plusieurs moments de la mise à niveau. Vous pourriez devoir insérer plusieurs fois le même cédérom. Cela est dû aux relations entre paquets répartis sur plusieurs cédéroms.
Les paquets déjà installés ayant une nouvelle version, mais qui ne peuvent être installés sans modifier l'état d'un autre paquet, seront laissés dans leur version actuelle (et affichés comme retenu — held back). Cela peut être résolu soit en utilisant aptitude et en choisissant d'installer ces paquets, soit en essayant aptitude -f install paquet.
Après la mise à niveau, avec la nouvelle version d'apt, vous
pouvez maintenant mettre à jour les informations des paquets, ce qui inclut le
nouveau mécanisme de vérification des signatures des paquets :
# aptitude update
La mise à niveau aura déjà récupéré et activé les clés de signature pour les
archives de paquets Debian. Si vous ajoutez d'autres sources de paquets (non
officielles), apt affichera des avertissements liés à son
incapacité à vérifier que les paquets téléchargés depuis celles-ci sont
légitimes et n'ont pas été altérés. Pour plus d'informations, veuillez voir Gestion de paquets, Section 2.2.1.
Vous pourrez remarquer que, comme vous utilisez la nouvelle version
d'apt, il téléchargera des fichiers de différences de paquets
(pdiff) au lieu de la liste complète des index de paquets. Pour
plus d'information sur cette fonctionnalité, veuillez voir Téléchargements plus lents des
fichiers d'index de paquets APT, Section 5.1.4.
Si une opération utilisant aptitude, apt-get ou
dpkg échoue avec l'erreur suivante :
E: Dynamic MMap ran out of room
l'espace de cache par défaut est insuffisant. Vous pouvez résoudre cela soit
en enlevant ou en commentant des lignes dont vous n'avez pas besoin dans
/etc/apt/sources.list, soit en augmentant la taille du cache. La
taille du cache peut être augmentée en positionnant
APT::Cache-Limit dans /etc/apt/apt.conf. La commande
suivante le positionne à une valeur qui devrait être suffisante pour la mise à
niveau :
# echo 'APT::Cache-Limit "12500000";' >> /etc/apt/apt.conf
Cela suppose que vous n'avez pas déjà positionné cette variable dans ce fichier.
Il est parfois nécessaire d'activer l'option d'apt
APT::Force-LoopBreak pour pouvoir temporairement retirer un paquet
essentiel à cause de boucles « Conflicts/Pre-Depends ».
Aptitude vous alertera à ce propos et interrompra la mise à
niveau. Vous pouvez contourner ce problème en passant l'option -o
APT::Force-LoopBreak=1 sur la ligne de commande d'aptitude.
Il est possible que la structure de dépendances d'un système soit tellement
défectueuse qu'elle requiert une intervention manuelle. Habituellement, cela
signifie qu'il faut utiliser aptitude ou :
# dpkg --remove nom_du_paquet
pour éliminer certains des paquets en cause, ou :
# aptitude -f install
# dpkg --configure --pending
Dans certains cas extrêmes, vous pourriez devoir forcer une réinstallation à l'aide d'une commande comme :
# dpkg --install /chemin/vers/nom_du_paquet.deb
Les conflits de fichiers ne devraient pas se produire si vous mettez à niveau depuis un système sarge « pur », mais ils peuvent se produire si vous avez des rétroportages non officiels d'installés. Un conflit de fichiers entraînera une erreur de ce type :
Préparation du remplacement de <paquet-toto> (en utilisant <fichier-paquet-toto>) ...
dpkg: erreur de traitement de <paquet-toto> (--install):
tentative de remplacement de « <un-nom-de-fichier> »,
qui appartient aussi au paquet <paquet-titi>
dpkg-deb: sous-processus paste tué par le signal (Broken pipe)
Des erreurs ont été rencontrées pendant l'exécution :
<paquet-toto>
Vous pouvez tenter de résoudre un conflit de fichiers en forçant la suppression du paquet mentionné sur la dernière ligne du message d'erreur :
# dpkg -r --force-depends nom_du_paquet
Après cela, vous devriez être en mesure de continuer la mise à niveau, en utilisant les commandes d'aptitude précédemment décrites.
Durant la mise à niveau, on vous posera des questions pour configurer ou
reconfigurer de nombreux paquets. Quand on vous demandera si des fichiers des
répertoires /etc/init.d ou /etc/terminfo ou le
fichier /etc/manpath.config doivent être remplacés par la version
du responsable du paquet, il est généralement nécessaire de répondre
« oui » pour assurer la cohérence du système. Vous pouvez toujours
revenir aux versions précédentes, puisqu'elles sont sauvegardées avec une
extension .dpkg-old.
Si vous n'êtes pas certain de ce qu'il faut faire, notez le nom du paquet ou du fichier et examinez le problème plus tard. Vous pouvez chercher dans le fichier d'enregistrement pour revoir les informations qui étaient à l'écran lors de la mise à niveau.
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 cette section comprend beaucoup d'informations liées à
l'utilisation des paquets initramfs-tools et udev.
Cependant, comme les noyaux Debian pour mips n'utilisent pas d'initrd pour
amorcer le système, certaines de ces informations peuvent ne pas vous
concerner. Les informations sont cependant incluses car vous pouvez avoir
udev d'installé pour d'autres raisons.
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 Mettre à jour vers un noyau 2.6, Section 5.2.
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.
Si vous utilisez actuellement un noyau de la série 2.6 de sarge, cette mise à jour aura lieu automatiquement après la mise à niveau complète des paquets du système (comme décrit dans Paquets mis à jour, Section 4.5).
Si possible, vous devriez mettre à jour le paquet de noyau séparément de la mise à niveau (dist-upgrade) principale pour réduire les risques d'avoir un système temporairement non amorçable. Voir Mettre à jour le noyau, Section 4.5.5 pour une description de ce processus. Notez que cela devrait être effectué uniquement après le processus de mise à niveau minimal décrit dans Mise à niveau minimale du système, Section 4.5.4.
Vous pouvez également procéder à cette étape si vous utilisez votre propre
noyau personnalisé et que vous voulez utiliser le noyau disponible dans etch.
Si votre version de noyau n'est pas prise en charge par udev, il
vous est alors recommandé de le mettre à jour après la mise à niveau minimale.
Si votre version est gérée par udev, vous pouvez sans inconvénient
attendre d'avoir effectué la mise à niveau complète avant de faire la mise à
jour du noyau.
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 à Mettre à jour depuis un noyau 2.6,
Section 4.6.2.
Si votre système ne s'appuie pas sur hotplug[9], 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 Mettre à jour le reste
du système, Section 4.5.6. Une fois que votre système a été mis à niveau,
vous pouvez ensuite exécuter la commande suivante (en remplaçant
<variante> dans le nom du paquet de noyau par celui le plus
approprié pour votre système) :
# aptitude install linux-image-2.6-<variante>
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[10]. 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/.
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.
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.
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.
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-<variante>
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 Paquets obsolètes, Section 4.10. Vous devriez contrôler les fichiers de configuration qu'ils utilisent et envisager de purger les paquets pour supprimer leurs fichiers de configuration.
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
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[11] et ne fournira normalement pas d'autre support entre temps. Il vous est recommandé de les remplacer par un logiciel alternatif, s'il en existe.
Il y a plusieurs raisons pour lesquelles un paquet peut avoir été retiré de la distribution : il n'est plus maintenu en amont, il n'y a plus de responsable Debian intéressé par la maintenance du paquet, la fonctionnalité fournie par le paquet a été remplacée par un logiciel différent (ou une nouvelle version) ou il n'est plus considéré comme convenable pour etch en raison de ses bogues. Dans ce dernier cas, le paquet peut cependant toujours être présent dans la distribution « unstable ».
Détecter quels paquets sont « obsolètes » dans un système mis à
niveau est facile car les interfaces de gestion des paquets les marqueront
comme tel. Si vous utilisez aptitude, vous verrez une liste de
ces paquets sous l'entrée « Paquets obsolètes ou créés localement ».
Dselect fournit une section similaire, mais la liste présentée
peut être différente. Si vous avez utilisé aptitude pour
installer des paquets manuellement dans sarge, le programme aura gardé la trace
de ces paquets installés manuellement et pourra marquer comme obsolètes les
paquets tirés par les seules dépendances et qui ne sont plus nécessaires si un
paquet est supprimé. À la différence de deborphan,
aptitude ne marquera pas comme obsolètes des paquets que vous avez
installés manuellement, au contraire de ceux qui ont été installés
automatiquement par les dépendances.
Il existe des outils supplémentaires que vous pouvez utiliser pour trouver les
paquets obsolètes comme deborphan, debfoster ou
cruft. Deborphan est hautement recommandé, bien
qu'il n'indique (dans le mode par défaut) que les bibliothèques
obsolètes : les paquets dans les sections « libs » ou
« oldlibs » qui ne sont utilisés par aucun autre paquet. Ne
supprimez pas aveuglément les paquets que ces outils présentent,
particulièrement si vous utilisez des options non standard aggressives, car ils
sont susceptibles de produire des faux positifs. Il est hautement recommandé
d'examiner manuellement les paquets suggérés à la suppression (c.-à-d. leurs
contenu, taille et description) avant de les supprimer.
Le système de suivi des bogues de
Debian fournit souvent des informations supplémentaires sur les
raisons pour lesquelles un paquet a été retiré. Vous devriez consulter à la
fois les comptes-rendus de bogue archivés pour le paquet lui-même et ceux du
pseudo-paquet
ftp.debian.org.
Certains paquets de sarge ont été divisés en plusieurs paquets dans etch, souvent pour améliorer la maintenabilité du système. Pour faciliter le chemin de mise à jour dans de tels cas, etch fournit souvent des paquets « factices » (« dummy packages » en anglais) : des paquets vides qui ont le même nom que l'ancien paquet de sarge avec des dépendances entraînant l'installation des nouveaux paquets. Ces paquets factices sont considérés comme des paquets obsolètes après la mise à jour et peuvent être supprimés sans problème.
La plupart (mais pas toutes) des descriptions des paquets factices indiquent
leur but. Cependant, les descriptions des paquets factices ne sont pas
uniformes, vous pourriez donc trouver que deborphan avec les
options de type --guess-* sont utiles pour les détecter sur votre
système. Notez que certains paquets factices ne sont pas destinés à être
supprimés après une mise à jour, mais ils sont utilisés pour déterminer quelle
est la version actuellement disponible d'un programme.
[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ suivant ]
Notes de publication pour Debian GNU/Linux 4.0 (« etch »), Mips
$Id: release-notes.fr.sgml,v 1.75 2008-01-20 23:45:15 fbothamy Exp $debian-doc@lists.debian.org