How to set up develop and test environment (QEmu) on Ubuntu

[cyberkoa]

Hi ,
My question should be simple just that I do not have experience on QEmu and OS development.

I have followed the Wiki and manage to compile the ReactOS 2.9 (since SVN is broken, I get a working one) .

Now my question is , I don't really understand the make targets in the Wiki .

My objective is

1. Run the ReactOS that I compiled using Qemu .
2. Modify the source to do testing
3. Compile again
4. Run the modified version of ReactOS

How should be the make procedure ?
Thanks in advanced

[oiaohm]

Right This is not that complex.

You need a few minor things.

A mingw32 complier envorment.

Build instruction are in the wiki. ubuntu been debian relelated might have it in options to download.
I use bash on my termals
ROS_PREFIX=i386-mingw32 make bootcd
ROS_PREFIX=i386-mingw32 make livecd
Change the i386-mingw32 to what ever suits your mingw install.
Minor changes I just make a livecd and test there.

qemu -dummy-net --cdrom livecd.iso -boot d
This runs the iso.

To use the bootcd will install.
You need a make drive image. This is normall done with dd command
dd if=/dev/zero of=disk.img bs=1g count=1.

Ok that is a little large that is a 1g image.
qemu -dummy-net -hda disk.img -cdrom bootcd.iso -boot d
Go threw install.
Then to use.
qemu -dummy-net -hda disk.img -boot c
Its not that complex. Setting is a pain.

[cyberkoa]

thx for the guidance, I manage to make those ISO but when I try to run , it shows blue screen and gives error "INACCESSIBLE_BOOT_DEVICE" for both livecd and bootcd (with image file created after using dd)

i change the qemu command a bit where -dummy-net -> net none because my qemu do not recognise -dummy-net option.

I use i586-mingw-msvc instead of i386 because I compile the source following the Wiki instruaction

I do try to run the with sudo , and su but not successful also.

I search the forum on this problem , one thread in 2005 Jan recommend downgrade the binutil .. I am not sure whether is this problem or not ?

FYI , my system is
1) AMD Athlon XP
2) 1 LG CD-writer and 1 BenQ DVD writer (<-could it bcos of the DVD ?)
3) version of i586-mingw-msvc is 3.4.2



Result of df in my system

Filesystem Size Used Avail Use% Mounted on
/dev/hda2 144G 21G 116G 16% /
tmpfs 253M 0 253M 0% /dev/shm
tmpfs 253M 13M 240M 5% /lib/modules/2.6.12-10-386/volatile
/dev/hda1 43G 32G 12G 73% /media/hda1

hda2 is Ubuntu Linux
hda1 is WinXP Pro

CD is /dev/hdb
DVD is /dev/hdc

[oiaohm]

qemu -dummy-net --cdrom livecd.iso -boot d

Ok I typoed

qemu -net none -cdrom livecd.iso -boot d
-dummy-net is the old option for -net none. Opps sorry. and I double - the cdrom.

This should work.

Now the disk.img file is to provide a place to install. Ie blank. The dd command is a way of creating a large blank file.
Until the boot cdrom is used to format and install on it. It will not boot and give that error message from qemu until boodcd is used.

Rule that out before diging into binutils. I have used versions of binutils all over the place and had the .iso work. And many versions not supported by the core developers or mingw.

The livecd .iso should work with out a disk image and the bootcd should work without a diskimage but not be able to install.

qemu -net none -cdrom livecd.iso -boot d
qemu -net none -cdrom bootcd.iso -boot d

Both should run and work to a point. Ie bootcd will not be able to install no harddrive image. You should be able to play with the reactos live cd unless something has gone really wrong in the build. Ie if the live cd works and the boot cd build most things are good.

As long a qemu is working you hardware is not important.
qemu is a contained envorment.

The disk image is require if you wish to test programs to make sure they work with reactos.

Little explaination of what that dd command is doing.

if is in file. /dev/zero is a infinty sized file filled with zeros.
of is out file the file you wish to create.
bs is block size 1g 500m all are exceptable. man file explain the excepted options.
count is the number of blocks.

dd if=/dev/zero of=disk.img bs=1g count=1
Ie it create a 1g complete blank file.

The install cd ie bootcd can format the black disk.img when its
qemu -net none -hda disk.img -cdrom bootcd.iso -boot d
It is part of the installer. You have to go threw the installer until it gets to
the end so reactos is installed on the image.

