Hello, Can anyone help out? I ran the "make run/seoul-auto.run" in my nova_x86_64 build directory and nearly at the end of the process i got this error: make: *** [run/seoul-auto] Erreur 253 (please find below a sample of the trace from the serial output) I also attached the complete trace. Can anyone help me solve the problem? I work on Ubuntu 12.04.
//error ... ... .... [init -> seoul] VMM: # rtc_cmos rtc_cmos: setting system clock to 2015-10-09 17:16:38 UTC (1444410998) [init -> seoul] VMM: # RAMDISK: ext2 filesystem found at block 0 [init -> seoul] VMM: # RAMDISK: Loading 20704KiB [1 disk] into ram disk... / [init -> seoul] VMM: # | / [init -> seoul] VMM: # | / [init -> seoul] VMM: # | / [init -> seoul] VMM: # | / [init -> seoul] VMM: # | / [init -> seoul] VMM: # | / [init -> seoul] VMM: # | / [init -> seoul] VMM: # | / [init -> seoul] VMM: # | / [init -> seoul] VMM: # | / [init -> seoul] VMM: # | / [init -> seoul] VMM: # | / [init -> seoul] VMM: # | / [init -> seoul] VMM: # | / [init -> seoul] VMM: # | / Booting Core 4.7.7 [init -> seoul] VMM: # Running Linux Kernel 3.1.0. [init -> seoul] VMM: # Checking boot options...Done. [init -> seoul] VMM: # Starting udev daemon for hotplug support...| [init -> seoul] VMM: # | Done. [init -> seoul] VMM: # modprobe: chdir(3.1.0): No such file or directory [init -> seoul] VMM: # modprobe: chdir(3.1.0): No such file or directory Error: Spawned process died unexpectedly make: *** [run/seoul-auto] Erreur 253
Hello,
On 09.10.2015 21:06, Parfait Tokponnon wrote:
Hello, Can anyone help out?
may you please try to invoke the resulting iso file with qemu directly without using our run tool? Change "spawn qemu-system-x86_64 -cpu ..." (see log file) to "qemu-system-x86_64 -cpu ..." and call it from within the build directory. What is the (error) output of qemu ? Do you are running Ubuntu 12.04 from within a VM ?
Regards,
Alex.
Hello,
Thank you for your reply. I had some trouble with my system, that is why i didn't reply you earlier...
Yes, I am running Ubuntu from within a VM (VirtualBox). Is there any problem related to it? I didn't know we cannot test the platform from within a VM...
And Yes, when I had invoked qemu directly with the provided command in the log file it worked too.
So what could be the explanation?
Regards,
PS: sorry for the duplication, i have used the wrong mail account prevously!
2015-10-12 11:49 GMT+02:00 Alexander Boettcher < alexander.boettcher@...1...>:
Hello,
On 09.10.2015 21:06, Parfait Tokponnon wrote:
Hello, Can anyone help out?
may you please try to invoke the resulting iso file with qemu directly without using our run tool? Change "spawn qemu-system-x86_64 -cpu ..." (see log file) to "qemu-system-x86_64 -cpu ..." and call it from within the build directory. What is the (error) output of qemu ? Do you are running Ubuntu 12.04 from within a VM ?
Regards,
Alex.
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi,
On 14.10.2015 12:44, Parfait Tokponnon wrote:
Yes, I am running Ubuntu from within a VM (VirtualBox). Is there any problem related to it? I didn't know we cannot test the platform from within a VM...
developing within a VM is no issue, but actually running the result from within a VM is adventurous - at least - most the time, based on practical experience.
In your case you have 3 level of virtualization/emulation nested - you are running Ubuntu in Virtualbox (1), then you run Genode/Nova inside Qemu (2) ontop of (1) and finally you run a Linux VM with Seoul VMM (3) on top of (2).
Beside the obviously waste of CPU time and increasing your idle time, you have to rely on all upper levels to work correctly. Such a assumption and in principal such a development setup just leads to various types of frustrations - I would try to avoid that.
And Yes, when I had invoked qemu directly with the provided command in the log file it worked too. So what could be the explanation?
Our run tool sets for automatically tested scripts (as seoul-auto.run) a timeout until it must have been finished. Since you say it works for you when you are calling qemu directly - it could be that the execution time in your 3-level nested virtualization setup is too short.
You may try to increase the timeout in seoul-auto.run (search for run_genode_until) or try using seoul-net.run instead, which is mainly the same setup but without timeout.
Does this change things for you ?
If not, you would have to find out why tcl/expect stops working with a eof (in <genode-dir>/tool/run/run) error when waiting for qemu output.
Regards,
Alex.
Hi Alexander, That's correct, when I had set the timeout to 600, it ran perfectly. Concerning the layers of virtualization, I understand well your concerns. It was just for trying purpose. Really, I am already considering moving to a real development platform and let the Linux VM. Regards,
2015-10-14 18:07 GMT+02:00 Alexander Boettcher < alexander.boettcher@...1...>:
Hi,
On 14.10.2015 12:44, Parfait Tokponnon wrote:
Yes, I am running Ubuntu from within a VM (VirtualBox). Is there any problem related to it? I didn't know we cannot test the platform from within a VM...
developing within a VM is no issue, but actually running the result from within a VM is adventurous - at least - most the time, based on practical experience.
In your case you have 3 level of virtualization/emulation nested - you are running Ubuntu in Virtualbox (1), then you run Genode/Nova inside Qemu (2) ontop of (1) and finally you run a Linux VM with Seoul VMM (3) on top of (2).
Beside the obviously waste of CPU time and increasing your idle time, you have to rely on all upper levels to work correctly. Such a assumption and in principal such a development setup just leads to various types of frustrations - I would try to avoid that.
And Yes, when I had invoked qemu directly with the provided command in
the
log file it worked too. So what could be the explanation?
Our run tool sets for automatically tested scripts (as seoul-auto.run) a timeout until it must have been finished. Since you say it works for you when you are calling qemu directly - it could be that the execution time in your 3-level nested virtualization setup is too short.
You may try to increase the timeout in seoul-auto.run (search for run_genode_until) or try using seoul-net.run instead, which is mainly the same setup but without timeout.
Does this change things for you ?
If not, you would have to find out why tcl/expect stops working with a eof (in <genode-dir>/tool/run/run) error when waiting for qemu output.
Regards,
Alex.
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-
Alexander Boettcher -
Parfait Tokponnon