Au secours, mon poste ne démarre plus !

Mercredi 14 août, 8h50. Je pars de chez moi de bonne humeur : la veille, avec Matthieu, nous avons enfin réussi à résoudre le bug qui nous bloquait depuis quelques jours.

À peine dix minutes plus tard j'arrive au bureau confiant. Je salue rapidement mes collègues, j'ouvre le clapet de mon ordinateur, et le démarre.

Et là, première surprise : Linux Mint se lance en mode sans échec. Etonné, je bouge ma souris pour cliquer sur le bouton redémarrer. Mais là, seconde surprise : la souris ne répond pas.

Ce seront là les premiers symptômes du problème qui m'amènera plus tard dans la journée à devoir réinstaller tout mon système d'exploitation.

Chez marmelab, chaque développeur est responsable de son poste de travail, pour le meilleur... comme pour le pire. J'ai appris grâce à cette histoire comment récupérer mes données les plus importantes (projets, configurations, codes d'accès), mais surtout comment éviter de les perdre à l'avenir.

Et comme il vaut mieux prévenir que guérir, j'ai décidé de partager ce que j'ai appris avec vous.

Le constat

Il existe mille raisons qui font qu'un ordinateur cesse de fonctionner du jour au lendemain. Rien qu'à marmelab nous en avons rencontré un bon paquet :

• Linux Mint qui ne redémarre pas après un passage en mode hibernation - Maxime
• Installation d'une nouvelle version de linux - Adrien
• Le fameux sudo rm -rf / - Kévin
• Son matériel qui lâche, ou quelqu'un qui lâche son matériel - Vous ?

Bien évidemment, la liste s'allonge rapidement après quelques recherches sur internet.

Quoi qu'il en soit, lorsqu'on fait face à un tel problème, et comme pour tout, il est nécessaire d'en comprendre la raison.

Sans souris, il ne me restait que le clavier. J'ai donc directement ouvert un terminal en tapant le raccourcis CTRL + ALT + T.

Suspectant un problème d'installation de Linux que j'avais mis à jour la veille avant de partir, j'ai consulté les logs de la commande apt. Ces derniers sont enregistrés dans le fichier /var/log/apt/term.log.

La piste à suivre pour détecter de possibles erreurs est de récupérer la version courante du noyau via la commande uname, puis de chercher d'éventuels problèmes dans les logs d'installation.

Je n'ai malheureusement pas conservé les données de mon ancien poste, mais voici le résultat de ces commandes lorsque je les lance sur mon système actuel :

adrien@amo-pc: ~$ uname -msr
Linux 5.0.0-36-generic x86_64

adrien@amo-pc: ~$ cat /var/log/apt/term.log | grep linux-image-5.0.0-36-generic
Sélection du paquet linux-image-5.0.0-36-generic précédemment désélectionné.
Préparation du dépaquetage de .../1-linux-image-5.0.0-36-generic_5.0.0-36.39~18.04.1_amd64.deb ...
Dépaquetage de linux-image-5.0.0-36-generic (5.0.0-36.39~18.04.1) ...
Paramétrage de linux-image-5.0.0-36-generic (5.0.0-36.39~18.04.1) ...
Traitement des actions différées (« triggers ») pour linux-image-5.0.0-36-generic (5.0.0-36.39~18.04.1) ...

À ce propos, la commande dpkg peut vous être utile puisqu'elle permet de lister les paquets installés.

adrien@amo-pc: ~$ dpkg --list | grep linux-image
...
rc  linux-image-4.15.0-65-generic              4.15.0-65.74                                amd64        Signed kernel image generic
rc  linux-image-4.15.0-66-generic              4.15.0-66.75                                amd64        Signed kernel image generic
ii  linux-image-4.15.0-70-generic              4.15.0-70.79                                amd64        Signed kernel image generic
...
ii  linux-image-5.0.0-32-generic               5.0.0-32.34~18.04.2                         amd64        Signed kernel image generic
ii  linux-image-5.0.0-36-generic               5.0.0-36.39~18.04.1                         amd64        Signed kernel image generic
ii  linux-image-generic                        4.15.0.70.72                                amd64        Generic Linux kernel image
ii  linux-image-generic-hwe-18.04              5.0.0.36.94                                 amd64        Generic Linux kernel image

Au final, l'étude des logs a confirmé mon intuition : le problème venait bien d'une mise à jour du système ratée. Ne restait plus qu'à réinstaller proprement le paquet en question.

L'astuce de la clef USB exécutable

J'ai naturellement commencé par lancer un petit sudo apt update, mais je n'ai pas vraiment aimé ce que j'ai vu.

