- lava-users - op-lists.linaro.org

About the cursor movement in the device config file.

by Elaine Wu (wuyanjun)

hi, all, I am using the new uefi, it use the cursor movement and the Enter to enter the entry. So I use the config file to write it, but I found it can not work well. the config is below. boot_cmds_ramdisk_sata = expect "Move Highlight", sendline "\033[B", sendline "\033[B", sendcontrol "M", sendline "\033[B", sendline "\033[B", sendline "\033[B", sendline "\033[B", sendline "\033[B", sendline "\033[B", sendcontrol "M", expect "D02", sendline "provision {SERVER_IP} -u htsat -p hello8943217 -f Image_D02 -a 10000", expect "succ" , sendline "norwfmem 100000 100000 1f00000", expect "OK", sendline "provision {SERVER_IP} -u htsat -p hello8943217 -f hip05-d02.dtb -a 100000", expect "succ", sendline "spiwfmem 100000 300000 100000", expect "OK", expect "OK", sendline "exit", expect "Select Language", sendline "\033[B", sendline "\033[B", sendcontrol "M", sendline "\033[B", sendline "\033[B", sendline "\033[B", sendline "\033[B", sendcontrol "M" After I read the source code of LAVA. I found it use the pexpect.spawn to interact with the terminal, So I directly writte a python file to directly use spawn to interact with the terminal, and it can work well . The source code is below. import sys from pexpect import spawn child = spawn("board_connect 2") # this is similar with minicom logfile = "/tmp/test_for_terminal.log" fd = open(logfile, 'a+') child.logfile = fd child.expect("to stop automatical booting", timeout=120) child.sendline("b") child.expect("Move Highlight") ## boot from sata child.sendline("\033[B") child.sendline("\033[B") child.sendcontrol("M") child.sendline("\033[B") child.sendline("\033[B") child.sendline("\033[B") child.sendline("\033[B") child.sendline("\033[B") child.sendline("\033[B") child.sendcontrol("M") child.expect("D02") child.sendline("provision 192.168.6.100 -u htsat -p hello8943217 -f Image_D02 -a 10000") child.expect("succ") child.sendline("norwfmem 100000 100000 1f00000") child.expect("OK") child.sendline("provision 192.168.6.100 -u htsat -p hello8943217 -f hip05-d02.dtb -a 100000") child.expect("succ") child.sendline("spiwfmem 100000 300000 100000") child.expect("OK") child.expect("OK") #child.interact() child.sendline("exit") child.expect("Select Language") child.sendline("\033[B") child.sendline("\033[B") child.sendcontrol("M") child.sendline("\033[B") child.sendline("\033[B") child.sendline("\033[B") child.sendline("\033[B") child.sendcontrol("M") child.interact() So I don't know why in LAVA it can not work. Also I have realized a function named /sendcursor /similar with the sendcontrol in the lava_dispatcher package especially in the /usr/lib/python2.7/dist-package/lava_dispatcher/utils.py, and it call the pexpect.spawn.sendline to send contents to the child process. But it still have the same phenomenon with using sendline(namely won't select the entry in the uefi menu). Does this problem is caused by the dashboard showing? The attached files are the log files when I use the python file to execute the interaction and the one when LAVA execute it. Thanks for your help. Elaine Hisilicon turing software and architecture

9 years, 1 month

2
2
0 0

Configuration file for new devices

by Quentin Schulz

Hi, We are building a LAVA lab which will be soon integrated to KernelCI. We want to add most of our boards to LAVA that's why we created configuration files for the old dispatcher (the one used by KernelCI at this moment) for all device types we own. I would like to know if you were interested in getting those configuration files to put them in your git repository (we are using some from: https://github.com/Linaro/lava-dispatcher/tree/release/lava_dispatcher/defa… If yes, what is your naming convention? I've seen sama53d for the SAMA5D3 Xplained for example. This is the list of boards currently added to our lab: Board name Current configuration file's name NextThingCo. CHIP sun5i-r8-chip Boundary Devices Nitrogen6x imx6q-nitrogen6x ATMEL at91rm9200ek at91rm9200ek ATMEL at91sam9261ek at91sam9261ek ATMEL at91sam9m10g45ek at91sam9m10g45ek ATMEL at91sam9x25ek at91sam9x25ek ATMEL at91sam9x35ek at91sam9x35ek ATMEL sama5d31ek sama5d31ek ATMEL sama5d36ek sama5d36ek ATMEL sama5d44ek sama5d4ek Marvell Armada 385 AP armada-385-db-ap Solidrun Clearfog armada-388-clearfog Plathome OpenBlocks AX3 armada-xp-openblocks-ax3-4 Regards, Quentin

9 years, 1 month

3
2
0 0

[PATCH] device-types: add meson8b-odroidc1.conf default

by Marc Titinger