Please post back it might be some other strange problem other than misunderstanding. Before digging to far got to rule out the basics.

[cyberkoa]

Thx again oiaohm, especially the full explanation

In fact I already realize the typo in the --cdrom and I actually try with -cdrom .

When I run livecd.iso , it starts up with black background (with the sentence press any key to boot from CD．．．）　then in less than 2 seconds , the screen changed to blue screen
similar to this

INACCESSIBLE_BOOT_DEVICE
*** STOP : 0x0000007B (0x00000000 times 4)

Frames:
ntoskrnl.exe: 1cdb>
ntoskrnl.exe: 1cf2>
ntoskrnl.exe: 6dfdb>
ntoskrnl.exe: 6ba2b>
ntoskrnl.exe: 4204>
ntoskrnl.exe: 6a553>
<0>

I am compiling the 0.29 source , which should not be broken right ?
That why I wonder is my compilation environment problem(compiler & linker version or other) .

Or the qemu version problem ?

[oiaohm]

I am redownloading the current 0.2.9 just to double check it. Ok old version of 0.2.9 pre audit works so I would not except that as a problem. Unless something has changed because of the audit<not expect so>.

I have upgraded my qemu to version 0.8.0 without the kernel accerator. Ok I have to put that back. Ie the reason for running the old version had to update both. So if yours is 0.8.0 then its not most likely the cause.

binutils-2.16.91-20060119-1-src.tar.gz I know works.

As well as standard tree binutils-2.16.1(Ok a few other bugs appears but it boots past that point it get the full gui up it can cause minor apps problems).

gcc-3.4.5-20060117-1.tar.gz I know works as well.
Since you followed the setup Guide I guess you have them.

ntoskrnl.exe Displayed does Suggest a problem I big one.

To be at the ntoskrnl.exe Qemu has already loaded and run the freeloader. Now is locating it.

Note I built my gcc and binutils poorly optmised in i386 mode not i586 mode. This very rarely can cause differences. I don't expect this to be a problem since the core developers are using i586 optmised.

This is something strange. The question is what is causing the problem.

I missing that you mentioned blue screen before sorry. QEMU gives the same message on a black screen(I sometimes wish that programs had completely different error messages). Blue screen is a kernel bail out bad causes can be many. Incompad envorment Ie QEMU bad versions can do this.

This error is suggesting that either the cdrom driver is not loaded or the cdrom filesystem driver is not working. Question why. Has freeloader failed to load it. Or the default hives damaged in your version of reactos.

Note I always press a key there but I don't expect that to be the difference.

At this point all we can do is compare versions and make sure we match kinda close.

I will edit this message after I test the current source on the download server http://jaist.dl.sourceforge.net/sourcef ... EL-src.zip
Or post a confirm note if the forum blocks me from editing this message.

[cyberkoa]

After a few testing , I realise that it maybe is Qemu problem.


The Boshs BIOS detected the following

ata0 master : QEMU HARDDISK ATA-2 Harddisk

ata0 slave : unknown device

ata1 master : QEMU CD-ROM ATAPI-U CD-ROM/DVD-ROM

ata1 slave : unknown device

I tried to take out the DVD writer /CD-writer one by one and trying a few combination , the Boshs BIOs detection is the same

Maybe the Boshs BIOs could not detect properly the CD/DVD and cause the ReactOS could not find the "Boot Device"

I am going to try to burn a physical LiveCD and test later .. but if this is true , then I can't emulate ReactOS on ubuntu

[oiaohm]

jaist. Image from sourceforge works.

Ok Now explain Qemu.

What Qemu shows you is a fake enviroment. Nothing to do with real hardware.

Question what version Qemu. Worst case that you might need to build Qemu from source to get everything working.

Boch Bois I was not using. I was just using the standard Qemu internal.

[cyberkoa]

I have burned the livecd ISO to a CD and try to boot from the CDROM drive.

The CD boots up , and shows a quick burn screen then turns black ..
This is the trial at my PC with LCD monitor.


I tried at another Celeron PC , the CD boots up , then shows a screen with pink and blue color but no word , then hang there.


It seems like my build has problem , still struggling to figure out what happen ..

[oiaohm]

Reactos is not the most stable beast. Before blaming build download the prebuild iso. Yep it does not like partical systems.

Only way to take on a non-working build system is version to version matching and checking passed command. The parts in the mingw versions
that I know that work are.

binutils-2.16.91-20060119-1
gcc-3.4.5-20060117-1
w32api-2.6
mingw-runtime-3.9
And as mentioned before qemu.
qemu-0.8.0
Any one looking at these version it will and can change into the future.

If that all matchs for the the system should work.
List of these versions of these parts are required for me to number one ask people to see if any one has a problem with ros. Now if what you have is a normally working combination. We then have a problem.

Either damage at your end or something with build was different.

One of the common faults in the mingw is w32api or mingw-runtime or gcc build with a different version of binutils to the version being used. A lot of bad things can be caused by it. I have had even the simple mingw test.c program
#include <stdio.h>
int main() {
printf("I am working\n");
}
Build with
i386-mingw32-gcc test.c -o test.exe
Not work due to it. The exe should work with any version of windows and wine from the cmd or console(*depending on OS). Ie verry bad things. This is a common fault to all linux mingw users. I have to remember to tell people important stuff like this. Gcc complier is not a even a part working Gcc until you have built the a simple test and it works.

Another of the faults with building ros under linux. Is thinking that you got away with make with out defining the prefix because it stops. You do not if you have typed make without ROS_PREFIX "make clean" is require just once. Twice you have do it again. Annoying it has to be a odd number even is not good. I hope the version 0.3.0 does not have this problem anymore.

Problem is that linux produces elf .o and mingws binutils supports elf as a .o. Linux headers are not right for building anything windows so does not work.

Check the list of versions. Check the build. Fault locations are most likely one or the other. I keep forgeting about the 0.2.9 error in the build scripts.

I would have listed how to aquire the version but its late here if I do I might make a major mistake leading you on a goose chase. Ask if you need how will provide at a more awake time.

[cyberkoa]

I have tested to download the pre-build livecd , burn to CD and boot up from that CD , the similiar problem happened.

= =
My building environment version

i586-mingw32msvc-gcc -dumpversion shows 3.4.2 ,( I have gcc-4.0 in my PC)

qemu 0.70 now , when I initially post this thread , it was 0.80 , but I downgraded it for testing.

mingw32-binutils 2.15.91.20040904

mingw-runtime 3.7-1

the winapi version I not sure how to check

it seems like the binutils and runtime is quite old . however, the prebuild liveCD also fail ... a bit strange...

[oiaohm]

w32api is the hardest to id. No file in it contatines a version number only way is to know what one was installed. Something I always not down if you used the waxdragon script its 3.2 w32api.

You setup looks to be a waxdragon script setup. Little old but should be working. Unless yours is suffering from the debian error
http://www.mingw.org/MinGWiki/index.php/BuildMingwCross
Yes there is a note mingw gcc 3.4.2 not good at least 3.4.4 on debian. This note might need to be expanded to your platform as well. Script would have to be updated to use it. Reason why I needed versions.

I just run more modern less problems.

Since you have the prebuild livecd .iso. Try opening that with your QEMU.

If that works as it should we know we have a working QEMU. One less problem. If download livecd works and yours does not something is wrong in build if both don't work something is wrong with QEMU. One less part to think about.

Reactos is Alpha status OS. Alpha status OS's have a habit of being verry hardware picky. Work on one box and not the next. It is tested to work with QEMU the one hardware system that should work since its the same all the time.

[cyberkoa]

I have tested to run the prebuild livecd.iso using qemu and it runs !

I think this is a break through ..

I am quite busy this week , have not had time to check the build environment and to rebuild ROS , I promise I will come back next week.

oiaohm , thanks for patient and detail guidance , sincerely.

[cyberkoa]

hi , I'm back finally.

I have tried to delete the whole source code folder and try rebuild , modify the arch to i586 in config.xml cause compilation problem.

switching back to i386 no compilation problem but still the same run-time problem.

Now I plan to build mingw* from and get the winapi version so that the build environment as close as a build environment that known to work.

oiaohm, you mentioned that the following environment is known that work, just want to confirm with you the w32api version is 2.6 or 3.6 ..

binutils-2.16.91-20060119-1
gcc-3.4.5-20060117-1
w32api-2.6
mingw-runtime-3.9
And as mentioned before qemu.
qemu-0.8.0

Thanks.

[oiaohm]

You found a type w32api 3.6. I oppesed.

Numbers Numbers more numbers a typos slip in.

Everything else in that list matchs my system.

I am sorry for any wasted time this typo caused.