Peut être que vous avez remarqué, mais le serveur était down pendant quelques heure hier. J'ai voulu faire la fameuse mise à jour de  glibc, qui fût comme sur de nombreuse installation un véritable désastre monumentale. 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 perdu à jamais si je me déconnectait. Et bien évidement, je me suis déconnecté. A 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 plutot une machine virtuel libre qui permet d'émuler beaucoup de processeur, et d'architecture différente. Évidement ARM en fait partit. Je pense que vous comprenez ce que je veux faire, booter le système présent sur le clef usb du dockstar dans une VM depuis un autre PC.J'ai donc retirer la clef 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épots:

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 voila, 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 lancé cette commande, un écran virtuel devrait ce lancer avec le boot process qui défile jusqu'a 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'autre carte. Ensuite l'option -hda indique le disque dur principale, dans notre cas c'est la clef USB, donc /dev/sdb1 correspond à la partition ext2 du systeme Archlinux (et non /dev/sdb). L'option -kernel, pas très compliqué, indique le chemin du noyau téléchargé précédemment.

La magie la dedans c'est que si vous modifié quelque choses, c'est modifié sur la clef 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 !