PrettyOS startet nur emuliert



  • Hallo,

    da man ja anscheinend als unregistrierter Nutzer nichts im PrettyOS-Forum schreiben kann (ganz toll gemacht ­čÖä), schreib ich das halt hier.

    Ich wollte mal nachfragen, wie man PrettyOS auf einem "echten" Computer gestartet bekommt.

    Ich hab bisher die floppy-Datei (zu finden im PrettyOS Ordner: /prettyos/trunk/Source/) ├╝ber qemu ( qemu-system-i386 -fda FloppyImage.img ) gestartet, was auch immer gut funktioniert hat, sogar Internetverbindung usw., es funktioniert auch auf einer 64-bit Emulation ( qemu-system-x86_64 -fda FloppyImage.img ), alles kein Problem.

    Nun wollte ich das ganze mal richtig starten.

    Also Linux hochgefahren, USB-Stick an Computer und sudo dd if=./FloppyImage.img of=/dev/sda1 eingegeben, wobei /dev/sda1 die USB-Devicedatei ist.

    Danach Computer neugestartet und im Bootmen├╝ den USB-Stick ausgew├Ąhlt. Danach kam kurz eine Meldung wo irgendwas mit Bootloader stand, dann ist seltsamerweise mein normales Betriebssystem hochgefahren, da war irgendein Fehler.
    Zuerst dachte ich, das Ganze liegt daran, dass ich einen 64-bit Computer habe, aber das kanns nicht sein, ich habs n├Ąmlich auch auf einem anderen Computer, der 32-bit ist, ausprobiert, da war der gleiche Fehler.

    P.S.: Nein, diesen Thread bitte nicht ins PrettyOS-Forum verschieben, weil da kann ich ja wie gesagt nichts posten. Besser w├Ąre es, ihr w├╝rdet endlich das Forum f├╝r alle freischalten.



  • USB-Sticks funktionieren nur mit viel Gl├╝ck. Als ich das versucht habe, konnte ich nur die wenigsten PCs ├╝berreden, vom USB-Stick zu booten, aber auf einem ging es dann doch. Du k├Ânntest Legacy-USB-Support im BIOS aktivieren, vielleicht hilfts.

    Wenn Du echte Disketten und ein entsprechendes Laufwerk hast, versuchs damit.



  • Mr X schrieb:

    USB-Sticks funktionieren nur mit viel Gl├╝ck. Als ich das versucht habe, konnte ich nur die wenigsten PCs ├╝berreden, vom USB-Stick zu booten, aber auf einem ging es dann doch. Du k├Ânntest Legacy-USB-Support im BIOS aktivieren, vielleicht hilfts.

    Wenn Du echte Disketten und ein entsprechendes Laufwerk hast, versuchs damit.

    Ich hab keine Disketten mehr.

    Aber warum ist das abh├Ąngig vom USB-Stick? Dem Bootloader m├╝sste es eigentlich egal sein, von welchem Medium er gestartet wird, denn ich schreibe ja mit dd eine bitgenaue Kopie des Image auf den USB-Stick, d.h. der eigentliche Bootloader bleibt unver├Ąndert und m├╝sste eigentlich starten.

    Wie l├Ąsst sich das Problem l├Âsen?

    Und warum werden nicht-registrierte User aus dem PrettyOS-Forum ausgeschlossen?



  • Bis wohin kommt der Bootloader denn? (Was ist die letzte Ausgabe, falls Du die sehen kannst)



  • Mir ist ├╝brigens gerade eine Idee gekommen, was vielleicht das Problem ist. Dooferweise muss ich erstmal einen Weg finden, das Problem m├Âglichst ohne USB-Stick zu reproduzieren.



  • Loading second stage bootloader...



  • Das unterst├╝tzt meine Theorie:
    Im Stage1-Bootloader nutzen wir noch brav die Nummer des Bootdevices, die uns das BIOS ├╝bergeben hat. Dem Stage2-Bootloader wird diese zwar ├╝bergeben, aber er nutzt sie nicht, stattdessen wird stets 0 genommen. Das trifft auf den meisten Systemen zu (dort, wo das erste Floppy-Laufwerk genommen wird), nicht aber z.B. auf (den meisten) Systemen mit USB-Stick.

    Geh mal nach /stage2_bootloader/boot2.asm und schreib in die Funktion entry_point: folgendes:

    mov BYTE [DriveNum], dl
    

    Wenn es dann funktioniert...



  • ich hab vorher das vorkompilierte image genommen.

    wenn ich prettyos auf linux kompilieren will mit
    sh ./build.sh

    kommt irgendwann der fehler

    nasm kernel/data.asm -Ox -f elf -Ikernel/ -o object_files/kernel/data.o
    kernel/data.asm:15: error: `incbin': unable to open file `user/vm86/VIDSWTCH.COM'
    kernel/data.asm:18: error: `incbin': unable to open file `user/vm86/APM.COM'
    make: *** [object_files/kernel/data.o] Fehler 1

    ­čśĽ



  • Welche PrettyOS-Revision?



  • Mr X schrieb:

    Welche PrettyOS-Revision?

    die allerneuste: http://prettyos.svn.sourceforge.net/viewvc/prettyos.tar.gz?view=tar



  • Die allerneuste uralte. Der Link verweist auf das alte Repository. (Siehe hier: http://www.c-plusplus.net/forum/310029)

    Und in der wirklich neusten Revision ist das Build-Problem unter Linux behoben.



  • Mr X schrieb:

    Die allerneuste uralte. Der Link verweist auf das alte Repository. (Siehe hier: http://www.c-plusplus.net/forum/310029)

    Und in der wirklich neusten Revision ist das Build-Problem unter Linux behoben.

    zum gl├╝ck aktualisiert ihr immer eure FAQ, besonders die oberste. ­čśĽ

    gibts ne m├Âglichkeit, den ganzen "trunk/Source" ordner runterzuladen? ohen svn? ich hab keine ahnung wie das geht und grad keine lust, irgendwas zu googlen.



  • hm. Anscheinend nicht. Zumindest finde ich keine Tarball-Option auf Sourceforge (https://sourceforge.net/p/prettyos/code/1407/tree/)

    zum gl├╝ck aktualisiert ihr immer eure FAQ, besonders die oberste. ­čśĽ

    Danke f├╝r den Hinweis - da ist tats├Ąchlich ein Link nicht aktualisiert worden. Wird sobald m├Âglich ge├Ąndert (bzw. entfernt, wenn niemand den "Download Tarball"-Button findet.)



  • Ich f├╝rchte, es wird dir nichts anderes ├╝brig bleiben, als dir SVN zu besorgen und es damit herunterzuladen.



  • Mr X schrieb:

    Ich f├╝rchte, es wird dir nichts anderes ├╝brig bleiben, als dir SVN zu besorgen und es damit herunterzuladen.

    ok, wie ist der aufruf? bestimmt irgend so ein "clone repository" wie bei git oder so

    p.s.: also z.b. bei git ist es so, dass man ├╝ber ein webinterface eine zip runterladen kann, aber anscheinend gibts das hier nicht.



  • habs selbst herausgefunden:
    svn checkout http://svn.code.sf.net/p/prettyos/code ./

    jetzt werd ich mal die zeile ausbessern und kompilieren.



  • serlib_cpp.cpp:10:42: Fehler: ┬╗operator new┬ź nimmt Typ ┬╗size_t┬ź (┬╗unsigned int┬ź) als ersten Parameter [-fpermissive]
    userlib_cpp.cpp:14:44: Fehler: ┬╗operator new┬ź nimmt Typ ┬╗size_t┬ź (┬╗unsigned int┬ź) als ersten Parameter [-fpermissive]
    make[1]: *** [userlib_cpp.o] Fehler 1
    make: *** [userlibs] Fehler 2

    findet ihr das etwa lustig?



  • Nunja. GCC/Clang ├Ąndern mit jedem Release ihre Definition des new-Operators. Pass es manuell an das an, was dein GCC will. Wenn Du uns deine GCC oder Clang-Version nennst, k├Ânnen wir eine zus├Ątzliche #ifdef-Weiche f├╝r diese Version anlegen.



  • Mr X schrieb:

    Nunja. GCC/Clang ├Ąndern mit jedem Release ihre Definition des new-Operators. Pass es manuell an das an, was dein GCC will. Wenn Du uns deine GCC oder Clang-Version nennst, k├Ânnen wir eine zus├Ątzliche #ifdef-Weiche f├╝r diese Version anlegen.

    GCC-Version:
    gcc-Version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1)

    Wobei ich glaube, dass es mittlerweile schonwieder eine neue GCC-Version gibt.

    Warum braucht ihr ├╝berhaupt C++? Linux hats vorgemacht, C w├╝rde im Grunde reichen!



  • GCC-Version:
    gcc-Version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1)

    Das ist seltsam, weil wir (auf Windows) ebenfalls GCC 4.7.2 einsetzen. Dann ├Ąndere halt lokal den Prototypen, sodass es kompiliert. Oder nimm Clang, dass ist eh der bessere Compiler ­čśâ

    Warum braucht ihr ├╝berhaupt C++? Linux hats vorgemacht, C w├╝rde im Grunde reichen!

    Userprogramme. Und im Nachhinein w├╝rde ich sagen, dass C++ im Kernel auch ganz praktisch gewesen w├Ąre. Konstruktoren und Desktruktoren sind eben doch komfortabler als irgendwelche delete_console(console_t* c);-Funktionen.


Log in to reply