From: Marc Titinger <mtitinger(a)baylibre.com> - specific u-boot prompt - specific C-c interrupt char - uImage only: hardkernel u-boot sources are heavily hardcoded in an old u-boot version (no bootz) Signed-off-by: Marc Titinger <mtitinger(a)baylibre.com> --- .../device-types/meson8b-odroidc1.conf | 44 ++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 lava_dispatcher/default-config/lava-dispatcher/device-types/meson8b-odroidc1.conf diff --git a/lava_dispatcher/default-config/lava-dispatcher/device-types/meson8b-odroidc1.conf b/lava_dispatcher/default-config/lava-dispatcher/device-types/meson8b-odroidc1.conf new file mode 100644 index 0000000..96232b4 --- /dev/null +++ b/lava_dispatcher/default-config/lava-dispatcher/device-types/meson8b-odroidc1.conf @@ -0,0 +1,44 @@ +client_type = bootloader +send_char = False +uimage_only = True +append_dtb = True + +u_load_addrs = + 0x20000000 + 0x22000000 + 0x21000000 + +z_load_addrs = + 0x20000000 + 0x22000000 + 0x21000000 + +boot_cmds_ramdisk = + setenv autoload no, + setenv kernel_addr_r "'{KERNEL_ADDR}'", + setenv initrd_addr_r "'{RAMDISK_ADDR}'", + setenv loadkernel "'tftp ${kernel_addr_r} {KERNEL}'", + setenv loadinitrd "'tftp ${initrd_addr_r} {RAMDISK}; setenv initrd_size ${filesize}'", + setenv bootargs "'console=ttyAML0,115200n8 root=/dev/ram0 ip=dhcp'", + setenv bootcmd "'dhcp; dhcp; setenv serverip {SERVER_IP}; run loadkernel; run loadinitrd; {BOOTX}'", + run bootcmd + +boot_cmds_nfs = + setenv autoload no, + setenv kernel_addr_r "'{KERNEL_ADDR}'", + setenv initrd_addr_r "'{RAMDISK_ADDR}'", + setenv loadkernel "'tftp ${kernel_addr_r} {KERNEL}'", + setenv loadinitrd "'tftp ${initrd_addr_r} {RAMDISK}; setenv initrd_size ${filesize}'", + setenv nfsargs "'setenv bootargs console=ttyAML0,115200n8 root=/dev/nfs rw nfsroot={SERVER_IP}:{NFSROOTFS},tcp,hard,intr ip=dhcp'", + setenv bootcmd "'dhcp; setenv serverip {SERVER_IP}; run loadkernel; run loadinitrd; run nfsargs; {BOOTX}'", + run bootcmd + +bootloader_prompt = odroidc# +interrupt_boot_prompt = key to stop autoboot +interrupt_boot_control_character = c + +boot_options = + boot_cmds + +[boot_cmds] +default = boot_cmds -- 2.5.0

9 years, 1 month

3
8
0 0

lava job strucked when execute the config file.

by Wu Yanjun (Elaine)

hi, I have two questions to ask: 1. I am using the lava to boot the D02 board, it can successfully execute before. But it failed after I update the uefi and rewrite the config file. But when I execute the config file manually, it succeed booting the board. And I can figure out what is wrong. The version of LAVA I used is 2015.9.post1, and I use LAVA v1. From the figure, we can see it is strucked when booting the kernel. then The log file of the lava job, the log of boot manually and the config file has been attached. 2. The uefi is used need to control by cursor movement, so I need to send KEY-DOWN in the d02.conf file. But when I use 'sendline "\033[A"' or ‘sendline "\16[A"', I found it can not work in the LAVA. So I want to know if we have any method to realize it? Thank you very much. -- Best Wishes wuyanjun (Elaine) Hisilicon Turing Software and Architecture

9 years, 1 month

1
0
0 0

the board uefi use dialog to boot, how can I configuare the lava device-type config file.

by Elaine Wu (wuyanjun)

hi, all, The uefi the board used has upgraded, so that the configuration of it can not be used in the current environment. Because now the uefi use the dialog to show the menu. As I know, the expect and sendline in the lava XXX.conf can not work well in this situation. Does you know how to config the XXX.conf to support this kind of uefi? The menu of the uefi is below. and Thank you very much. Elaine (wuyanjun) Hisilicon, Turing Architecture and Software

9 years, 1 month

2
4
0 0

adding per-action comment or brief description or meta-data into the bundle

by Marc Titinger

Hi Neil and all, how do I add per-action comments or meta data so that I can parse them from the result bundle: the following for instance will pass the schema validation, but the result bundle will degenerate into keeping only the last "comment" metadata entry, while I'd like a per-action metadata entry. { "command": "lava_command_run", "metadata": { "comment": "comment1" }, "parameters": { "commands": [ "uname -a" ] } }, { "command": "lava_command_run", "metadata": { "comment": "comment2" }, "parameters": { "commands": [ "ls -al" ] } }, The result bundle will contain the same metadata for each lava-command: "attributes": { "comment": "comment2", <=== same value "image.type": "kernel-ci", .... snip ... "logging_level": "DEBUG", "device.tree": "omap4-panda-es.dtb" }, "test_id": "lava-command" IOW, how do I assign a brief description to an action ? Thanks and regards, Marc.

9 years, 1 month

2
4
0 0

Reviews

by Neil Williams

https://review.linaro.org/#/c/10593/ and https://review.linaro.org/#/c/10595/ have some comments which need to be addressed. The simplest way is to register for a Linaro Community account and then you can login to gerrit yourself. Alternatively, the comments can be addressed by email and the reviews updated. https://ci.linaro.org/job/lava-dispatcher/836/console -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

9 years, 1 month

1
0
0 0

回复： Forward of moderated message

by wangbo

