PrettyOS startet nur emuliert

anscheinend ist der bootloader noch nicht so ausgereift.

es funktioniert immernoch nicht.

Da steht einfach "Loading Second Stage Bootloader...", dann springt der curser zweimal nach unten, danach seht da noch was, was nich nicht lesen kann, weils so schnell weg ist, danach bootet grub normal (hab dualboot).

ich hab die lösung gefunden.

bisher hab ich das image qemu immer als floppy angegeben ("-fda FloppyImage.img")

jetzt hab ich das image mal als usb-stick emuliert ("-usb FloppyImage.img")

und siehe da, hier ist wohl der fehler, qemu meldet:

qemu-system-i386 -usb FloppyImage.img schrieb:

Booting from Hard Disk...
Loading Second Stage Bootloader...
**************
BOOT2.BIN missing

was sagt ihr?

Mr X

Interessant.

In der Datei /documentation/test-results.txt sind einige Rechner aufgeführt, die Boot-Probleme von USB-Sticks und USB-Floppylaufwerken aufweisen.

Es gibt welche, die booten danach von der Festplatte weiter. Und es gibt welche, die melden BOOT2.BIN als fehlend. Hab das bisher für verschiedene Symptome für das gleiche Problem gehalten.

Nun jedenfalls habe ich einen PC, der vorher das Windows nach Stage 1 bootete getestet: Da geht es nun! Einen Fehler sind wir also los.

Das Qemu das gleiche Problem mit -usb zeigt, wie deine beiden echten Rechner, ist nicht gesagt. Nach der BOOT2-Meldung sollte er aber auf einen Tastendruck warten, und danach resetten.

Mr X schrieb:

Interessant.

In der Datei /documentation/test-results.txt sind einige Rechner aufgeführt, die Boot-Probleme von USB-Sticks und USB-Floppylaufwerken aufweisen.

Es gibt welche, die booten danach von der Festplatte weiter. Und es gibt welche, die melden BOOT2.BIN als fehlend. Hab das bisher für verschiedene Symptome für das gleiche Problem gehalten.

Nun jedenfalls habe ich einen PC, der vorher das Windows nach Stage 1 bootete getestet: Da geht es nun! Einen Fehler sind wir also los.

Das Qemu das gleiche Problem mit -usb zeigt, wie deine beiden echten Rechner, ist nicht gesagt. Nach der BOOT2-Meldung sollte er aber auf einen Tastendruck warten, und danach resetten.

ok, gut das problem ist anscheinend bekannt.

aber was ist da der grund? ich mein, anscheinend tritt der fehler "zufällig" auf?

also bei mir wartet der bootloader nicht auf tastendruck. auf beiden pc (64-bit und 32-bit) startet einfach das betriebssystem.

Mr X

also bei mir wartet der bootloader nicht auf tastendruck. auf beiden pc (64-bit und 32-bit) startet einfach das betriebssystem.

Dann würde ich behaupten, dass die Meldung BOOT2.BIN missing auch nicht angezeigt wurde. Dieses Problem wird meines Erachtens nach durch die o.g. Änderungen gelöst, zumindest auf einem System bei mir.

Mr X schrieb:

also bei mir wartet der bootloader nicht auf tastendruck. auf beiden pc (64-bit und 32-bit) startet einfach das betriebssystem.

Dann würde ich behaupten, dass die Meldung BOOT2.BIN missing auch nicht angezeigt wurde. Dieses Problem wird meines Erachtens nach durch die o.g. Änderungen gelöst, zumindest auf einem System bei mir.

ich habe jetzt nochmal die "originale" rev 1407 gedownloaded und das vorkompilierte image mit qemu als usb emuliert.

ich diesem fall gibt qemu aus:

Booting from Hard Disk...
Loading Second Stage Bootloader...
Boot failed: could not read the boot disk

die sache wird ja immer seltsamer

Mr X

Die bisherigen Korrekturen am Bootloader sind nun in Rev. 1408 auch im SVN.

XanClic

Zu der new-Sache…

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.

Es liegt mir fern zu behaupten, ich würde viel von C++ verstehen, aber intuitiv hätte ich behauptet, dass new einfach mal ein size_t nimmt, wie malloc halt auch.
Und wenn ich so in den C++0x-Standard gucke, steht unter 18.6.1.1 (Language support library → Dynamic memory management → Storage allocation and deallocation → Single-object forms) folgendes:

void* operator new(std::size_t size);

Weiß ja nicht, ob es irgendwas ändert, wenn mans so macht, wie es da steht.

Mr X

Es liegt mir fern zu behaupten, ich würde viel von C++ verstehen, aber intuitiv hätte ich behauptet, dass new einfach mal ein size_t nimmt, wie malloc halt auch.

Ich habe darüber auch nachgedacht. Probieren könnte man es sicher mal - aber ich erinnere mich dunkel, dass wir es mal so hatten... Außerdem - es scheint sich ja auch die zugrundeliegende size_t-Definition ständig zu ändern - ich fürchte, dann müssten wir die halt ständig anpassen.

cooky451

Nicht mit C++11. Falls das funktioniert:

typedef decltype(sizeof(int)) size_t;