Paul Stanley - Sun Microsystems Ireland - Solaris Software ??: > resending to include the caiman-discuss alias > > Paul Stanley - Sun Microsystems Ireland - Solaris Software wrote: > >> angela wrote: >> >> >>> Hi Paul, >>> >>> Good news, we find the issue that prevent us executing GUI test suite >>> instgui through remote ssh/rsh. >>> And we also setup a KVM, instgui got all PASS. >>> >>> >>> >> That's great. >> >> >>> The only issue is if execute the test again without reboot the system >>> and reset X, some test cases failed with error: >>> >>> 520|0 1 00001149 1 1|unexpected signal 11 (SIGSEGV) received. >>> >>> By tracing, we found most time the keyCombo() function call of dogtail >>> causes the error, but we do not know the further root cause. >>> We are also not sure that maybe other dogtail functions cause the same >>> issue. >>> >>> Fortunately we have the workaround that executing test suite after boot, >>> we suggest that we may go on PIT integration process. >>> >>> >>> >> I think this should be okay - the reboot before starting can be handled >> by the STEP wrapper. >> >> >>> The suggested solution is to use KVM over IP and execute testsuite: >>> >>> 1) Assume the system can be accessed by rsh/ssh before start to execute >>> test, >>> and the system should be set to boot from CD or USB automatically. >>> >>> 2) modify the opensolaris image to be tested: >>> - enable ssh or rsh service >>> Hope this can be done by ITeam. >>> >>> >>> >> I'd suggest you log an RFE for this and we can mark it as a prerequisite >> for automated testing. >> Done. See CR6431 http://defect.opensolaris.org/bz/show_bug.cgi?id=6431 >> >> >>> 3) reboot SUT, so that SUT boot from LiveCD or LiveUSB >>> >>> >>> >> Is this reboot not sufficient to avoid the issue you mentioned above? >> No, we met the issue only when tried to re-execute the test suite in step 8). If we execute test suite from very beginning, that is, boot to LiveCD/LiveUSB and reset X, it doesn't happen. >> It's not clear how the test object gets onto the USB/CD. I would suggest >> this is also handled as part of the configuration in the STEP wrapper. >> Some people SST and PIT are also working on install type STEP testsuites >> (e.g. the S10 upgrade/liveupgrade tests) - maybe they can shed some >> light on how best to design testsuites that reinstall the system. >> The wrapper can take this job, burn the CD/USB with tested image. One question is, when and how to destroy the tested image. If the system is booted from LiveCD/LiveUSB, doing dd on the whole device may cause the system hang. I suppose dd some sectors may make it unable to boot next time, and also will not cause hang on current system, but I'm not sure about it, and don't know which sectors should be done dd.
>> >> >>> 4) rsh/ssh to SUT with user "jack" >>> >>> 5) install packages needed >>> >>> 6) X-server and environment configuration >>> Xorg tcp_listen=true >>> export DISPLAY=:0.0 >>> export LC_ALL=C >>> enable assitive technologies: AT-SPI >>> restart Xorg >>> xhost + >>> >>> 8) configure and execute test suite >>> execute test suite with jack user, using pfexec to get root permission. >>> In the original solution, the test will leave the system in macroroot. So it is easy to do investigation if some test suite failed. If the STEP wrapper take care of creating LiveCD/LiveUSB as well as destroying it, then the test will leave the system at the very beginning state. And the investigation will take more time. Which one is much preferred? >>> Do you have any concerns? Can this solution be possible for PIT environment? >>> If yes, we are planning to start STEP wrapping. >>> >>> >>> >> Seems fine to me - I'm sure the others on the thread will join in if >> they have other issues or suggestions. >> >> Paul >> >> >>> Cheers, >>> Angela >>> >>> >>> Paul Stanley - Sun Microsystems Ireland - Solaris Software ??: >>> >>> >>> >>>> angela wrote: >>>> >>>> >>>> >>>> >>>>> Hi Paul, >>>>> >>>>> 1) about KVM over IP solution: >>>>> We don't have this device right now, so at first, we connect the monitor >>>>> with SUT, >>>>> and tried to run test from remote system. >>>>> Unfortunately, we found there are some issues which prevent test >>>>> execution from remote system. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> Can you give some more details of the issues? This solution maps well to >>>> the current SST setup and has a couple of advantages when it comes to >>>> analysis. >>>> >>>> >>>> >>>> >>>>> We suppose that with KVM or KVM over IP should act the same as with >>>>> monitor, right? >>>>> If so, then this solution will not work for this test suite. >>>>> >>>>> 2) about redirect to X server solution: >>>>> This can work, the X server can be any systems except SUT. >>>>> And the X server can run on snv, opensolaris or opensolaris microroot. >>>>> >>>>> So the following is one possible solution: >>>>> >>>>> 1) X-server configuration >>>>> >>>>> 2) modify SUNWgnome-gui-test which will be used by instgui: >>>>> Some codes in this package should be changed firstly, to disable dogtail >>>>> A11y checking. >>>>> This pkg will not be modified regularly, so we can do the modification >>>>> firstly, >>>>> and then install it to SUT when execute the test. >>>>> >>>>> 3) hack the opensolaris image to be tested: >>>>> - enable ssh or rsh service >>>>> Hope this can be done by ITeam. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> We should pass this as a testing requirement to the I-team - preferably >>>> a clean supported option to enable this. >>>> >>>> >>>> >>>> >>>>> 3) boot the SUT from LiveCD or LiveUSB >>>>> >>>>> 4) rsh/ssh to SUT with user "jack" >>>>> >>>>> 5) su root >>>>> As opensolaris will not allow root login, so we must login with jack >>>>> firstly. >>>>> As new installer "gui-install" and test suite needs root permisstion to >>>>> execute. >>>>> So we are think using pfexec to workaround this. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> I don't see any reason this would not work >>>> >>>> >>>> >>>> >>>>> Currently, we are not sure about this, we will try this after our >>>>> Chinese New Year holiday. >>>>> So if we could, then no need to su root. >>>>> While, if not, there are the following two solutions: >>>>> *) change the opensolaris image to allow root login >>>>> or >>>>> *) STEP should add support on this. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> If necessary this can be done I'm sure. >>>> >>>> >>>> >>>> >>>>> 6) install packages needed >>>>> >>>>> 7) set DISPLAY and start /usr/lib/at-spi-registryd in background >>>>> >>>>> 8) configure and execute test suite >>>>> >>>>> So for us, we will go back to you on pfexec issue after holiday. >>>>> >>>>> Any comments? >>>>> >>>>> BTW, Jan.24 to Feb.1 2009 is our Chinese New Year holiday. >>>>> We will be back office at Feb.2. >>>>> >>>>> Have a nice week, >>>>> Angela >>>>> >>>>> >>>>> Paul Stanley - Sun Microsystems Ireland - Solaris Software ??: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> SST currently use a KVM over IP solution - the SUT thinks it has a >>>>>> monitor and if necessary (for analysis) an engineer can see what's being >>>>>> displayed. I can ask SST which exact models they use if you like. >>>>>> >>>>>> PIT don't have requirements for anything like this yet - but we could >>>>>> plan for this as part of install testing. >>>>>> >>>>>> There may be other solutions (depending on the X application) - e.g. >>>>>> just redirect the display to a single infrastructure server running an X >>>>>> server. In this scenario an engineers desktop could be passed as the >>>>>> target X server in cases where interaction is required - e.g. analysis >>>>>> of testcase fails >>>>>> >>>>>> There may be other solutions too. >>>>>> >>>>>> Paul >>>>>> >>>>>> angela wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hi Paul, >>>>>>> >>>>>>> I was unable to attend the last concall. >>>>>>> I would like to know how to run X application without monitor in >>>>>>> PIT/SST? >>>>>>> Can you or someone give us an introduction firstly? >>>>>>> >>>>>>> Thanks, >>>>>>> Angela >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
