Ubuntu Server : upgrade de 7.10 en 8.04
En Ubuntu version desktop, càd graphique, il est simple de passer d’une version à l’autre : l’update manager vous signale automatiquement l’existence d’une nouvelle version d’Ubuntu et il suffit de quelques clicks souris pour lancer la mise à jour.
En version serveur, vous êtes en console en mode texte et Ubuntu ne vous proposera pas automatiquement cette nouvelle version.
Mumbly nous donne la solution dans ce billet.
Je vais détailler un peu cette mise à jour serveur en console.
Les 2 commandes à passer sont simples :
sudo aptitude install update-manager-core
Il est possible que l’update-manager-core soit déjà installé. Sur mon serveur, il l’était. 
$ sudo do-release-upgrade Checking for a new ubuntu release Done Upgrade tool signature Done Upgrade tool Done downloading extracting '/tmp/tmpRAQEVW/hardy.tar.gz' authenticate '/tmp/tmpRAQEVW/hardy.tar.gz' against '/tmp/tmpRAQEVW/hardy.tar.gz.gpg' Lecture du cache Vérification du gestionnaire de paquets Continuer dans une session SSH ? Il semble que vous soyez dans une session SSH. Il n'est pas recommandé actuellement d'effectuer une mise à niveau via SSH car une réparation sera plus difficile en cas d'erreur. Si vous continuez, un démon SSH supplémentaire sera lancé sur le port « 9004 ». Voulez-vous poursuivre ? _Continuer [oN]
Pas conseillé… oui… mais pour un serveur, on n’a pas toujours le choix.
Dans mon cas, je pourrais descendre à la cave faire cette upgrade en console. Je vais quand même le faire à “distance” en SSH. Je continue donc. Je présume que le port 9004 est une session SSH de secours en cas de problèmes.
Remarque : je me complique la tâche, car j’utilise en fait “apt-cacher” qui est un cache local sur … ce serveur lui-même !
Cela m’évite de faire les téléchargements pour les mises à jour 4 fois de suites pour nos 3 PC et le serveur.
_Continuer [oN] O Lancement d'un processus sshd supplémentaire Pour faciliter la réparation en cas d'erreur, un démon sshd supplémentaire sera lancé sur le port « 9004 ». Si quelque chose se passe mal avec la session ssh actuelle vous pourrez toujours vous connecter avec l'autre. Reading package lists: Done Reading state information: Done Reading state information: Done Reading state information: Done Done http://127.0.0.1 gutsy Release.gpg Done http://127.0.0.1 gutsy-updates Release.gpg Done http://127.0.0.1 gutsy-security Release.gpg Hit http://127.0.0.1 gutsy Release Done http://127.0.0.1 gutsy Release Done http://127.0.0.1 gutsy-updates Release Done http://127.0.0.1 gutsy-updates Release Hit http://127.0.0.1 gutsy-security Release ...
Done downloading Reading package lists: Donerity/multiverse Packages: 98 Reading state information: Done Reading state information: Done Reading state information: Done Mise à jour des informations sur les dépôts Aucun miroir valide trouvé Aucune entrée de miroir pour la mise à niveau n'a été trouvée lors de l'examen des informations de votre dépôt. Ceci peut se produire lorsque vous utilisez un miroir interne ou si les informations sur le miroir sont obsolètes. Souhaitez vous que votre « sources.list » soit malgré tout récrit ? Si oui, cela mettra à jour toutes les entrées « gutsy » vers « hardy ». Si vous cliquez sur « Non », la mise à jour sera annulée. _Continuer [oN]
J’accepte donc et je continue (et si ça plante, je descendrai dans ma cave…)
Done http://127.0.0.1 hardy Release.gpg Done http://127.0.0.1 hardy-updates Release.gpg Done http://127.0.0.1 hardy-security Release.gpg Done http://127.0.0.1 hardy Release ...
Done downloading
Vérification du gestionnaire de paquets Reading package lists: Donerity/multiverse Packages: 98 Reading state information: Done Reading state information: Done Reading state information: Done
Calcul des modifications
Voulez-vous commencer la mise à niveau ?
1 paquet va être supprimé. 21 nouveaux paquets vont être installés. 288 paquets vont être mis à jour.
Vous devez télécharger un total de 185M. Ce téléchargement prendra environ 3 minutes avec votre connexion.
La récupération et l'installation de la mise à niveau peuvent prendre plusieurs heures. Un fois le téléchargement terminé, l'opération ne peut plus être annulée.
_Continuer [oN] Détails [d] o
Récupération Done http://127.0.0.1 hardy/main libc6 2.7-10ubuntu3 Done http://127.0.0.1 hardy/main libc6-i686 2.7-10ubuntu3 ...
Done downloading Mise à niveau Done downloading Extraction des modèles depuis les paquets : 100% Préconfiguration des paquets... (Lecture de la base de données... 24339 fichiers et répertoires déjà installés.) Préparation du remplacement de libc6 2.6.1-1ubuntu10 (en utilisant .../libc6_2.7-10ubuntu3_i386.deb) ... Dépaquetage de la mise à jour de libc6 ... ...
Voilà, l’upgrade d’Ubuntu Server 7.10 vers 8.04 est terminé.
Juste quelques questions à répondre (en général des fichiers de configuration modifiés), et surtout attendre… Même dans cette configuration serveur qui contient moins de programmes qu’une installation normale avec Gnome, la mise à jour à quand même pris environ 1h15.
Tout s’est bien passé, à l’exeption du serveur Web Apache2 qui n’a pas redémarré correctement. Problème assez vite trouvé : j’avais un peu bricolé la configuration de phpMyAdmin, et après la mise à jour Apache2 essayait de démarrer un membre de configuration qui n’existait pas (un lien symbolique pointant vers un fichier non existant).
Je suppose que c’est la mise à jour du paquet phpMyAdmin avec ma configuration non standard qui a posé problème.
Problème très mineur donc. Et même le cache local “apt-cacher” n’a pas posé de problème lors des téléchargement de paquets.
Tout semble ok : Apache2, mySQL, Munin, NTP, SSH fonctionnent… Mon blog répond puisque je complète ce billet. Les serveurs web aussi. Et les statistiques Munin ont bien redémarrées.;-)