Hi Neil, But the problem is I want to define a job and use python script to communicate with the Android DUT, for example I want to use script.py in dispatcher to control the DUT. And the "lava_test_shell" will copy all these commands in steps to run.sh. # test_script.yaml run: steps: - echo "hello world" - ./android/script/script.py # run.sh in DUT ###default parameters from yaml### ###### ###test parameters from json### ###### ###other parameters### LAVA_SERVER_IP='172.16.117.50' TARGET_TYPE='android' ###### set -e export TESTRUN_ID=python cd /data/local/tmp/lava-mstar01/tests/0_c7a6f9e0-ae70-4d8b-8c06-f6da04b7a26c UUID=`cat uuid` echo "<LAVA_SIGNAL_STARTRUN $TESTRUN_ID $UUID>" #wait for an ack from the dispatcher read echo "hello world" ./android/script/script.py echo "<LAVA_SIGNAL_ENDRUN $TESTRUN_ID $UUID>" #wait for an ack from the dispatcher read ------------------ 原始邮件 ------------------ 发件人: "Neil Williams";<neil.williams(a)linaro.org>; 发送时间: 2016年1月30日(星期六) 晚上11:29 收件人: "wangbo"<wangbo.hfut(a)qq.com>; 抄送: "Lava Users Mailman list"<lava-users(a)lists.linaro.org>; 主题: Re: Forward of moderated message On 29 January 2016 at 04:08, wangbo <wangbo.hfut(a)qq.com> wrote: > Hi Neil, > > Thanks very much to your quickly and warmly answer. > > One more question: > > LAVA copy all the test scripts defined in the YAML to the DUT at the > specified directory, then the job will be executed on the DUT. The LAVA test shell scripts are POSIX shell. If a shell is not available, the test can be rewritten to use ADB commands, as the CTS tests do. > And if I want > to test one android device, but almost all the android images don't support > python interpreter, LAVA does not run any python code on the DUT unless the test writer puts python commands into their test shell definition YAML. The python code only runs on the dispatcher and handles communications over the serial port (or using ADB). > so it's impossible to write case with python, in most > cases we should use shell to run the test case. But sometimes we want to use > Appium/Robotium to test the android image, and use LAVA to deploy the image, > analyze and record the test results, so LAVA is unavailable in such > conditions. Do you have any advice to integrate these tools in LAVA or will > LAVA support such conditions in the future. You'd need to use multinode (as with CTS) to install the test support binaries into a VM which then communicates with the device. That VM then reports results that are retrieved with LAVA. > > Best Regards. > > ------------------ 原始邮件 ------------------ > 发件人: "Neil Williams";<neil.williams(a)linaro.org>; > 发送时间: 2016年1月29日(星期五) 凌晨3:27 > 收件人: "wangbo"<wangbo.hfut(a)qq.com>; > 抄送: "Lava Users Mailman list"<lava-users(a)lists.linaro.org>; > 主题: Re: Forward of moderated message > >> From: wangbo <wangbo.hfut(a)qq.com> >> Date: Thu, 28 Jan 2016 20:39:25 +0800 >> Subject: LAVA uninstall and upgrade, build method from the source code >> Hi all, >> >> I installed LAVA on Ubuntu 14.04 in our lab, but later we plan to upgrade >> the system to Ubuntu 15.10, so what should I do now? > > I'm afraid the only long term option is to migrate to Debian Jessie, > possibly using a VM, and then using jessie-backports. It is uncertain > whether it will be possible to support LAVA on the upcoming Ubuntu > Xenial 16.04LTS and support for Trusty has already been frozen. There > have been problems upgrading from 14.04 - these issues have already > been discussed on the lists. > > https://lists.linaro.org/pipermail/lava-announce/2015-November/000003.html > > The next upload of LAVA should be able to migrate into Ubuntu ahead of > the cut off for the Xenial release but that is outside our control. It > is also unknown whether it will be possible to maintain a system based > on Xenial - the LAVA software team will be unable to maintain such > support and users would need to be proactive in fixing problems that > may arise. > >> Because I have already installed LAVA, so should I uninstall it firstly, >> and then use apt-get install to reinstall LAVA? But I can't find more >> information about this in the website, can you give me some advice, thanks >> very much. > > https://staging.validation.linaro.org/static/docs/installing_on_debian.html… > > The main problems will be with the database, so building in any way > will have the same difficulties. Trusty is, sadly, a dead end at the > moment. > >> And, how to install LAVA from the source code? > > Not supported - installation is only supported as Debian packages. > LAVA is much more than a pip install / virtualenv can ever manage. > >> LAVA includes different parts, like lava-server, lava-dispatcher, >> lava-tool, etc. So which one should be installed firstly? By the way in the >> Git, for example "https://git.linaro.org/lava/lava-server.git/tree", there >> is no document about the install method. Now, I will modify some code to >> meet our demands in our lab, and then replace the corresponding file. We >> plan to manage the code with Git too. So if we know the install method from >> the source code, it will be better to build the code. > > There is no documentation for installing from git because the > installation method has moved to using packages. We abandoned the old > install from git methods a long time ago due to interminable bugs and > insolvable dilemmas. > > During the migration to the new dispatcher, things are too complex to > support more than Debian Jessie (and the next Debian release, > Stretch). Once the migration is complete (in 2017), the advantages of > the new design should also make it easier to support other operating > systems. We are a long way from that at the moment. > > -- > > Neil Williams > ============= > neil.williams(a)linaro.org > http://www.linux.codehelp.co.uk/ -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

9 years, 2 months

2
4
0 0

Missing apache config file

by Felsch Marco

