Hi Angela, On 16.2.2009, at 12:57, 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? Yeah, i've tried to make it work, but it seems it's just broken (i've filed 6807027: grub's savedefault is broken, will not store selected boot entry). I've attached a shell script that can take care of adding the boot entry, but w/o working savedefault it's quite useless. Another problem is that even if savedefault would work, solaris' grub doesn't support booting off CD it seems. I'll take a look at some linux distro how they do it, since i've the feeling that it should be possible. I've tried to workaround this issue by bundling alternative bootloader with the script, that grub loads from the disk and that subsequently chainloads the cd, but it doesn't work on my notebook claiming there's not media in the tray :-) What a mess.. Another way to make this work would be to take the Jumpstart approach. Set the boot order on the system to NET, HDD, CDROM and boot the system off the network. Download GRUB image that would point to the CD- ROM, install and connect to the boot server and remove the boot image for that particular machine. On next reboot the netboot would fail and we'd boot off HDD. But we hit the CD chainload problem again. I'll see what I can come up with tomorrow. Cheers, Spity > > > 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 >>>> >>> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: grub-boot-cd.ksh Type: application/octet-stream Size: 1830 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090218/4550bf44/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: grub-boot-cd.tar Type: application/x-tar Size: 40960 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090218/4550bf44/attachment.tar>
