Table des matières
Waiting for
root file system
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.
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.
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.
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.
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.
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.
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 ».
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.
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.
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 |
---|---|
Vous pouvez vérifier quels paquets sont marqués comme auto dans aptitude en exécutant : # aptitude search '~i~M' |
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 |
---|---|
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
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.
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.
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 |
---|---|
Les lignes de source pour un cédérom se réfèrent souvent à
« |
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 :
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
→ (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 |
---|---|
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
:
supprimez les paquets téléchargés lors d'une précédente installation :
# apt-get clean
copiez le répertoire /var/cache/apt/archives
sur le
disque USB :
# cp -ax /var/cache/apt/archives /media/cleusb/
montez le répertoire de cache temporaire à la place de l'actuel :
# mount --bind /media/cleusb/archives /var/cache/apt/archives
après la mise à niveau, rétablissez le répertoire
/var/cache/apt/archives
initial :
# umount /media/cleusb/archives
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 ».
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.
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.
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.
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=
. Il se peut que
vous deviez ajuster la valeur pour le délai (en seconde).
9
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.
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.
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.
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 :
Étiquetez le système de fichier (le nom doit comporter moins de 16 caractères) en exécutant : e2label /dev/hda6 systemeracine
Éditez /boot/grub/menu.lst
et modifiez la ligne :
# kopt=root=/dev/hda6 ro
en
# kopt=root=LABEL=systemeracine ro
![]() | Note |
---|---|
N'enlevez pas le |
Mettez à jour les lignes kernel
dans
menu.lst
en exécutant la commande
update-grub.
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 :
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 |
---|---|
L'UUID de votre système de fichiers sera différent. |
É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 |
---|---|
N'enlevez pas le |
Mettez à jour les lignes kernel
dans
menu.lst
en exécutant la commande
update-grub.
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.
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 ».
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
Sélectionnez la ligne
kernel /vmlinuz-2.6.26-1-686 root=/dev/hda6 ro
appuyez sur la touche e et remplacez
hd
par
X
sd
(X
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
hd
, changez-les également. Ne
modifiez pas les entrées similaires à X
root (hd0,0)
. Une
fois effectuées toutes ces modifications, appuyez sur la touche
b. Votre système devrait pouvoir démarrer normalement.
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.
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.
Démarrez depuis votre distribution autonome (« Live CD ») préférée, par exemple Debian Live, Knoppix ou Ubuntu Live.
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.
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)
Redémarrez le système, retirez le CD autonome et votre système devrait démarrer correctement.
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.
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.
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:
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.