Dear LAVA-Team, I have set up two new LAVA instances (master, worker) based on the production release 2016.02. The installation worked fine but I can't switch the apache site. I followed the instructions on: https://validation.linaro.org/static/docs/installing_on_debian.html#install… Then I searched for the lava-server.conf file on my system, but didn't find it. It looks like it isn't installed. I also tried to add it to add it manually, but it didn't worked. i.A. Marco Felsch Entwicklung Standort Chemnitz ******************** Wir sind umgezogen! ******************** Tel. +49 371 433151-34, Fax +49 371 433151-22 Zwickauer Strasse 173, 09116 Chemnitz ******************************************************************* mailto:marco.felsch@tq-group.com TQ-Systems GmbH Mühlstraße 2, 82229 Seefeld Amtsgericht München, HRB-Nr. 105 018, UST-IdNr. DE 252 251 764 WEEE-Reg.-Nr. DE 46311528 Sitz der Gesellschaft: Seefeld Geschäftsführer: Dipl.-Ing. (FH) Detlef Schneider, Dipl.-Ing. (FH) Rüdiger Stahl http://www.tq-group.com<http://www.tq-group.com/> Besuchen Sie uns / Visit us: light + building, Frankfurt am Main, March 13 - 18, 2016, Hall 9.0, Stand C80 Aircraft Interiors Expo, Hamburg, April 5 - 7, 2016, Stand 2A20 Automatica, Munich, June 21 - 24, 2016 Intersolar, Munich, June 22 - 24, 2016

9 years, 2 months

2
1
0 0

For all lava-tool users

by Neil Williams

If you are running lava-tool on Debian unstable (sid) or testing (stretch), the new version of python-keyring (8.4.1-1) will break lava-tool at versions lower than 0.14-2 as it has moved a previously supported component into a separate package which did not previously exist. Sadly, the lava-tool maintainers were not made aware of this change in functionality in advance - lava-tool simply stopped working in unstable. lava-tool 0.14-2 has been uploaded with the only change being a dependency on python-keyrings.alt which is the new package which provides the functionality formerly available as part of python-keyring itself. python-keyrings.alt already exists in Debian testing and can be safely installed ahead of the upgrade of python-keyring, so users may wish to install python-keyrings.alt now in order to maintain functionality. Version 8.4 of python-keyring will migrate into Debian testing before version 0.14-2 of lava-tool can migrate, so users of testing may have a short window where lava-tool fails in Debian testing if python-keyrings.alt is not installed in advance. Ubuntu users may also be affected as python-keyring is a "main" package, so may possibly update in Xenial Xerus - however as lava-tool is a "universe" package, it may not be possible to upgrade Xenial to 0.14-2 of lava-tool. Users are advised to manually install python-keyrings.alt to maintain functionality. lava-tool users running Jessie are not affected (but are advised to upgrade to 0.14-1~bpo8+1 from jessie-backports for other updates, new functionality and bug fixes). -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

9 years, 2 months

1
0
0 0

[RFC v2] lava_command: add host-side enter/exit hooks to control measurement tool

by Marc Titinger

