Chapitre 4. Mises à jour des versions précédentes

Table des matières

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. Préparez initramfs pour LILO
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. La section proposed-updates
4.2.5. 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 les sources d'un miroir local à apt
4.4.3. Ajouter des sources sur CD-ROM et DVD à apt
4.5. Mettre à jour les paquets
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. Mettez à jour apt et/ou aptitude en premier
4.5.5. Utiliser dans apt la liste des paquets automatiquement installés maintenue par aptitude
4.5.6. Mise à niveau minimale du système
4.5.7. Mettre à jour le reste du système
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étapaquet du noyau
4.6.2. Réordonnement de l'énumération des périphériques
4.6.3. Problèmes de minutage lors de l'amorçage
4.7. Choses à faire avant le prochain redémarrage
4.7.1. Ré-exécuter lilo
4.8. Le démarrage du système s'interrompt sur le message Waiting for root file system
4.8.1. Comment éviter le problème avant d'effectuer la mise à niveau
4.8.2. Comment corriger le problème après la mise à niveau
4.9. Préparations pour la prochaine version
4.10. Paquets obsolètes
4.10.1. Paquets factices

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 Lenny. Ce chapitre couvre des problèmes potentiels non liés directement au processus de mise à niveau, mais qu'il est 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 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.

4.1.1.1. Assurez-vous d'utiliser un noyau approprié

La version de glibc dans Lenny ne fonctionne pas avec des noyaux antérieurs à 2.6.8 quelle que soit l'architecture. Certaines architectures requièrent même des noyaux plus récents. Il est fortement recommandé de mettre le noyau à niveau vers la version 2.6.18 ou 2.6.24, ou encore une version personnalisée de noyau postérieure à 2.6.18, avant de démarrer le processus de mise à jour.

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

4.1.3. Préparations pour une récupération

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.

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[2] 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. Celui-ci possède des commandes de base qui permettent de « tracer » le problème et peut-être de le corriger.

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

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

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

Vous 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

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. Préparez initramfs pour LILO

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.

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 des systèmes etch « purs » sans paquet provenant d'autres sources. Pour une meilleure fiabilité du processus de mise à niveau, vous pouvez supprimer ces paquets de votre système avant de commencer la mise à niveau.

Cette procédure suppose également que votre système a été mis à niveau jusqu'à la dernière révision de etch. 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 etch ».

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 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 »).

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

4.2.4. La section proposed-updates

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.

4.2.5. Sources non officielles et rétroportages

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.

4.2.5.1. Utilisation de paquets de backports.org

Le dépôt backports.org est un dépôt semi-officiel géré par des mainteneurs Debian GNU/Linux dont l'objectif est de fournir des paquets récents pour la distribution stable, sous forme de recompilation de paquets de la distribution « testing ».

Le dépôt backports.org contient des paquets de « testing » dont les numéros de version sont diminués, ce qui permet de préserver les mises à jour des « rétroportages » de etch vers Lenny. Cependant, certains de ces paquets ont été construits à partir d'unstable (mises à jour de sécurité et les exceptions suivantes : Firefox, le noyau, OpenOffice.org et X.Org).

If you do not use one of these exceptions, you can safely upgrade to lenny. If you use one of these exceptions, set the Pin-Priority (see apt_preferences(5)) temporarily to 1001 for all packages from lenny, and you should be able to do a safe dist-upgrade too.

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 'linux-image-2.6.*' | cut -f1)
[Note]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, on indiquera d'abord un disque dur local, puis des CD-ROM, puis les miroirs FTP et HTTP).

[Astuce]Astuce

Il peut être nécessaire d'ajouter une exception de vérification GPG pour les DVD et CD-ROM. Pour cela, ajoutez la ligne suivante dans /etc/apt/apt.conf, si elle n'est pas déjà présente dans /etc/apt/apt.conf.d/00trustcdrom :

APT::Authentication::TrustCDROM "true";

Cela ne fonctionne toutefois pas avec les fichiers image de CD-ROM ou DVD.

