angela wrote: > Thanks Jan. I had tried and finally we got the results: > > 1. About reboot issue: > Seems that grub in Solaris doesn't support boot-once feature. But I can > use bootadm set-menu default=<n> to modify boot entry using LiveUSB. > As I don't know how to add an entry in grub menu for LiveCD, does any > one know it? > > 2. About LiveCD/USB: > ssh enable is still needed, as we need to log into the system and set > test environment, and then start instgui test.
I am working bug 6431 ssh or rlogin service should be enable in install image for automated testing > > The following is what I've tested: > The system has two hard disks, hard disk 1 has been installed > opensolaris, with ZFS root pool named rpool; hard disk 2 is used as test > disk to install opensolaris from LiveUSB. > and prior the test run the system is booted from hard disk 1, and have > accessible ssh > Steps: > 1) modify menu.lst to USB entry in hard disk 1 > 2) reboot from LiveUSB > 3) import rpool on hard disk 1, and modify menu.lst to hard disk 2 entry > 4) install the system on hard disk 2 > 5) reboot from hard disk 2 is ok > > I didn't try the situation if hard disk 1 is with UFS, but I think there > will have no issue. > So I prefer that, in hard disk 1, we use UFS, and there is a free slice > that can be used to install STEP packages as well as store STEP results. > Then the solution will as the following, using LiveUSB firstly: > 1) install STEP packages on hard disk 1 (ssh already enabled) > 2) generate image on USB, with ssh enabled > 3) modify menu.lst to USB entry in hard disk 1 > 4) reboot from LiveUSB > 5) import rpool on hard disk 1, and modify menu.lst to hard disk 2 entry > 6) install the system on hard disk 2, and set ssh enabled > 7) reboot from hard disk 2 (ssh already enabled) > 8) import rpool on hard disk 1, and modify menu.lst to hard disk 1 entry > 9) reboot from hard disk 1 > 10) upload STEP results, and leave the system as before > > What do you think? > > Thanks, > Angela > > Jan Spitalnik ??: >> Hi all, >> >> On 9.2.2009, at 9:42, angela wrote: >> >>> Hi Paul and guys, >>> >>> >>> >>> Current the test suite instgui doesn't consider scenario that >>> reboot Slim installation. If we want to cover this scenario, >>> the system needs reboot from harddisk after fully installation. >>> >>> As x86 systems, the boot device is defined in the boot sequence >>> in BIOS. So since we have no way to change BIOS settings, >>> after Slim installation, to boot from hd, one possible solution >>> is to destroy LiveCD/LiveUSB, so that in next boot the system >>> can boot from harddisk. >>> >>> After installation, we should: >>> 1) destroy the image which is located on current boot device; >>> 2) be able to do reboot through ssh section remotely. >>> >>> I suppose doing a dd on current LiveUSB could reach our target. >>> but I'm not sure which sectors can be destroyed while not influent >>> current running system. >>> And how about LiveCD case? >> we had a discussion in SST how to do this w/o destroying the image - >> since that >> makes reQs harder. We came up with the following scenario: >> >> Prereq: >> 0a) Installed some version of osol on the client, with ssh enabled >> 0b) BIOS boot order set to boot off HDD by default >> >> 1) Login to the client, modify GRUB's menu.lst located at /rpool/ to >> allow 'boot-once' mode >> and point GRUB at the CD/DVD. (Details: >> http://www.gnu.org/software/grub/manual/html_node/Booting-once_002donly.html) >> >> >> 2) Reboot >> 3) System boots off the CD >> 4) Once the testsuite is over and reboots the system will boot back to >> the drive >> ... >> next iteration is just a jump to point 1) >> >> It solves the following issues: >> - no need to discard the media >> - no need for SSH on the LiveCD/USB >> >> It adds the following issues: >> - prior the testrun the system must have accessible ssh >> >> How does this sound? >> >> Cheers, >> Spity >> >> PS: We didn't try this, it's just an idea right now. >> >>> >>> Can anyone shed some lights on what is the best solution? >>> >>> Thanks, >>> Angela >>> >>> angela ??: >>>> 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 >>>>> >>>>> >>>> _______________________________________________ >>>> caiman-discuss mailing list >>>> caiman-discuss at opensolaris.org >>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>>> > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