Err :1 http://security.ubuntu.com/ubuntu bionic-security InRelease
  Ne parvient pas à résoudre « security.ubuntu.com »

W: Impossible de récupérer http://fr.archive.ubuntu.com/ubuntu/dists/bionic/InRelease  Ne parvient pas à résoudre « fr.archive.ubuntu.com »

W: Le téléchargement de quelques fichiers d'index a échoué, ils ont été ignorés, ou les anciens ont été utilisés à la place.

Pour faire simple : en mode sans échec ma carte réseau était coupée, et je n'ai pas trouvé le moyen de la réactiver. J'ai également essayé de brancher une clef usb qui contenant le paquet en question, mais elle n'était pas reconnue par le système.

Mon problème s'est donc complexifié puisqu'il fallait désormais que je puisse restaurer une version du noyau linux sans internet et accès externe à la machine.

Mon salut est venu de Kévin qui m'a aiguillé vers la bonne solution : utiliser une version live d'ubuntu installée sur une clef USB exécutable pour accéder au système depuis l'extérieur.

En effet, malgré un système d'exploitation bien endommagé, le disque dur était totalement fonctionnel. Rien ne nous empêchaît alors de lancer un second système d'exploitation sur la même machine, qui aurait pour unique but de réparer le système endommagé.

Pour les amateurs de Star Wars, c'est un peu comme lorsque R2D2 se branche au système d'un vaisseau pour redistribuer la puissance de ses moteurs.

La manipulation un peu spéciale que je viens de vous décrire se fait via le chrooting. Derrière ce nom barbare se cache une opération qui permet de changer le répertoire racine du processus courant. Elle s'effectue à l'aide de la commande chroot, qui signifie change root.

En suivant ces instructions, j'ai donc lancé les commandes suivantes sur ma machine :

ubuntu@ubuntu: ~$ mkdir mnt
ubuntu@ubuntu: ~$ sudo mount /dev/mint-vg/root /home/ubuntu/mnt
ubuntu@ubuntu: ~$ sudo chroot /home/ubuntu/mnt

Et voilà, la magie a opéré ! J'avais désormais accès à mon ancien disque dur, mais cette fois-ci avec un système d'exploitation sain, et bien sûr internet (la version live d'ubuntu n'étant pas en mode sans échec).

Adieu Linux Mint, bonjour Ubuntu

Malheureusement dans mon cas, j'ai vite été bloqué. En effet, linux n'acceptait pas que j'installe des dépendances système à cause de problèmes de droits insolubles 😢. Ayant déjà perdu deux bonnes heures, j'ai décidé de ne pas passer plus de temps à essayer de résoudre ce problème.

J'ai quand même réussi à sauvegarder l'essentiel : mes fichiers de conf aws, ssh, ainsi que pas mal de petits projets que je n'avais pas pris le temps de publier sur Github.

drwxr-xr-x  2 adrien adrien 4,0K août  19 15:34 .aws
drwx------ 26 adrien adrien 4,0K oct.  16 11:54 .config
-rwxrwxrwx  1 adrien adrien  363 août  20 14:50 .gitconfig
drwx------  3 adrien adrien 4,0K oct.   4 11:31 .ssh
-rwxrwxrwx  1 adrien adrien 2,0K sept. 17 09:48 .zsh_aliases
-rw-r--r--  1 adrien adrien 3,5K août  15 22:07 .zshrc

11h55. Tout est sauvegardé. Je lance alors l'installation d'ubuntu en cliquant, non sans trembler, sur le bouton Erase disk, and install ubuntu.

Ma pause repas a finalement été concacrée à la réinstallion de tout mon système, et j'ai pu reprendre un projet client dès l'après-midi. L'histoire se termine bien.

Conclusion

Tout cette histoire s'est passée il y a quelques mois, et même si j'en rigole aujourd'hui, j'étais assez stressé en découvrant l'état de mon ordinateur. Je ne savais pas ce qu'il se passait, ni combien de temps j'aurais besoin pour retrouver un système sain. Je pensais également devoir tirer un trait sur plusieurs fichiers de configuration sur mesure, mais aussi sur pas mal de petits projets non publiés.

Il faut être honnête, je ne m'étais pas préparé du tout à ça. Mais maintenant que ça m'est arrivé, j'ai bien pris la mesure du problème et on ne m'y reprendra pas.

Il s'agit d'un sujet qu'on néglige trop souvent. C'est pourquoi j'ai mis en place des stratégies pour pouvoir réinstaller facilement mon poste.

Et ça tombe bien car nous en parlerons dans un prochain article.

Bonus