This is used to generate measurements by interacting with devices that are not reachable as a node, and avoid target-specific support. Each device.conf file can define a host command or script used when entering a lava_command_run and leaving a lava_command_run, In the style of the PDU power cycling commands. host_hook_enter_command = <enter_hook> (command line to pass to host) host_hook_exit_command = <exit_hook> Hooks calling abi: ENTRER: arg0 = <enter_hook> arg1 = "output-file-fullpath" & EXIT: arg0 = <exit_hook> arg1 = "output-file-fullpath" & The MO is close to lava_test_shell: the LAVA_SIGNAL_TESTCASE search pattern will be applied to the output of the exit hook and if a measurement is found, a test_case will be added to the bundle stream of the job. Any file found in the logdir will be attached, starting with stdout.log. If a {output-file-fullpath}.minetype is found, its content is used as 'mime_type' for the attached file (as with lava_shell_test) example, see Job http://lava.baylibre.com:10080/dashboard/streams/anonymous/lab-health/bundl… as an example of unit-test power statistics record and display as test_cases. Signed-off-by: Marc Titinger <mtitinger(a)baylibre.com> --- v2: expect LAVA_SIGNAL_TESTCASE patterns like with lava_test_shell --- lava_dispatcher/actions/lava_command.py | 46 +++++++++++++++++++++++++++++++-- lava_dispatcher/config.py | 5 ++++ 2 files changed, 49 insertions(+), 2 deletions(-) diff --git a/lava_dispatcher/actions/lava_command.py b/lava_dispatcher/actions/lava_command.py index 7bf787a..0748b51 100644 --- a/lava_dispatcher/actions/lava_command.py +++ b/lava_dispatcher/actions/lava_command.py @@ -33,6 +33,8 @@ from lava_dispatcher.test_data import create_attachment from lava_dispatcher.utils import read_content from datetime import datetime +from lava_dispatcher.actions import lava_test_shell +from lava_dispatcher.lava_test_shell import parse_testcase_result class cmd_lava_command_run(BaseAction): @@ -54,16 +56,30 @@ class cmd_lava_command_run(BaseAction): _parser = None _fixupdict = {} _results_from_log_file = [] + _cur_record = None + _record_index = 0 + _uuid = None def run(self, commands, parser=None, iterations=1, fixupdict=None, timeout=-1): target = self.client.target_device + context = self.context log_dir = tempfile.mkdtemp(dir=target.scratch_dir) self._logfile = os.path.join(log_dir, 'stdout.log') + self._uuid = str(uuid4()) if parser is not None: self._parser = parser if fixupdict is not None: self._fixupdict = fixupdict logging.info("lava_command logfile: %s" % self._logfile) + + #if there is a host-side hook to call: + host_enter_hook = context.device_config.host_hook_enter_command + if host_enter_hook: + self._cur_record = os.path.join(log_dir, self._uuid.split('-')[0]) + host_enter_hook = host_enter_hook.rstrip('&') + " " + self._cur_record + " &" + logging.warning('Running enter hook on host %s' % host_enter_hook) + context.run_command(host_enter_hook) + with self.client.tester_session() as session: for count in range(iterations): logging.info("Executing lava_command_run iteration: %s" % count) @@ -81,6 +97,27 @@ class cmd_lava_command_run(BaseAction): self._results_from_log_file.append(res) logging.error(e) + #if there is a host-side hook to call: + host_exit_hook = context.device_config.host_hook_exit_command + if host_exit_hook: + host_exit_hook = host_exit_hook.rstrip('&') + " " + self._cur_record + " &" + logging.warning('Running EXIT hook on dispatcher host %s' % host_exit_hook) + output = context.run_command_get_output(host_exit_hook) + + # See https://github.com/BayLibre/iio-capture as an instance of an + # app that will produce compatible output when called from the host + # Hook. + test_pattern = r"<LAVA_SIGNAL_TESTCASE TEST_CASE_ID=(?P<test_case_id>.*)\s+"\ + "RESULT=(?P<result>(PASS|pass|FAIL|fail|SKIP|skip|UNKNOWN|unknown))\s+"\ + "UNITS=(?P<units>.*)\s+MEASUREMENT=(?P<measurement>.*)>" + test_case_pattern = re.compile(test_pattern) + + for line in output.split(os.linesep): + match = test_case_pattern.match(line.strip()) + if match: + res = parse_testcase_result(match.groupdict()) + self._results_from_log_file.append(res) + bundle = self._get_bundle() self._write_results_bundle(bundle) @@ -126,12 +163,17 @@ class cmd_lava_command_run(BaseAction): def _get_test_runs(self): now = datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ') - attachment = [create_attachment(os.path.basename(self._logfile), read_content(self._logfile))] + attachment_dir = os.path.dirname(self._logfile) + attachment = lava_test_shell._attachments_from_dir(os.path.dirname(self._logfile)) + # fixup default mimetypes, for stdout.log mainly + for entry in attachment: + if entry['pathname'].endswith(".log"): + entry['mime_type'] = "text/plain" results = self._get_test_results() return { 'test_id': 'lava-command', 'analyzer_assigned_date': now, - 'analyzer_assigned_uuid': str(uuid4()), + 'analyzer_assigned_uuid': self._uuid, 'time_check_performed': False, 'test_results': results, 'attachments': attachment diff --git a/lava_dispatcher/config.py b/lava_dispatcher/config.py index 63aa3c6..10bccc8 100644 --- a/lava_dispatcher/config.py +++ b/lava_dispatcher/config.py @@ -29,6 +29,11 @@ from configglue import parser, schema class DeviceSchema(schema.Schema): + + # Host-side hook for lava_command_run + host_hook_enter_command = schema.StringOption() + host_hook_exit_command = schema.StringOption() + master_testboot_dir = schema.StringOption() master_testboot_label = schema.StringOption() master_testrootfs_dir = schema.StringOption() -- 2.5.0

9 years, 2 months

2
1
0 0

Re: [Lava-users] Forward of moderated message

by Neil Williams

> From: wangbo <wangbo.hfut(a)qq.com> > Date: Thu, 28 Jan 2016 20:39:25 +0800 > Subject: LAVA uninstall and upgrade, build method from the source code > Hi all, > > I installed LAVA on Ubuntu 14.04 in our lab, but later we plan to upgrade the system to Ubuntu 15.10, so what should I do now? I'm afraid the only long term option is to migrate to Debian Jessie, possibly using a VM, and then using jessie-backports. It is uncertain whether it will be possible to support LAVA on the upcoming Ubuntu Xenial 16.04LTS and support for Trusty has already been frozen. There have been problems upgrading from 14.04 - these issues have already been discussed on the lists. https://lists.linaro.org/pipermail/lava-announce/2015-November/000003.html The next upload of LAVA should be able to migrate into Ubuntu ahead of the cut off for the Xenial release but that is outside our control. It is also unknown whether it will be possible to maintain a system based on Xenial - the LAVA software team will be unable to maintain such support and users would need to be proactive in fixing problems that may arise. > Because I have already installed LAVA, so should I uninstall it firstly, and then use apt-get install to reinstall LAVA? But I can't find more information about this in the website, can you give me some advice, thanks very much. https://staging.validation.linaro.org/static/docs/installing_on_debian.html… The main problems will be with the database, so building in any way will have the same difficulties. Trusty is, sadly, a dead end at the moment. > And, how to install LAVA from the source code? Not supported - installation is only supported as Debian packages. LAVA is much more than a pip install / virtualenv can ever manage. > LAVA includes different parts, like lava-server, lava-dispatcher, lava-tool, etc. So which one should be installed firstly? By the way in the Git, for example "https://git.linaro.org/lava/lava-server.git/tree", there is no document about the install method. Now, I will modify some code to meet our demands in our lab, and then replace the corresponding file. We plan to manage the code with Git too. So if we know the install method from the source code, it will be better to build the code. There is no documentation for installing from git because the installation method has moved to using packages. We abandoned the old install from git methods a long time ago due to interminable bugs and insolvable dilemmas. During the migration to the new dispatcher, things are too complex to support more than Debian Jessie (and the next Debian release, Stretch). Once the migration is complete (in 2017), the advantages of the new design should also make it easier to support other operating systems. We are a long way from that at the moment. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

9 years, 3 months