Une version peut être référencée à la fois par son nom de code (par exemple, etch, lenny) et par son nom d'état (c.-à-d. oldstable, stable, testing, unstable). Se référer à une version par son nom de code évite d'être surpris par une nouvelle version et c'est pour cette raison que cette approche a été choisie ici. Bien sûr, vous devez surveiller vous-même les annonces des nouvelles versions. Si vous utilisez les noms d'état, vous verrez simplement une grande quantité de mises à jour de paquets disponibles dès qu'une publication a eu 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 »). 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-amd64/...
http://mirrors.kernel.org/debian/dists/lenny/contrib/binary-amd64/...

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.

4.4.2. Ajouter les sources d'un miroir local à apt

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-amd64/...
/var/ftp/debian/dists/lenny/contrib/binary-amd64/...

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.

4.4.3. Ajouter des sources sur CD-ROM et DVD à apt

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.

4.5. Mettre à jour les paquets

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

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, vérifiez à nouveau que les sources d'apt (dans /etc/apt/sources.list) se réfèrent soit à « lenny » soit à « stable ». Il ne doit y avoir aucune source pointant vers etch.

[Note]Note

Les lignes de source pour un cédérom se réfèrent souvent à « unstable » ; bien que cela soit trompeur, vous ne devez 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, 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

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

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

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]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 :

  • supprimer les paquets qui ont été téléchargés auparavant (dans /var/cache/apt/archives). Nettoyer le cache des paquets avec apt-get clean ou aptitude clean supprimera tous les paquets téléchargés auparavant ;

  • supprimer les paquets oubliés. Si vous avez installé popularity-contest, vous pouvez utiliser popcon-largest-unused pour lister les paquets que vous n'utilisez plus 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 »). Sinon, vous pouvez lancer aptitude en « mode interactif » et trouver les paquets obsolètes dans la section « Paquets obsolètes ou créés localement » ;

  • 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).

    You can list packages that take up most of the disk space with aptitude. Start aptitude into « visual mode », select ViewsNew Flat Package List (this menu entry is available only after etch version), press l and enter ~i, press S and enter ~installsize, then it will give you nice list to work with. Doing this after upgrading aptitude should give you access to this new feature.

  • supprimer les traductions et les fichiers de localisation du système, s'ils ne sont pas nécessaires. Vous pouvez installer le paquet localepurge et le configurer de manière à ce qu'un jeu restreint de paramètres régionaux (« locales ») soit conservé sur le système. Cela réduira la place occupée dans /usr/share/locale.

  • déplacer temporairement vers un autre système les journaux système résidant sous/var/log/ (ou les supprimer définitivement).

  • utiliser un répertoire /var/cache/apt/archives temporaire. Vous pouvez utiliser un cache temporaire depuis un autre système de fichiers, un périphérique de stockage par USB, un disque dur temporaire, un système de fichier déjà utilisé, etc.

    [Note]Note

    N'utilisez pas de montage NFS car la connexion réseau pourrait être interrompue au cours de la mise à niveau.

    Par exemple, si une clé USB est montée sur /media/cleusb :

    1. supprimez les paquets téléchargés lors d'une précédente installation :

      # apt-get clean

    2. copiez le répertoire /var/cache/apt/archives sur le disque USB :

      # cp -ax /var/cache/apt/archives /media/cleusb/

    3. montez le répertoire de cache temporaire à la place de l'actuel :

      # mount --bind /media/cleusb/archives /var/cache/apt/archives

    4. après la mise à niveau, rétablissez le répertoire /var/cache/apt/archives initial :

      # umount /media/cleusb/archives

    5. supprimez le répertoire subsistant /media/cleusb/archives.

    Vous pouvez créer le répertoire de cache temporaire dans n'importe quel système de fichiers monté sur votre système.

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

4.5.4. Mettez à jour apt et/ou aptitude en premier

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.

[Note]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.

4.5.5. Utiliser dans apt la liste des paquets automatiquement installés maintenue par aptitude

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"

4.5.6. Mise à niveau minimale du système

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

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

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.

