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. 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 >>> >> >