2
2
0 0

using shell-hooks to record stuff on host

by Marc Titinger

Hi Neil et al. I'd like to have the host record power measurements during a job, or during a unit-test. browsing the lava manual, I came across the shell-hooks which seem to enable what I want to do. Suppose I want to call a script "capture-start.sh" at the top of the job, and "capture-stop.sh" at the end, is this the proper way to do stuff: In the job json: ------------------- ``` { "command": "lava_test_shell", "parameters": { "testdef_repos": [ { "git-repo": "https://github.com.... /lava-test-definitions.git", "testdef": "capture-start.yaml" } ], "timeout": 1800 } }, .... dispatcher actions of interest .... { "command": "lava_test_shell", "parameters": { "testdef_repos": [ { "git-repo": "https://github.com.... /lava-test-definitions.git", "testdef": "capture-stop.yaml" } ], "timeout": 1800 } }, ``` In the yaml, do I need to override all the handlers ? If I don't need end_case or postprocess_test_result do I need to fill them, and point to a "nop.sh" script "? I assume that I need to provide at lest one step to be done on the target, even if I am only interested in the host-side commands, would the following yaml make sense: ``` metadata: format: Lava-Test Test Definition 1.0 name: power-capture-start run: steps: - lava-test-case pass-test --shell echo starting power measurements handler: handler-name: shell-hooks params: device_config_vars: DEVICE_TYPE: device_type handlers: start_testcase: capture-start-start-hook.sh end_testcase: nop.sh postprocess_test_result: nop.sh ``` Thanks and Regards, Marc.

9 years, 3 months

1
0
0 0

u-boot version of panda master image

by Marc Titinger

Hi all, I have a basic practical question: I'm trying to reset a panda-es board with a suitable master image for lava to use with the default device-types confs, namely with: lava-dispatcher/device-types/panda-es.conf:bootloader_prompt = U-Boot so I wrote panda-master-20150303.img.tgz (linaro master-images) to the sdcard I'm using. I'd expect u-boot.bin on the boot partition to being compatible with the expected lava prompt and u-boot command set ('bootz' supported for instance), but I keep having an incompatible config of u-boot ("Panda" as a prompt, bootz not supported, etc...), what am I missing? Thanks and Regards, Marc.

9 years, 4 months

2
1
0 0

how to debug "incomplete" jobs with no log ?

by Marc Titinger

Hi Neil et al, I'm trying to debug a simple qemu job that goes straight from running to incomplete without log creation (used to working ok, but I reinstalled everything on a different machine...) Looking at /var/log/lava-server/lava-scheduler.log I see the following: 2015-12-09 15:22:27,838 [INFO] [lava_scheduler_daemon.job.JobRunner.14] starting job {u'timeout': 18000, 'health_check': False, u'job_name': u'qemu-arm-test', u'actions': [{u'command': u'deploy_linaro_kernel', u'parameters': {u'login_prompt': u'login:', u'kernel': u' http://images.validation.linaro.org/functional-test-images/qemu-arm/zImage-…', u'username': u'root', u'rootfs': u' http://images.validation.linaro.org/functional-test-images/qemu-arm/core-im…'}}, {u'command': u'boot_linaro_image', u'parameters': {u'test_image_prompt': u'root@qemu-system-arm:~#'}}], u'target': u'qemu0'} 2015-12-09 15:22:27,838 [INFO] [lava_scheduler_daemon.job.MonitorJob] monitoring "setsid lava-server manage schedulermonitor 14 lava-dispatch qemu0 /tmp/tmpPd4nGs -l info -f /var/log/lava-server/lava-scheduler.log" 2015-12-09 15:22:29,171 [INFO] [lava_scheduler_daemon.job.Job.qemu0] executing "lava-dispatch /tmp/tmpFltuQQ --output-dir /var/lib/lava-server/default/media/job-output/job-14" 2015-12-09 15:22:30,388 [INFO] [lava_scheduler_daemon.job.DispatcherProcessProtocol] childConnectionLost for qemu0: 0 2015-12-09 15:22:30,389 [INFO] [lava_scheduler_daemon.job.DispatcherProcessProtocol] childConnectionLost for qemu0: 1 2015-12-09 15:22:30,389 [INFO] [lava_scheduler_daemon.job.DispatcherProcessProtocol] childConnectionLost for qemu0: 2 2015-12-09 15:22:30,389 [INFO] [lava_scheduler_daemon.job.DispatcherProcessProtocol] processExited for qemu0: A process has ended with a probable error condition: process ended with exit code 1. 2015-12-09 15:22:30,389 [INFO] [lava_scheduler_daemon.job.DispatcherProcessProtocol] processEnded for qemu0: A process has ended with a probable error condition: process ended with exit code 1. 2015-12-09 15:22:30,389 [INFO] [lava_scheduler_daemon.job.Job.qemu0] job finished on qemu0 2015-12-09 15:22:30,389 [INFO] [lava_scheduler_daemon.job.Job.qemu0] job incomplete: reported 1 exit code 2015-12-09 15:22:30,422 [INFO] [lava_scheduler_daemon.dbjobsource.DatabaseJobSource] job 14 completed on qemu0 I tried to run manually: setsid lava-server manage schedulermonitor 14 lava-dispatch qemu0 qemu-arm.json powerci@lab-baylibre:~/POWERCI/scripts/user$ 2015-12-09 15:23:23,285 [ERROR] [lava_scheduler_daemon.job.Job.qemu0] AttributeError: 'Job' object has no attribute '_protocol' Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 1203, in mainLoop self.runUntilCurrent() File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 798, in runUntilCurrent f(*a, **kw) File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 393, in callback self._startRunCallbacks(result) File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 501, in _startRunCallbacks self._runCallbacks() --- <exception caught here> --- File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 588, in _runCallbacks current.result = callback(current.result, *args, **kw) File "/usr/lib/python2.7/dist-packages/lava_scheduler_daemon/job.py", line 226, in _run self.cancel(exc) File "/usr/lib/python2.7/dist-packages/lava_scheduler_daemon/job.py", line 157, in cancel self._protocol.transport.signalProcess(getattr(signal, signame)) exceptions.AttributeError: 'Job' object has no attribute '_protocol' Note that I get the same issue with other jobs (boards, kvm): submission is OK, but incomplete, and no log. Any help would be much appreciated! Many thanks, Marc.