4.5.8. Problèmes possibles pendant une mise à niveau

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

E: Dynamic MMap ran out of room

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

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

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

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

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

# dpkg --remove nom_du_paquet

pour éliminer certains des paquets en cause, ou :

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

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

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

Les conflits de fichiers ne devraient pas se produire si vous mettez à niveau depuis un système 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.

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

Cette section explique comment mettre à jour le noyau et identifie les 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.

4.6.1. Installer un métapaquet du noyau

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

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

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

4.6.3. 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 é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).

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. Ré-exécuter lilo

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.

4.8. Le démarrage du système s'interrompt sur le message Waiting for root file system

Procédure de secours en cas de changement de /dev/hda en /dev/sda

Des utilisateurs ont signalé que suite à une mise à jour, le noyau pouvait ne plus trouver la partition racine lors du démarrage.

Dans ce cas, le démarrage du système s'interrompt sur le message suivant :

Waiting for root file system ...

puis quelques secondes après, une simple invite de commande busybox apparaît.

Ce problème peut se produire lorsque la nouvelle génération des pilotes IDE est utilisée suite à la mise à jour du noyau. Les anciens pilotes nommaient les disques IDE hda, hdb, hdc, hdd et les nouveaux pilotes nomment les mêmes disques sda, sdb, sdc, sdd respectivement. Le problème apparaît lorsque la mise à jour ne génère pas un nouveau fichier /boot/grub/menu.lst qui tienne compte de la nouvelle convention de nommage. Au cours de l'amorçage, Grub transmet alors au noyau un paramètre concernant une partition racine qu'il ne peut pas trouver.

Si vous avez rencontré ce problème après avoir effectué la mise à jour, reportez-vous à Section 4.8.2, « Comment corriger le problème après la mise à niveau ». Pour éviter ce problème avant de mettre à niveau, continuez la lecture.

4.8.1. Comment éviter le problème avant d'effectuer la mise à niveau

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 :

  1. Étiquetez le système de fichier (le nom doit comporter moins de 16 caractères) en exécutant : e2label /dev/hda6 systemeracine

  2. Éditez /boot/grub/menu.lst et modifiez la ligne :

    # kopt=root=/dev/hda6 ro

    en

    # kopt=root=LABEL=systemeracine ro

    [Note]Note

    N'enlevez pas le # au début de la ligne, il est nécessaire.

  3. Mettez à jour les lignes kernel dans menu.lst en exécutant la commande update-grub.

  4. Modifiez /etc/fstab et changez la ligne qui monte la partition /, par exemple :

    /dev/hda6     /     ext3  defaults,errors=remount-ro 0 1

    en

    LABEL=systemeracine     /     ext3  defaults,errors=remount-ro 0 1

    Le changement concerne la première colonne, vous n'avez pas à modifier les autres colonnes de cette ligne.

Pour mettre en œuvre l'approche UUID :

  1. Find out the universally unique identifier of your filesystem by issuing: ls -l /dev/disk/by-uuid | grep hda6. You can also use vol_id --uuid /dev/hda6 (in etch) or blkid /dev/hda6 (if already upgraded to lenny).

    Vous obtiendrez une ligne similaire à celle-ci :

    lrwxrwxrwx 1 root root 24 2008-09-25 08:16 d0dfcc8a-417a-41e3-ad2e-9736317f2d8a -> ../../hda6

    L'UUID est le nom du lien symbolique pointant vers /dev/hda6 c.-à-d. : d0dfcc8a-417a-41e3-ad2e-9736317f2d8a.

    [Note]Note

    L'UUID de votre système de fichiers sera différent.

  2. Éditez /boot/grub/menu.lst et modifiez la ligne :

    # kopt=root=/dev/hda6 ro

    en

    # kopt=root=UUID=d0dfcc8a-417a-41e3-ad2e-9736317f2d8 ro

    [Note]Note

    N'enlevez pas le # au début de la ligne, il est nécessaire.

  3. Mettez à jour les lignes kernel dans menu.lst en exécutant la commande update-grub.

  4. Modifiez /etc/fstab et changez la ligne qui monte la partition /, par exemple :

    /dev/hda6     /     ext3  defaults,errors=remount-ro 0 1

    en

    UUID=d0dfcc8a-417a-41e3-ad2e-9736317f2d8  /  ext3  defaults,errors=remount-ro 0 1

    Le changement concerne la première colonne, vous n'avez pas à modifier les autres colonnes de cette ligne.

