**Installation d'une image raw sur un serveur dédié.**
Bonjour la communauté OVH,
Je travaille sur un projet de création d'un "**Hello World**" en mode serveur 64 bits.
Comme c'est une question un peu complexe je me suis permis de faire une vidéo visible ici : Vidéo explicative si vous voulez en savoir plus.
**Après continuons sur la question:**
Ce que je tente de faire c'est d'installer une image bootable sur le serveur. C'est celle qui se lance dans la vidéo avec la commande **qemu-system-x86_64 $(QEMUKVM) -serial mon:stdio -hda out/Taurifs2.img -smp $(CPUS) $(QEMUNET) -m 1024 -no-reboot**.
Bien sur, avant de me lancer dans l'opération j'ai bien lue la documentation fournie par OVH.
Le fichier raw est constitué d'un MBR, stage1, un FileSystem qui contient l'OS, executables, fichiers utiles pour faire fonctionner cet OS. En théorie il y'a tout pour démarrer sur une vrai machine.
Maintenant lorsque je tente de le charger sur le serveur dédié j'ai ce message:
En première intention j'ai ouvert un ticket, mais il est évident que cela dépasse les compétences du support (je ne leur jette pas la pierre, c'est vraiment une question complexe). Donc je me tourne vers la communauté, voir si quelqu'un à déjà tenté cela. Apparemment il n'existe aucune information sur le format attendue ni de tutorial.
Merci de votre retour.
55066 
19.11.2016 12:11
Bonjour,
Comment avez-vous créé votre image ?
Bonjour,
parfois poser la question permet de trouver la réponse.
Alors comment je fait:
Après je crée une structure fichier qui contient l'arborescence avec le kernel, executables les fichiers divers (ico, png, txt, html, css, jpg, ...), la base de donnée, les dossiers utilisateurs, etc.
Je passe tout ça dans un executable qui assemble dans un fichier raw les secteurs (512 octets) avec les 3 stages et qui crée le Filesystem avec l'arborescence.
Puis j'inscris dans la Partition table les informations. C'est là que je me suis dit: peut-être qu'il test la validité de la partition, et probablement que les octets 511 et 512 valent 0x55, 0xAA.
Donc j'ai retravaillé cette partie et miracle c'est passé. C'était bien le sens de ma première question: Quel format attendue? Comme je travaille sur un nouvel OS j'ai utilisé cette zone pour mes besoins. Heureusement j'avais à peu près suivie le standard donc la modification a été légère.
Bon maintenant sur une vrai machine l'OS ne se lance pas. Faut que je continue les tests.
Bonjour,
Si vous choisissez le format raw, le fichier doit correspondre à ce qui se trouve sur le disque de la machine. SI vous lancez parted Taurifs2.img, il doit voir votre table des partitions, c'est ce test qui est effectué à l'installation. C'est étonnant que l'image fonctionne avec QEMU mais ne contienne pas de table des partitions.
Bonjour,
si si y'a bien une partition table sur mon projet. Sauf qu'au début je l'avais un peu adapté a mes besoins. Je l'ai remis d'équerre avec le standard et effectivement l'image s'installe.
Maintenant il crash au boot. Je pensais que si QEMU sait traiter une véritable machine saurait aussi, mais c'est pas le cas.
Pour le moment je sais que le stage0 passe, le stage1 fonctionne juste avant le passage 16/32 bits. Chaque essai c'est 15 minutes au moins ...
Je continue, je vais mettre une trace dans le stage2 et ensuite voir s'il enchaine sur le kernel.
Bonjour et bonne année 2025.
Pour continuer le sujet, après pas mal d'essais et de galères je boot sur le serveur avec stage0, stage1, stage2 et lancement d'un main en 64 bits.
J'ai refait complètement le bootloader. Sur une machine réel le placement du gdt et le système de lecture des secteurs fonctionne sur QEMU mais pas sur le hard.
Alors ce n'est pas mon OS encore vraiment, juste un bon test. Je récupère le magic et le mbi sur l'OS 64 bits. Donc le multiboot est OK.
Maintenant je vais remettre tous le code. Suite bientôt.
C'est bien velu comme projet !
Pour continuer sur le sujet, enfin j'ai réussi a trouver tous les bugs. Il y'a vraiment un décalage entre une émulation par QEMU et de vrai machines. Je ne parle pas des bugs sur les processeurs, qui fait que ce qui est autorisé par la doc ne fonctionne pas. Donc y'a qu'une seule façon de gérer les disques au boot.
Maintenant j'ai un bootloader complet et il lance bien un kernel 64 bits de test. Prochain boulot réintégrer tout ça dans mon projet.
Ici c'est en mode texte mais il sait gérer les différents modes graphiques VGA.
Est-ce que le code sera libre et distribué sur une plate-forme du type GitHub ? Ça pourrait peut-être utile pour d'autres clients.
Le code de la partie user sera probablement libre. Pour le moment je monte un système sécurisé et il faudra voir si la partie boot et kernel doit être protégée (je pense que oui si le produit deviens commercial).
Mais, comme j'ai pris la plupart du code sur GitHub il est déjà présent! Pour ceux qui sont assez curieux pour aller plonger leur nez dans toute cette masse de code vous pouvez faire votre propre OS.
Mon expérience est que 90% du code présent ne fonctionne pas correctement. Soit ça ne compile pas, soit il existe des bugs grossiers ou c'est vraiment trop léger. Vue que les IA sont scanné tout ça, je suis persuadé que notre métier n'est pas prêt d'être remplacé par une IA.
C'est une petite victoire, vue que je travaille sur le sujet que quand je ne travaille pas pour d'autres entreprises:
Enfin le contrôleur ATA fonctionne en 64 bits, sur QEMU, VirtualBox et sur le serveur d'OVH. Il ne fonctionne pas sur mon Lenovo local mais c'est moins grave.
Il reste que le serveur a 32 Go de RAM et je les voie pas sur la carte e820. Là je détecte 0 à 8B000 et 10000 à 7DCA8000 (ce qui est logique) et 0? 80000000. Faudra que je change le mapage du kernel si je veux gérer plus que 4Go.