Test de bootloader à distance

Niveau :
Résumé : ssh qemu-system -hda /dev/sda

Supposons que vous administriez une machine distante. Vous n'avez pas d'accès physique à cette machine. C'est ennuyant puisque vous venez de changer la configuration de votre bootloader.

Comment faire pour rebooter tout en garantissant que ca va marcher ?

Hé bien j'ai la solution qui vous permettra de tester ce boot avant de rebooter : qemu.

Préparer les disques

Il nous faut des disques en lecture seule pour éviter que le boot de la machine virtuelle n'écrive sur un disque en cours d'utilisation. Donc pour chacun de vos disques physique :

$ cp -a /dev/sda /root/sda
$ chmod 440 /root/sda

Ainsi nous avons des disques garantis en lecture seule.

Préparer son terminal

Nous allons enregistrer ce qui se passe sur le terminal, lequel va tourner en ncurses, il est donc important pour la lisibilité des logs de le dimensionner à la même taille que l'écran de boot, c'est-à-dire 80x25.

Modifiez la taille de votre fenêtre de terminal jusqu'à ce que les variables $COLUMNS et $LINES vaillent respectivement 80 et 25.

Préparer son bootloader

Quel que soit votre bootloader configurez le de façon à ce qu'il ne lance pas de mode graphique, sinon vous ne pourrez pas stocker les logs de ce qui se passe.

Choisit son qemu

Installez qemu. Puis en fonction du matériel à émuler choisissez qemu-system-i386 ou qemu-system-x86_64 ou une autre architecture si vous travaillez sur d'autres machines.

Lancer le tout

Préparez un 2e terminal pour tuer qemu , ca sera plus simple que d'attendre qu'il se termine proprement (killall qemu pour les impatients).

$ sync
$ ssh -t localhost "qemu-system-x86_64 -m 512 -curses -hda /root/sda" | tee logs

Pourquoi sync ? au cas où vous auriez fait des modification impactant le boot, on force l'écriture de celles-ci sur le disque.

Pourquoi ssh ? Pour profiter de l'option -t qui crée un terminal virtuel même lorsqu'on travaille dans un pipe.

Pourquoi tee ? Pour stocker les logs de ce qui se passe tout en gardant la main sur le clavier. Tout est tellement rapide qu'il peut y avoir des erreurs invisibles.

Pourquoi -m 512 (512Mo de ram): prenez une valeur inférieure à votre matériel mais malgré tout proche pour éviter les effets de bord.

Pensez à ajouter les disques dont vous pourriez avoir besoin selon le niveau de boot que vous voudriez tester.

Lire les logs

Bon, qemu s'est lancé, le boot a planté, mais vous n'avez pas eu le temps de voit l'erreur.

Commencez par tuer le qemu s'il vous gêne. Puis lisez les logs :

$ less -R logs

Pourquoi -R ? parce que cette option vous permet de ne pas traduire les caractères spéciaux que qemu écrit à travers ncurses et vous permet de voir le contenu des logs tels qu'ils sont apparus à l'écran.

Mode graphique

Si vous ne voulez pas de logs ou que vous ne pouvez pas empêcher le mode graphique de se lancer, vous pouvez faire sans. Dans ce cas, à vous de vous connecter à la machine de façon à ce qu'un serveur X soit accessible (par exemple avec ssh -X).

La commande devient alors :

$ sync
$ qemu-system-x86_64 -m 512 -hda /root/sda

PS : Et ça marche avec les outils de virtualisation comme xen.

Tags:planet-libre, Savoir-faire, Serveur