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 des informations de configuration que vous ne pouvez 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 peut 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 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 avant la mise à niveau.

Vous devrez probablement faire une mise à jour du noyau lors de la mise à niveau vers Lenny, 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 etch et Lenny en ce qui concerne les pilotes, la détection matérielle, 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 les chapitres de ces notes de publication.

Pour cette raison, il est raisonnable de s'assurer que vous pourrez réparer le système s'il ne redémarrait pas, ou, pour les systèmes gérés à distance, si la connexion au réseau échouait.

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.2, « 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 utiliser une console locale pour réparer le système.

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 sûr que cela fonctionne.

Si cela échoue, vous aurez besoin d'une autre méthode pour amorcer votre système et 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 analyser et corriger le problème.

L'option que nous vous recommandons est d'utiliser le mode de secours (« rescue mode ») de l'installateur Debian de Lenny. L'avantage d'utiliser l'installateur est que vous pouvez choisir l'option 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 devez 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
	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.

Les utilisateurs du programme d'amorçage LILO doivent noter que les paramètres par défaut de initramfs-tools génèrent désormais un initramfs trop grand pour être chargé par LILO. Ces utilisateurs devraient soit changer pour grub, soit éditer le fichier /etc/initramfs-tools/initramfs.conf pour modifier la ligne

MODULES=most

et y écrire

MODULES=dep

Notez cependant que initramfs-tools n'installera dans l'image disque en mémoire (« initramfs ») que les modules requis par le matériel présent. Si vous souhaitez un fichier d'amorçage qui fonctionne avec un matériel différent, vous devez laisser la ligne :

MODULES=most

et vérifiez que vous n'utilisez pas LILO.

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 devez vous assurer que le système est complètement à jour et « propre » avant de commencer la mise à niveau.

Ainsi, 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 d'un tel problème n'est possible que si votre fichier sources.list pointe encore vers etch et pas vers stable ou lenny ; voir Section A.2, « Vérifier votre liste de sources ».

Pour faire cette vérification, vous devez lancer aptitude en « mode interactif » et appuyer sur g (« Go »). S'il affiche une ou plusieurs action(s), vous devez les contrôler et les corriger ou les mettre en œuvre. 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 que pour enregistrer les paquets qui sont bloqués, aptitude utilise une méthode différente de celles 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 à etch comme expliqué dans Section A.2, « Vérifier votre liste de sources ».

Si vous avez ajouté la section proposed-updates dans le fichier /etc/apt/sources.list, il est conseillé de la supprimer avant de tenter la mise à jour. Il s'agit essentiellement d'une précaution pour éviter des conflits possibles.

Si vous avez des paquets non-Debian sur votre système, vous devez savoir qu'ils 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 dans votre /etc/apt/sources.list, vous devez vérifier si cette archive propose également des paquets compilés pour Lenny 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 etch 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^[3]. 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.

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 »). Les miroirs HTTP sont en général plus rapides que les miroirs FTP.

Par exemple, supposons que le miroir Debian le plus proche soit http://mirrors.kernel.org. Si vous consultez 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/lenny/main/binary-i386/...
http://mirrors.kernel.org/debian/dists/lenny/contrib/binary-i386/...

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

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

Notez que « dists » est ajouté automatiquement, et les paramètres qui suivent le nom de version donnent accès à plusieurs répertoires.

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

Plutôt que d'utiliser des miroirs 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/lenny/main/binary-i386/...
/var/ftp/debian/dists/lenny/contrib/binary-i386/...

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

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

Notez que « dists » est ajouté automatiquement, et les paramètres qui suivent le nom de version donnent accès à plusieurs répertoires.

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

Si vous ne voulez utiliser que les CD, 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 CD au point de montage /cdrom
# ls -alF /cdrom     # devrait afficher le contenu de la racine du CD
# umount /cdrom      # démontera le CD

Puis, lancez :

# apt-cdrom add

pour chaque CD-ROM binaire Debian en votre possession, afin d'ajouter ses données dans la base d'apt.

Il est fortement recommandé d'utiliser le programme /usr/bin/script pour enregistrer une transcription de la session de mise à niveau. Ainsi, quand un problème survient, vous avez un enregistrement de ce qui s'est passé, et vous pouvez fournir les informations exactes pour un rapport de bogue. Pour démarrer un enregistrement, saisissez :

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