4.8.2. Comment corriger le problème après la mise à niveau

4.8.2.1. Solution 1

Cette solution est applicable lorsque le menu de Grub qui permet la sélection de l'entrée sur laquelle démarrer est affiché. Si le menu ne s'affiche pas, essayez de le faire apparaître en appuyant sur la touche Esc avant que le noyau ne démarre. Si vous n'arrivez pas à accéder au menu, essayez la Section 4.8.2.2, « Solution 2 » ou la Section 4.8.2.3, « Solution 3 ».

  1. Dans le menu Grub, sélectionnez l'entrée sur laquelle vous voulez démarrer. Appuyez sur la touche e pour éditer l'entrée. Vous verrez alors quelque chose comme ceci :

    root (hd0,0)
    kernel /vmlinuz-2.6.26-1-686 root=/dev/hda6 ro
    initrd /initrd.img-2.6.26-1-686

  2. Sélectionnez la ligne

    kernel /vmlinuz-2.6.26-1-686 root=/dev/hda6 ro

    appuyez sur la touche e et remplacez hdX par sdX (X étant la lettre a, b, c ou d selon votre système). Dans cet exemple la ligne devient :

    kernel /vmlinuz-2.6.26-1-686 root=/dev/sda6 ro

    Puis appuyez sur Enter pour sauver la modification. Si d'autres lignes comportent hdX, changez-les également. Ne modifiez pas les entrées similaires à root (hd0,0). Une fois effectuées toutes ces modifications, appuyez sur la touche b. Votre système devrait pouvoir démarrer normalement.

  3. Maintenant que votre système a démarré, le problème doit être corrigé de manière permanente. Référez-vous à Section 4.8.1, « Comment éviter le problème avant d'effectuer la mise à niveau » et appliquez une des deux procédures proposées.

4.8.2.2. Solution 2

Démarrez depuis un support d'installation de Debian GNU/Linux (CD/DVD) puis lorsqu'une invite apparaît, choisissez rescue afin de lancer le mode de secours. Sélectionnez la langue, l'emplacement géographique, l'agencement du clavier, et laissez faire la configuration du réseau, qu'elle réussisse ou pas. Au bout d'un moment, il vous sera demandé la partition que vous voulez utiliser comme système de fichiers racine. Les choix proposés ressemblent à :

/dev/ide/host0/bus0/target0/lun0/part1
/dev/ide/host0/bus0/target0/lun0/part2
/dev/ide/host0/bus0/target0/lun0/part5
/dev/ide/host0/bus0/target0/lun0/part6

Si vous savez quelle partition contient votre système de fichiers racine, choisissez-la. Si vous ne le savez pas, essayez la première. Si un message apparaît au sujet d'une partition de système de fichiers racine invalide, essayez la partition suivante, et ainsi de suite. Essayer les partitions les unes à la suite des autres ne devrait pas les affecter. D'autre part, si un seul système est installé sur vos disques, vous devriez facilement retrouver la bonne partition racine. Si plusieurs systèmes sont installés, cela serait plus simple de connaître exactement quelle est la bonne partition.

Une fois la partition choisie, plusieurs actions vous seront proposées. Choisissez d'exécuter un shell dans la partition sélectionnée. Si cela ne fonctionne pas, essayez avec une autre partition.

