Ubuntu Server Karmic Koala et Dedibox
Certains d’entre vous l’on peut être remarqué, le serveur, et donc par conséquent le blog, était indisponible depuis très tôt ce matin (depuis environ 01h00) jusqu’à très tard ce matin (jusqu’à environ 11h45). La cause, j’ai tenté de migrer la Dedibox, qui était sous Ubuntu 9.04, vers Ubuntu 9.10. Malheureusement, j’ai pensé que la migration allait se passer comme toutes les autres fois. Mais ça n’a pas été le cas comme vous avez pu vous en douter. Donc pour la mémoire (et m’obliger à prendre plus d’informations auparavant) et pour ceux qui tomberaient dans le piège également, voilà comment procéder pour garder son serveur fonctionnel.
On a correctement mis à jour votre installation de Ubuntu Server via les commandes suivantes :~$ sudo aptitude update
~$ sudo aptitude full-upgrade
~$ sudo aptitude install update-manager-core
~$ sudo do-release-upgrade
Là tout est à jour, mais on a le malheur (qui a été le mien) de redémarrer après avoir remplacé dans le fichier menu.lst de GRUB les :root=UUID=4564577843545963533
par des :root=/dev/sda2
Manque de chance, le serveur ne veut pas booter quand même. Et ceci est dû au kernel utilisé par la Dedibox. Pour remédier à cela, il faut installer le kernel proposé dans les dépôts de Ubuntu. Immédiatement, on démarre le système de secours. Pour accéder à ce mode, on passe par l’interface d’administration, puis Système de secours et on clique Passer votre serveur en mode de secours. La machine est ainsi électriquement redémarrée et les identifiant / mot de passe du compte SSH nous sont donnés.
Préparons le terrain
Une fois connecté en SSH, on arrive sur un terminal sans privilèges d’administration. On va donc se les donner en utilisant le mot de passe qui nous a été fournis.~$ sudo su -
Maintenant, on va monter les partitions pour déterminer vraiment d’où vient le souci et dans notre cas installer le kernel qui va bien. Pour cela, on utilise les commandes mount et chroot.~# mkdir server
~# mount /dev/sda2 server
~# mount /dev/sda1 server/boot
~# mount --bind /proc server/proc
~# mount --bind /sys server/sys
~# mount --bind /dev server/dev
~# chroot server
À ce stade, on est sur notre serveur. On peut donc y effectuer les opérations nécessaires.
Réparons
Comme je l’ai dit plus haut, pour réparer les dégâts, il faut utiliser le kernel générique à la place du kernel Dedibox. On installe alors le paquet linux-server.root@serveur sudo aptitude update
root@serveur sudo aptitude full-upgrade
root@serveur sudo aptitude install linux-server
On oublie surtout pas de remplacer le root=UUID=… par root=/dev/sda2 dans le fichier menu.lst de GRUB et voilà, la réparation est faite.
Chouette, ça marche !
La réparation est terminé, on peut revenir sur une utilisation normale du serveur. Cependant, il faut prendre soit de terminer tous les processus que l’on a lancé en chroot et de démonter toutes les partitions.root@serveur exit~# umount server/proc
~# umount server/sys
~# umount server/dev
~# umount server/boot
~# umount server
~# exit
~$ exit
Pour finir, on retourne dans la console d’administration Dedibox et on clique sur Cliquer ici pour repasser en mode normal. Et là, le boot devrait se faire sans aucun souci. Conclusion, il ne faut pas se précipiter et se dire que tout réinstaller est la seule solution. Ici, on a réparé le tout sans perte de données mais par contre il y a eu un downtime (et un long pour moi, je tiens à m’en excuser d’ailleurs). C’est après avoir été dans ce genre de situations, que l’on se dit que GNU/Linux c’est quand même vachement bien. Mais ce n’est pas une raison pour faire n’importe quoi !
Sources