9 years, 5 months

2
3
0 0

adding measurements to a test result

by Marc Titinger

Hi, is it possible to interact with a host tool (running on the dispatcher host) to gather arbitrary key values and post them into the test result stream. IOW, How do I add a MEASUREMENT/UNITS values using the output of a host tool (no target shell interaction) ? Thanks, Marc.

9 years, 5 months

1
0
0 0

lavadpu restart issue

by Marc Titinger

Hi Neil et al. I'm working at add my switching device to lavapdu deamon, so I pull Matt's github etc...but when trying to restart the daemon I get the following error: déc. 04 15:56:49 powerci-lava-disp lavapdu-runner[3081]: Reading settings from /etc/lavapdu/lavapdu.conf déc. 04 15:56:49 powerci-lava-disp lavapdu-runner[3081]: Traceback (most recent call last): déc. 04 15:56:49 powerci-lava-disp lavapdu-runner[3081]: File "/usr/sbin/lavapdu-runner", line 103, in <module> déc. 04 15:56:49 powerci-lava-disp lavapdu-runner[3081]: context = daemon.DaemonContext( déc. 04 15:56:49 powerci-lava-disp lavapdu-runner[3081]: AttributeError: 'module' object has no attribute 'DaemonContext' déc. 04 15:56:49 powerci-lava-disp lavapdu-runner[3081]: ...fail! déc. 04 15:56:49 powerci-lava-disp systemd[1]: lavapdu-runner.service: Control process exited, code=exited status=1 déc. 04 15:56:49 powerci-lava-disp systemd[1]: Failed to start LSB: LAVA PDU Runner. déc. 04 15:56:49 powerci-lava-disp systemd[1]: lavapdu-runner.service: Unit entered failed state. déc. 04 15:56:49 powerci-lava-disp systemd[1]: lavapdu-runner.service: Failed with result 'exit-code'. I tried to revert to the master branch, re-installed with setup.py with no success. The json config file seems ok. Any clue? Many Thanks, Marc.

9 years, 5 months

1
0
0 0

help with initial config of a beaglebone-black while setting up a local dispatcher

by Marc Titinger

Hi All, I'm setting up a local LAVA scheduler+dispatcher (standalone). I'm able to posts jobs, but I think I'm missing an initial configuration for some actions to complete, namely action deploy_linaro_image the eMMC flash content of my BBB-RevB6 is pretty standard (debian-7.9 of 2015-11-03, 2gb image). Based on the log, the dispatcher expects the default "testboot" and "testrootfs" partitions with offset 2, I assuime this means that those partitions must be manually created the first time with index 3 and 4 in order for this to work. I would appreciate some hints, to avoid unnecessary test-and-try, what would be the expected partitionning for BBB with LAVA ? Thanks in advance, best regards, Marc.

9 years, 5 months

2
7
0 0

Issues with Django OpenID Authentication

by Neil Williams

Please let us know if you are using OpenID authentication with LAVA. Newer versions of django will make it impossible to support django-openid-auth in Debian unstable and testing. The version of django-openid-auth in Jessie can continue to be used, so we would like to know how many users want to continue with this support. OpenID as a protocol has been dying for some time and Linaro has moved over to LDAP, which is fine if LDAP is already available. The time pressure for this change is coming from the schedule to get the latest django and the latest lava packages into Ubuntu Xenial 16.04LTS which means that support needs to be implemented in the 2015.12 or 2016.1 LAVA releases. This is why this is quickly following the trusty change. We have been aware of the issues with django-openid-auth for some time, it was only when we had completed the move of the Cambridge lab to LDAP that changes involving django-openid-auth could be considered. If you are using OpenID authentication (e.g. using Launchpad or Google OpenID), please let us know. If you would like to see some other forms of authentication supported, also let us know. We can investigate Python Social Auth (http://psa.matiasaguirre.net/), if there is interest. If we don't hear from users who want django-openid-auth support for use on Debian Jessie, we will drop django-openid-auth support from all lava builds. This will leave LDAP and local Django accounts in 2015.12. If anyone has experience of other django authentication modules, also let us know. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

9 years, 5 months

1
0
0 0

Freezing support for LAVA on Ubuntu Trusty 14.04LTS

by Neil Williams

See also: https://lists.linaro.org/pipermail/lava-announce/2015-November/000002.html which was also sent to these lists (except linaro-dev). So far, nobody has come forward as a Trusty user. The only Trusty instance of which we are aware is already due to migrate to Debian Jessie. The LAVA software team are now applying updates which will freeze LAVA software support for Ubuntu Trusty at 2015.9 for lava-dispatcher and 2015.9.post1 for lava-server due to the complexities of supporting both django1.6 and the current django1.7 in Jessie and django1.8, possibly django1.9 by the time Debian Stretch is released. The last packages for Ubuntu Trusty 14.04LTS will be: lava-server 2015.9.post1 lava-dispatcher 2015.9 Once these changes are applied, the Debian packaging used to build future versions of LAVA packages will prevent builds against django1.6 and prevent installation if django1.6 is found, in order to prevent database corruption. This means that Trusty users will not be able to use the results of the dispatcher refactoring. Ubuntu Xenial Xerus - which is planned to be the 16.04LTS in April 2016 - is expected to pick up LAVA software releases from Debian up until the 2016.1 release (possibly 2016.2) and is also expected to be using django1.8. The next Debian stable release (Stretch), for which no date has yet been set, may use django1.9. Initial attempts at migrating a test instance from Trusty to django1.7 did not go well and the migration from Trusty to Xenial cannot be supported by the LAVA software team - the recommendation is to go directly from 2015.9 on Trusty to the same version available for Debian Jessie but there will still be work to be done to prepare and implement the migration which will be instance-dependent. Documentation is being added to assist with this migration but there will remain risks of data loss which will need to be managed for each instance. It is imperative that anyone using Trusty has an up to date backup of the postgresql database dump before considering any migration. If the existing data is to be dropped, a new install on Debian Jessie is recommended. It is not possible for the LAVA software team to support all versions of django from 1.6 to 1.9 - particular problems are known when going from django1.6 to django1.7 as the methods to migrate the lava-server database changed fundamentally in django1.7. Notes are being added to the documentation on the trusty branch based on 2015.9 to be released within lava-server 2015.9.post1 and to the documentation in the master branch (which will go into 2015.12). All future builds of LAVA software will now be made and uploaded only to Debian and releases.linaro.org. So far, nobody has come forward who is willing to maintain packaging for LAVA software on any distribution other than Debian. As the refactoring proceeds, we expect that it will become easier to package LAVA for other distributions but the migration to the refactoring must be complete first. Everyone interested in or using LAVA is encouraged to subscribe to the lava-announce mailing list which is low volume and only used for substantial changes like this. https://lists.linaro.org/mailman/listinfo/lava-announce See also https://validation.linaro.org/static/docs/support.html -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

9 years, 5 months

1
0
0 0

Calling all Trusty users of LAVA

by Neil Williams

This is a call to *all* users of LAVA on Trusty - please let us know who you are, what you're needs are and whether you are able to migrate to Debian Jessie instead of going from Trusty 14.04LTS to Xenial Xerus 16.04LTS. If you are using LAVA on any release of Ubuntu older than Trusty, the only advice from the LAVA team is to immediately migrate to Debian Jessie. If you are using LAVA on Wily Werewolf or Vivid Vervet, you should also consider testing the migration to Xenial and comparing with a migration to Debian Jessie, as below. LAVA is looking at a fix for the 2015.9 release but Django1.9 is in beta release already. There are issues with django1.8 which are in development. Currently, we are proposing that this update will be applied to 2015.9 and made into a frozen release. The master branch of LAVA will continue to develop and will need to use more features only available in Django1.7 and later. Documentation relating to installing Trusty would then be deprecated and removed in subsequent releases from the master branch. Equally, future database migrations on the master branch would no longer provide south support, using the django migration support provided by django1.7 and later. So these releases would not be built for Trusty - leaving only the frozen branch. Due to the complexity of supporting django1.6, it is unlikely that updates will be available for the frozen branch once this happens.. The changes in the lava-server due to the ongoing refactoring will mean that users of Trusty will be unable to migrate to pipeline support until the server has also been migrated to Xenial 16.04LTS. In addition to this, there is concern that migrating from Trusty and django1.6 all the way to django1.8 or possibly django1.9 in Ubuntu Xenial 16.04LTS is going to be problematic and the LAVA team will be unable to assist in most cases. The alternative is for someone with a reasonably complex lab running Ubuntu to take up a role as tester of the frozen branch *and* responsibility for patches which can maintain trusty support and migration to Xenial 16.04LTS. The problem then will be that it will be a very large transition when 16.04LTS actually becomes available - only for the same lag to start all over again. I'm unsure when Xenial will close the window for migrations from Debian into Xenial - I expect that the 2015.12 release of LAVA will migrate, I expect that 2016.1 will migrate too but I cannot be sure about 2016.2 or 2016.3. That migration is completely outside the control of the LAVA software team. https://launchpad.net/ubuntu/xenial/+source/lava-server Everyone considering staying on Ubuntu is advised to try a migration to Xenial *now* - in a VM, with and without a recent backup of your database and logs. Xenial currently has 2015.11. Also compare with a migration to Debian Jessie by dumping and reimporting the database. In each case, ensure that the permissions on /var/lib/lava-server and sub-directories are retained from the original. Please talk to us and test out what you are going to do. https://validation.linaro.org/static/docs/support.html -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

9 years, 5 months

1
0
0 0

Beginnings

by Neil Williams

Some pointers on this list: Anyone is welcome to subscribe and post their issues. A few notes which subscribers should follow and recommend to others: 0: Wherever possible, use a pastebin for log output and include a link to the paste in your post. 1: Paste from the complete log, not the summary, so that you get the complete lines. 2: Include in this paste or another paste, the job definition 3: If your job uses URLs which are not visible to the rest of the list, include a rough outline of how those were built and what versions of tools were used. Subscribers are invited to help each other. LAVA developers will be around but are not the only source of assistance on this list. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

9 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users