Vous devriez avoir maintenant une ligne de commande vous donnant un accès superutilisateur à votre système de fichiers racine, monté sur /target. Vous avez besoin d'accéder au contenu des répertoires /boot, /sbin et /usr de votre disque dur, qui devraient être disponibles sur /target/boot, /target/sbin et /target/usr. Si ces répertoires doivent être montés à partir d'autres partitions, faites-le. (Consultez /etc/fstab si vous n'avez aucune idée de la partition à monter).

Référez-vous à Section 4.8.1, « Comment éviter le problème avant d'effectuer la mise à niveau » et appliquez une des deux procédures proposées pour corriger le problème de manière permanente. Puis saisissez exit pour quitter le shell de secours et sélectionnez reboot pour redémarrer le système normalement. N'oubliez pas de retirer les supports amovibles.

4.8.2.3. Solution 3

  1. Démarrez depuis votre distribution autonome (« Live CD ») préférée, par exemple Debian Live, Knoppix ou Ubuntu Live.

  2. Montez la partition où se trouve le répertoire /boot. Si vous ne savez pas de laquelle il s'agit, utilisez le résultat de la commande dmesg pour savoir si votre disque est vu comme hda, hdb, hdc, hdd ou sda, sdb, sdc, sdd. Une fois le disque determiné, par exemple sdb, utilisez la commande suivante pour obtenir la table des partitions du disque et trouver la bonne partition : fdisk -l /dev/sdb.

  3. En supposant que la bonne partition est montée sous /mnt et que cette partition contient le répertoire /boot ainsi que son contenu, éditez le fichier /mnt/boot/grub/menu.lst.

    Repérez la section similaire à :

    ## ## End Default Options ##
    
    title           Debian GNU/Linux, kernel 2.6.26-1-686
    root            (hd0,0)
    kernel          /vmlinuz-2.6.26-1-686 root=/dev/hda6 ro
    initrd          /initrd.img-2.6.26-1-686
    
    title           Debian GNU/Linux, kernel 2.6.26-1-686 (single-user mode)
    root            (hd0,0)
    kernel          /vmlinuz-2.6.26-1-686 root=/dev/hda6 ro single
    initrd          /initrd.img-2.6.26-1-686
    
    ### END DEBIAN AUTOMAGIC KERNELS LIST

    et remplacez respectivement chaque hda, hdb, hdc, hdd par sda, sdb, sdc, sdd. Ne modifiez pas la ligne similaire à :

    root            (hd0,0)

  4. Redémarrez le système, retirez le CD autonome et votre système devrait démarrer correctement.

  5. Maintenant que votre système a démarré, il vous faut régler le problème définitivement. Référez-vous à Section 4.8.1, « Comment éviter le problème avant d'effectuer la mise à niveau » et appliquez une des deux procédures proposées.

4.9. 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 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 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.10. Paquets obsolètes

Avec lenny, plusieurs milliers de nouveaux paquets apparaissent, tandis que plus de deux mille anciens paquets présents dans etch disparaissent. Il n'est pas prévu de procédure 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 arrête habituellement le support de sécurité un an après la sortie de lenny[6] 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 Lenny 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 à jour est facile car les interfaces de gestion des paquets les marquent 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 dans etch, le programme aura gardé la trace de ces paquets ; ainsi, quand un paquet est supprimé, le programme peut marquer comme obsolètes les paquets installés par le seul jeu des dépendances et qui ne sont plus nécessaires. À la différence de deborphan, aptitude ne marque pas comme obsolètes les paquets que vous avez installés, 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 complé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.

The list of obsolete packages includes:

  • apache (1.x), dont le successeur est apache2

  • bind (8), successor is bind9

  • php4, successor is php5

  • postgresql-7.4, successor is postgresql-8.1

  • exim (3), successor is exim4

4.10.1. Paquets factices

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.



[2] Cette fonctionnalité peut être désactivée en ajoutant le paramètre panic=0 à vos paramètres d'amorçage.

[3] Le système de gestion des paquets de Debian ne permet pas qu'un paquet supprime ou remplace un fichier appartenant à un autre paquet sauf si ce paquet est prévu pour remplacer cet autre paquet.

[4] Les règles de ce fichier sont générées automatiquement par le script /etc/udev/rules.d/75-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.

[5] Pour plus d'informations sur les codes d'erreurs de lilo, veuillez consulter The Linux Bootdisk HOWTO.

[6] 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.