Try to replace osv-loader.qemu under ~/.capstan with newer version of kernel - https://github.com/cloudius-systems/osv/releases/download/v0.53.0/osv-loader.qemu.
On Sunday, March 24, 2019 at 2:47:36 AM UTC-4, robertob wrote: > > Thank you so much. > > I did all you wrote but I get these lines: > > OSv v0.24-472-gf240a59 > eth0: 192.168.122.15 > /java.so: failed looking up symbol _ZTINSt6thread6_StateE (typeinfo for > std::thr > > > [backtrace] > 0x00000000003477cd <elf::object::symbol(unsigned int)+205> > 0x0000000000399922 <elf::object::arch_relocate_rela(unsigned int, unsigned > int, > 0x00000000003446b3 <elf::object::relocate_rela()+147> > 0x0000000000346247 <elf::object::relocate()+199> > 0x0000000000349cdc <elf::program::load_object(std::string, std::vector<std > ::str> > 0x000000000034a54b <elf::program::get_library(std::string, std::vector<std > ::strd > 0x000000000041ccea <osv::application::application(std::string const&, std > ::vect> > 0x000000000041d515 <osv::application::run(std::string const&, std::vector< > std::a > 0x000000000041d73b <osv::application::run(std::vector<std::string, std:: > allocato > 0x0000000000213125 <do_main_thread(void*)+1717> > 0x000000000044d6a5 <???+4511397> > 0x00000000003f5477 <thread_main_c+39> > 0x00000000003959a5 <???+3758501> > 0x03209500032091ff <???+52466175> > 0x00000000003f4b6f <???+4148079> > 0xfb89485354415540 <???+1413567808> > > > > I cannot understand why the OSV version is 0.24. I think this is the > probem now. > > regards > r > > Il giorno venerdì 22 marzo 2019 21:45:38 UTC+1, Waldek Kozaczuk ha scritto: > >> So I have tested it myself and it looks like capstan (or OSv cannot parse >> properly command line built by capstan) cannot properly handle arguments >> when passes through YAML args list. >> >> It looks like you are using the "java" runtime that capstan advertises >> which aims to make it easier to deploy and run Java apps on OSv by >> automating process of constructing proper java command line and pull extra >> packages. But apparently it has bugs and in general it comes with another >> layer of abstraction which sometimes may make it more difficult to >> troubleshoot the problem. >> >> You can always bypass this layer and use "native" runtime where you have >> full control of how your OSv command like looks. This is BTW how I use >> capstan. >> >> Here is how your meta/run.yaml would look like: >> runtime: native >> config_set: >> *myconfig1*: >> bootcmd: "/java.so -jar /Uni.jar -lsim -nTc 10 -sp 50000 -kp >> ./keystore -tf ./config/topology.prop.xml -tIp 127.0.0.1 -d 60 -td >> ./traces/ -cfg ./config/config.prop.xml" >> config_set_default: *myconfig1* >> >> Also you need to change meta/package.yaml. See this example: >> name: java-example >> title: Java Example >> author: Anonymous >> version: "1.0" >> require: >> #- openjdk8-zulu-full >> - openjdk8-zulu-compact3-with-java-beans >> - osv.run-java >> created: "2018-06-13T18:09:24-04:00" >> >> Please see you can use either full and slimmer version of Open JDK 8 JRE. >> Also please note extra package which needs to be the last one and you can >> download it from github >> https://github.com/cloudius-systems/osv/releases/download/v0.51.0/osv.run-java.mpm/yaml >> >> and put it under $HOME/.capstan/packages/. Unfortunately the old >> Mikelangelo S3 repo has pretty old (2018) artifacts and I am not sure if >> anybody maintains it. You can always easily create your own S3 OSv packages >> repo if you want. >> >> I have tested it with my hello world class and Java app received >> arguments correctly: >> Sv v0.53.0 >> eth0: 192.168.122.15 >> java.so: Starting JVM app using: io/osv/nonisolated/RunNonIsolatedJvmApp >> java.so: Setting Java system classloader to >> NonIsolatingOsvSystemClassLoader >> Hello from Java on OSv! >> Arg: -lsim >> Arg: -nTc >> Arg: 10 >> Arg: -sp >> Arg: 50000 >> Arg: -kp >> Arg: ./keystore >> Arg: -tf >> Arg: ./config/topology.prop.xml >> Arg: -tIp >> Arg: 127.0.0.1 >> Arg: -d >> Arg: 60 >> Arg: -td >> Arg: ./traces/ >> Arg: -cfg >> Arg: ./config/config.prop.xml >> >> I hope this helps, >> Waldek >> >> On Wednesday, March 20, 2019 at 2:36:56 AM UTC-4, robertob wrote: >>> >>> Dear all, >>> >>> I have a "run.yaml" to run a JAR file. We need to pass a lot of >>> arguments but something go wrong. This is the snippet of the run.yaml: >>> >>> *myconfig1:* >>> * main: /Uni.jar* >>> * args:* >>> * - -lsim -nTc 10* >>> * - -sp 50000* >>> * - -kp ./keystore* >>> * - -tf ./config/topology.prop.xml* >>> * - -tIp 127.0.0.1* >>> * - -d 60* >>> * - -td ./traces/* >>> * - -cfg ./config/config.prop.xml* >>> >>> When I run the image the message I got is the following: >>> >>> *"unrecognised option '-nTc'"* >>> >>> It seems to consider only the first argument and not the others. >>> >>> Any advice? >>> >>> Regards >>> >>> R >>> >> -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