ou quelque chose d'équivalent. Ne mettez pas 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é. Basculez simplement sur la deuxième console (en utilisant Alt+F2) et, après la connexion, utilisez less -R ~root/mise-a-niveau-lenny.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-lenny.time ~/mise-a-niveau-lenny.typescript

La liste des paquets disponibles pour la nouvelle version doit tout d'abord être récupérée, avec cette commande :

# 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.

Avant de faire la mise à niveau complète de votre système, telle qu'elle est décrite dans Section 4.5.7, « Mettre à jour le reste du système », vous devez vous assurer d'avoir suffisamment d'espace disque. En effet, tous les paquets nécessaires à l'installation 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 /var/ du système de fichiers. 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. Si l'espace disque vient à manquer, la mise à niveau sera incomplète, ce qui peut rendre le système difficile à réparer.

Les programmes aptitude et apt peuvent 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.

Note

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.6, « Mise à niveau minimale du système » et d'avoir mis à jour le noyau avant d'exécuter cette commande pour estimer l'espace disque nécessaire.

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

Notez qu'afin de supprimer des paquets sans dommage, il est conseillé de changer sources.list pour pointer vers etch, comme décrit dans Section A.2, « Vérifier votre liste de sources ».

Several bug reports have shown that the versions of the aptitude and apt packages in etch are often unable to handle the upgrade to lenny. In lenny, apt is better at dealing with complex chains of packages requiring immediate configuration and aptitude is smarter at searching for solutions to satisfy the dependencies. These two features are heavily involved during the dist-upgrade to lenny, so it is necessary to upgrade these two packages before upgrading anything else.

The following command will upgrade both aptitude and apt:

# aptitude install aptitude apt dpkg

This step will also automatically upgrade libc6 and locales. At this point, some running services will be restarted, including xdm, gdm and kdm. As a consequence, local X11 sessions might be disconnected.

Upgrading with apt

Please note that using apt-get is not recommended for the upgrade from etch to lenny. If you do not have aptitude installed you are recommended to install it first. If you want to perform the upgrade with apt or if the upgrade with aptitude failed and you want to try the upgrade with apt' dependency chain resolution algorithm, you should run: # apt-get install apt Note that you will have to adapt other aptitude commands to use apt-get instead.

Aptitude conserve une liste des paquets qui ont été automatiquement installés (par exemple, pour satisfaire les dépendances d'un autre paquet). Dans Lenny, apt dispose aussi de cette fonctionnalité.

Quand la version Lenny d'aptitude est lancée pour la première fois, la liste des paquets automatiquement installés est convertie en une liste utilisable par la version Lenny d'apt. Si aptitude est installé, vous devriez exécuter au moins une fois la commande aptitude pour effectuer la conversion, par exemple en recherchant un paquet qui n'existe pas :

# aptitude search "?false"

En raison de la nécessité du conflit entre les paquets des versions etch et Lenny, la commande aptitude dist-upgrade peut 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 la mise à niveau complète avec dist-upgrade.

Exécutez en premier

# aptitude safe-upgrade

Cette commande met à jour les paquets qui peuvent l'être sans entraîner l'installation ou la suppression d'autres paquets.

L'étape suivante peut être différente 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.

On peut s'attendre à la suppression de certains paquets courants comme base-config, hotplug, xlibs, netkit-inetd, python2.3, xfree86-common, et xserver-common. Pour plus d'informations sur les paquets obsolètes dans Lenny, voir Section 4.10, « Paquets obsolètes ».

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

# aptitude dist-upgrade

Cette commande effectue une mise à niveau complète du système, c.-à-d. installe les versions les plus récentes de tous les paquets, et résoud tous les changements possibles de dépendances entre paquets des différentes versions. Si nécessaire, elle installe de nouveaux paquets (habituellement de nouvelles versions de bibliothèques, ou des paquets ayant changé de nom), et retire les paquets obsolètes en conflit.

Lorsque la mise à jour se fait à partir d'un ensemble de CD-ROM (ou DVD), on vous demandera d'insérer d'autres CD ou DVD à plusieurs moments de la mise à niveau. Vous pourriez devoir insérer plusieurs fois le même CD ou DVD. Cela est dû aux relations entre paquets répartis sur plusieurs supports.

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.

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 etch « pur », mais ils peuvent se produire si des rétroportages non officiels sont 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.

Quand vous faites une mise à niveau de etch vers Lenny, il est fortement recommandé d'installer un nouveau métapaquet 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 ne donne rien, vous devez alors installer un paquet linux-image vous-même. Pour voir la liste des métapaquets 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.6.18-6-686, il est recommandé d'installer linux-image-2.6-686. Notez que la variante k7 n'existe plus ; si vous utilisez actuellement une variante de noyau k7, vous devriez installer à la place la variante 686. Vous pouvez également utiliser apt-cache pour voir une description longue de chaque paquet. Cela peut vous aider à choisir le meilleur paquet 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 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. Notez que cela devrait être effectué uniquement après le processus de mise à niveau minimal décrit dans Section 4.5.6, « Mise à niveau minimale du système ».

Lenny inclut un mécanisme de reconnaissance du matériel plus robuste 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, et par conséquent, des changements dans 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 Lenny, 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, c'est-à dire, plus précisément, par les définitions dans /etc/udev/rules.d/70-persistent-net.rules^[4]. 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 dans le même ordre que celui dans lequel les périphériques ont été chargés. Pour 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 etch et Lenny. Par exemple, sym53c8xx_2 est devenu sym53c8xx.

Vous devez ensuite récréer l'image initramfs en exécutant update-initramfs -u -k all.

Une fois que vous utilisez un noyau de Lenny 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/.

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 échoue car le système de fichiers racine ne peut pas être monté et vous vous retrouvez dans un shell de débogage. Mais après vérifications, tous les périphériques nécessaires sont bien 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 de 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).

