utiliser Qemu pour réparer un Archlinux

Peut-être que vous avez remarqué, mais le serveur était down pendant quelques heures hier. J'ai voulu faire la fameuse mise à jour de glibc, qui fut comme sur de nombreuses installations un véritable désastre monumental. Bref le malheur étant fait, le dossier lib/ complètement vidé, je n'avais accès à aucune commande, et donc ma connexion ssh qui était encore présente serait perdue à jamais si je me déconnectais. Et bien évidemment, je me suis déconnecté. À partir de là, je ne pouvais plus accéder au DockStar que par le port série et pour ça il fallait l'éteindre etc... bref j'ai voulu tenter autre chose.

C'est là que Qemu intervient.

Qemu est un émulateur, ou plutôt une machine virtuelle libre qui permet d'émuler beaucoup de processeurs, et d'architectures différentes. Évidemment ARM en fait partie. Je pense que vous comprenez ce que je veux faire, booter le système présent sur la clé USB du DockStar dans une VM depuis un autre PC. J'ai donc retiré la clé USB du DockStar où est installé ArchLinux ARM pour la brancher sur mon PC. Ensuite il faut récupérer Qemu, avec Archlinux il est dans les dépôts :

sudo pacman -Sy qemu

Ensuite il faut récupérer le kernel qui va bien, un kernel zImage fera l'affaire :

wget http://jcapik.fedorapeople.org/files/ARM/Qemu/zImage-qemu-versatile-3.0.8-4.fc17.armv5tel

Et voilà, il suffit de faire un mélange de tout ça pour lancer qemu :

qemu-system-arm -M versatilepb -hda /dev/sdb1 -kernel /home/yadomi/VM/zImage-qemu-versatile-3.0.8-4.fc17.armv5tel

Lorsque vous lancez cette commande, un écran virtuel devrait se lancer avec le boot process qui défile jusqu'à arriver au prompt de login.

L'option -M permet de définir la famille ARM, la Versatile Product Family qui correspond au DockStar et à bien d'autres cartes. Ensuite l'option -hda indique le disque dur principal, dans notre cas c'est la clé USB, donc /dev/sdb1 correspond à la partition ext2 du système Archlinux (et non /dev/sdb). L'option -kernel, pas très compliquée, indique le chemin du noyau téléchargé précédemment.

La magie là-dedans c'est que si vous modifiez quelque chose, c'est modifié sur la clé aussi puisqu'il travaille dessus. Bref, c'est bien plus pratique que d'essayer de faire un chroot entre ARM et x86_64... Il existe aussi une option, -nographic, qui permet de désactiver l'écran virtuel et transmettre le tout vers un tty, il suffit ensuite d'utiliser screen ou minicom pour communiquer !