Si vous utilisez lilo comme programme d'amorçage (c'est le programme d'amorçage par défaut pour certaines installations de la version etch), il est fortement recommandé de ré-exécuter lilo après la mise à jour :

# /sbin/lilo

Veuillez noter que cela est nécessaire même si vous n'avez pas mis à jour le noyau du système car la seconde étape de lilo va changer à cause de la mise à jour du paquet.

Vérifiez également le contenu de votre fichier /etc/kernel-img.conf et assurez-vous d'avoir do_bootloader = Yes dans celui-ci. Ainsi, le programme d'amorçage sera toujours ré-exécuté après une mise à jour du noyau.

Si vous rencontrez des problèmes lors de l'exécution de lilo, veuillez vérifier les liens symboliques dans / vers vmlinuz et initrd, ainsi que le contenu de votre fichier /etc/lilo.conf.

Si vous avez oublié de ré-exécuter lilo avant le prochain redémarrage ou si le système est redémarré accidentellement avant que vous ne puissiez le faire manuellement, votre système peut ne plus démarrer. Au lieu de l'invite lilo, vous ne verrez que LI lors de l'amorçage du système^[5]. Voir Section 4.1.3, « Préparations pour une récupération » pour des informations sur les méthodes de secours à partir de ce point.

On peut complètement éviter le problème en utilisant un identifiant du système de fichier racine, invariable d'un démarrage à l'autre. Il existe deux méthodes possibles, soit en étiquetant le système de fichiers, soit en utilisant l'identifiant unique universel du système de fichier (UUID). Ces méthodes sont prises en charge depuis la version Etch.

Ces deux approches ont des avantages et des inconvénients. L'approche par les étiquettes est plus lisible, mais il peut y avoir des problèmes si un autre système de fichiers de votre machine possède la même étiquette. L'approche par UUID est plus laide, mais le risque d'avoir deux identifiants identiques est très peu probable.

Dans les exemples ci-dessous, nous supposons que le système de fichiers racine est sur /dev/hda6, et que votre système dispose d'une installation fonctionnelle de udev et des systèmes de fichiers ext2 ou ext3.

Pour mettre en œuvre l'approche par étiquette :

Pour mettre en œuvre l'approche UUID :

Certains paquets de la version Etch ont été divisés en plusieurs paquets dans Lenny, souvent pour améliorer la maintenabilité du système. Pour faciliter la mise à jour dans de tels cas, Lenny fournit souvent des paquets « factices » (« dummy packages » en anglais) : des paquets vides qui ont le même nom que l'ancien paquet de la version Etch et dont les dépendances entraînent 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 des descriptions des paquets factices signalent le but de ces paquets. Cependant, elles ne sont pas uniformes, et le programme deborphan, avec les options de type --guess-*, peut être utile pour détecter ces paquets 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.