lava-users

lava-users@lists.lavasoftware.org

2 participants
944 discussions

by Rees, Kevron

I have a minnowboard turbot device that I want lava to boot, flash, reboot to flashed image, and then run tests. I would like to boot the device via PXE networking to an initramfs where I will flash an image to permanent storage. I can use efibootmgr within the initramfs image to set next-boot to the permanent storage device. Once booted from the permanent storage device, lava tests will run as per normal. It appears that many of the ipxe examples I have found simply run tests on the initramfs itself. Is it possible to flash the device once the initramfs has booted? It seems like it would be simple for lava-dispatcher to run wget http://someurl/foo.img | dd of=/dev/sda once the initramfs has reached login. However, I do not know if there is such a deploy mechanism. Does anything already exist within lava to help achieve this model? Is there a better way? Any feedback would be appreciated. -Kevron

8 years, 4 months

Truncated commands & output in LAVA2

by Dragos Iorgulescu

Hi all! We have been working on integrating a cn8304-based board (uses uboot). We noticed some strange behavior that might be related to LAVA2. On average, 2 out of 3 job runs end up with errors/timeouts. We use the same job definition and device each and every time. Looking through LAVA logs, it seems that commands and some output gets truncated, thus malforming the commands being sent or the prompts that LAVA expects. The prompt we expect is "EBB8304> ", but sometimes it gets truncated to "304>". Also, a command gets mixed up somehow, and instead of "setenv loadinitrd 'tftpboot 0x60000000 358/tftp-deploy-VLCRzw/ramdisk/ramdisk.ext4.gz.uboot'", the board receives "EBB8304> setenv loadkernel 'tftpboot 0x40setenv loadinitrd 'tftpboot 0x60000000 358/tftp-deploy-VLCRzw/ramdisk/ramdisk.ext4.gz.uboot'" Details: * The job definition: https://paste.debian.net/993349/ * An excerpt from the LAVA2 job log/output, showing what gets mixed up: https://paste.debian.net/993350/ * The plain job log is attached to this e-mail Many thanks in advance! -- /Dragoş

8 years, 4 months

LAB Notice: Planned maintenance

by Dave Pigott

Hi all, Starting this week, we are finalising the transition of LAVA main production to LAVA V2. The main update and hopefully minor downtime, will commence at 09:00 UTC on Monday 6th November. Along with this we will also be upgrading all micro-instances to Debian Stretch and LAVA 2017.11. There will be a brief period on Monday morning, which should be less than an hour, when remote logins will be disabled as we upgrade the gateway server. Please note, that when validation.linaro.org comes back online, LAVA V1 job submissions will be rejected, so if you have any bots which auto-submit V1 jobs, please work with us to transition them to V2. Thanks Dave ---------------- Dave Pigott LAVA Lab Lead Linaro Ltd t: (+44) (0) 1223 400063

8 years, 4 months

LAVA Error 503 Service Unavailable Error

by Tan, Jian Chern

Hey does anyone know why i'm getting an Error 503 Service Unavailable after installing LAVA on a new server? I have it installed on another system and i've never gotten this error on that system before. If it helps, i'm working behind a corporate proxy and here are the pertinent lines from lava-server.log in the apache log folder. [Fri Oct 06 20:01:57.729804 2017] [proxy:error] [pid 2887:tid 140627852187392] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:8000 (127.0.0.1) failed [Fri Oct 06 20:01:57.729851 2017] [proxy_http:error] [pid 2887:tid 140627852187392] [client *IP*:56521] AH01114: HTTP: failed to make connection to backend: 127.0.0.1 Thanks! Jian Chern

8 years, 5 months

How to transfer a file from DUT to Server?

by Sathyamurthy, Raghuram

Hello, I working on a requirement for our project where I need to get some log from DUT and send back to Server. How can I achieve it? Thanks, Raghu

8 years, 5 months

lava-tool auth-add problem

by Michael Chen

Hi lava users, We're trying to use lava-tool to automate the job submit process, but having problem on using "lava-tool auth-add" command. The error message is ERROR: Username provided but no token found. I tried the instructions from the following page, but without luck. https://validation.linaro.org/static/docs/v2/lava-tool-issues.html I am pretty sure the user name, token, server url are correct since we tested it with the example python script from above page's second paragraph, and we can submit job through it. The version of lava-tool is 0.23-1 and lava-server is 2017.10-1+jessie. Does anyone have similar issue? Thank you. Michael Chen

8 years, 5 months

Test job failed due to uefi-menu-selector timeout

by Arthur She

Hi, I got a problem in LAVA v2. My test jobs failed due to uefi-menu-selector timeout occasionally. Like this one <https://staging.validation.linaro.org/scheduler/job/188583> and this one <https://staging.validation.linaro.org/scheduler/job/185376>. When it happened, I usually re-submit the test job and, sometimes, it got recovery and had the test job run successfully, like this <https://staging.validation.linaro.org/scheduler/job/185377>. However, we're working on our own CI loop now, the test job <https://staging.validation.linaro.org/scheduler/job/194340> is submitted automatically. It doesn't make sense to re-submit the test job. Any ideas? Thanks, Arthur

8 years, 5 months

Board At Desk v1.0, a downstream of LAVA and kernelci, just released.

by Agustin Benito Bethencourt

Hi, CIP just released Board At Desk v1.0 which is based on LAVAv2 and kernelci. Link: https://www.cip-project.org/blog/2017/10/18/cip-launches-bd-v1-0 From those involved in this release, thanks to all of you who make these technologies possible and also to those involved in kernelci.org project. Thank you also for your support these past months. Best Regards -- Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito(a)codethink.co.uk

8 years, 5 months

Re: [Lava-users] Help running an inline test

by Neil Williams

On 26 Sep 2017 2:59 am, "Daniel Sangorrin" <daniel.sangorrin(a)toshiba.co.jp> wrote: Hi Neil, > -----Original Message----- > From: Neil Williams [mailto:neil.williams@linaro.org] > Sent: Tuesday, September 12, 2017 5:49 PM > To: Daniel Sangorrin > Cc: Robert Marshall; Lava Users Mailman list > Subject: Re: [Lava-users] Help running an inline test > > On 12 September 2017 at 09:25, Daniel Sangorrin > <daniel.sangorrin(a)toshiba.co.jp> wrote: > > > >> -----Original Message----- > >> From: Neil Williams [mailto:neil.williams@linaro.org] > >> Sent: Tuesday, September 12, 2017 4:58 PM > >> To: Daniel Sangorrin > >> Cc: Robert Marshall; Lava Users Mailman list > >> Subject: Re: [Lava-users] Help running an inline test > >> > >> On 12 September 2017 at 08:50, Daniel Sangorrin > >> <daniel.sangorrin(a)toshiba.co.jp> wrote: > >> > Hi Neil, > >> > > >> > Thanks for your reply. > >> > > >> >> -----Original Message----- > >> >> From: Neil Williams [mailto:neil.williams@linaro.org] > >> >> Sent: Tuesday, September 12, 2017 4:16 PM > >> >> To: Daniel Sangorrin > >> >> Cc: Robert Marshall; Lava Users Mailman list > >> >> Subject: Re: [Lava-users] Help running an inline test > >> >> > >> >> On 12 September 2017 at 08:10, Daniel Sangorrin > >> >> <daniel.sangorrin(a)toshiba.co.jp> wrote: > >> >> > Robert, Neil: > >> >> > > >> >> > I managed to prepare a 2017.7 environment. The boot action still works fine. > >> >> > The test action still fails, but in a more 'sane' way I would say. > >> >> > There are strange things like 'None', no lava-test-runner, etc.. Please check the > >> >> > log attached. > >> >> > >> >> You haven't specified a deploy step, so there is no test shell > >> >> created. Boot just does the boot - to deploy the test environment > >> >> there must be a deploy action. > >> > > >> > As far as I understand, the deployment action occurs before the > >> > boot action and consists of preparing a kernel/filesystem in some > >> > media (e.g.: as a network filesystem). > >> > Ref: https://validation.linaro.org/static/docs/v2/actions-deploy.html > >> > > >> > For now, I wanted to run my tests with the kernel and filesystem > >> > that is already installed on the Flash memory. Is this impossible with LAVA? > >> > >> Such a system can only be booted, it cannot operate a Lava Test Shell > >> because there is no way to get the test shell onto the device without > >> a deploy. > >> > >> There is support for primary connections using SSH > >> https://validation.linaro.org/static/docs/v2/dispatcher- design.html#primary-connection > >> > >> See: Problems with simplistic testing in the documentation. > >> https://validation.linaro.org/static/docs/v2/simple-admin. html#problems-with-simplistic-testing > > > > Thanks a lot Neil. > > # I'm not against deployment, I just wanted to prepare the environment step by step. > > > > The primary connection could be a good solution but it looks like I wouldn't be able to use the PDU, > > or the autologin features from the u-boot action through the serial port. I will implement the > > deploy action instead. > > > > By the way, when you talk about "test shell" I am assuming that you mean a shell script or binary > > that is copied into the target filesystem and executed. Is that correct? > > My filesystem is very minimal: basically busybox using the ash shell. > > "test shell" == Lava Test Shell as defined by the test action block. > This relies on POSIX behaviour where the automation drives scripts > installed onto the system to execute the test operations themselves. > > To handle busybox ash compatibility, just set the Operating System as > Open Embedded. > > actions: > - deploy: > # ... rest of the deploy > os: oe > > https://validation.linaro.org/static/docs/v2/actions-deploy.html#index-18 Sorry, it took me a while but I finally got it working. I met several problems. Some of them were a matter of overriding variables. For example, I cannot use dhcp for the board so I had to change uboot_ipaddr_cmd and base_ip_args. There was one variable (SERVER_IP) I couldn't override, so I had to modify base-uboot.jinja2 for it. my jinja2: {% set uboot_serverip = '192.168.1.66' %} base-uboot.jinja2 # vi /etc/lava-server/dispatcher-config/device-types/base-uboot.jinja2 {% set base_uboot_tftp_bootcmd = uboot_tftp_bootcmd|default( " - setenv bootcmd '" + uboot_ipaddr_cmd|default('dhcp') + "; setenv serverip " + uboot_serverip|default('{SERVER_IP}') + "; run loadkernel; run loadinitrd; " + run_load_fdt + uboot_bootx_cmd|default('{BOOTX}') + "' - run bootcmd") -%} Note: I tried modifying LAVA_SERVER_IP and LAVA_NETWORK_IFACE in /etc/lava-dispatcher/lava-dispatcher.conf as well but it didn't work. Those settings are only relevant for V1, so V2 tests will ignore these. Setting the SERVER_IP in the device configuration is the wrong approach. This IP address is for the dispatcher, so it needs to be added to the dispatcher configuration. In V2, the dispatcher configuration is sent from the master. Setting a fixed IP address for the dispatcher is already supported. See /usr/share/lava-dispatcher/dispatcher.yaml for an example. See https://validation.linaro.org/static/docs/v2/pipeline-admin.html#extra-disp… You need a file named according to the hostname of the dispatcher as it appears in the dispatcher-master log file. If you consider it useful, please consider including it in the mainstream code. Thanks for your help, Daniel > >> >> >> -----Original Message----- > >> >> >> From: Lava-users [mailto:lava-users-bounces@lists.linaro.org] On Behalf Of Daniel Sangorrin > >> >> >> Sent: Monday, September 11, 2017 5:16 PM > >> >> >> To: 'Robert Marshall'; 'Lava Users Mailman list' > >> >> >> Subject: Re: [Lava-users] Help running an inline test > >> >> >> > >> >> >> > -----Original Message----- > >> >> >> > From: Lava-users [mailto:lava-users-bounces@lists.linaro.org] On Behalf Of Robert Marshall > >> >> >> > Sent: Monday, September 11, 2017 4:47 PM > >> >> >> > To: 'Lava Users Mailman list' > >> >> >> > Subject: Re: [Lava-users] Help running an inline test > >> >> >> > > >> >> >> > "Daniel Sangorrin" <daniel.sangorrin(a)toshiba.co.jp> writes: > >> >> >> > > >> >> >> > > Hi Neil, > >> >> >> > > > >> >> >> > > Thanks for your quick reply. > >> >> >> > > > >> >> >> > >> -----Original Message----- > >> >> >> > >> From: Neil Williams [mailto:neil.williams@linaro.org] > >> >> >> > >> Sent: Monday, September 11, 2017 3:23 PM > >> >> >> > >> > >> >> >> > >> On 11 September 2017 at 07:06, Daniel Sangorrin > >> >> >> > >> <daniel.sangorrin(a)toshiba.co.jp> wrote: > >> >> >> > >> > Hi, > >> >> >> > >> > > >> >> >> > >> > I have spent a few days learning LAVA with QEMU and the Beagle Bone black. > >> >> >> > >> > Now, I'm trying to setup a Renesas iwg20m board but I have some strange > >> >> >> > >> > problem. > >> >> >> > >> > # I'm using LAVA v2016.12. > >> >> >> > >> > >> >> >> > >> Updates are available - you should follow the LAVA documentation for > >> >> >> > >> the LAVA repositories and upgrade. > >> >> >> > >> > >> >> >> > >> https://staging.validation.linaro.org/static/docs/v2/ installing_on_debian.html#lava-repositories > >> >> >> > > > >> >> >> > > Thanks, I will try with the 2017.9 version then. > >> >> >> > > > >> >> >> > Daniel > >> >> >> > > >> >> >> > If you're doing the test within b@d [1] you should look at my > >> >> >> > https://gitlab.com/rajm/board-at-desk-single-dev/tree/ lava2017-fixes > >> >> >> > branch which has various fixes for our use of lava 2017-7, once that > >> >> >> > branch is merged - soon now! - it should 'just work' > >> >> >> > >> >> >> Wow Robert, just in time! Thanks. > >> >> >> > >> >> >> Daniel > >> >> >> > >> >> >> > >> >> >> _______________________________________________ > >> >> >> Lava-users mailing list > >> >> >> Lava-users(a)lists.linaro.org > >> >> >> https://lists.linaro.org/mailman/listinfo/lava-users > >> >> > > >> >> > _______________________________________________ > >> >> > Lava-users mailing list > >> >> > Lava-users(a)lists.linaro.org > >> >> > https://lists.linaro.org/mailman/listinfo/lava-users > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> > >> >> 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/ > > > > > > > > > > -- > > Neil Williams > ============= > neil.williams(a)linaro.org > http://www.linux.codehelp.co.uk/

8 years, 5 months

Help running an inline test

by Daniel Sangorrin

Hi, I have spent a few days learning LAVA with QEMU and the Beagle Bone black. Now, I'm trying to setup a Renesas iwg20m board but I have some strange problem. # I'm using LAVA v2016.12. The actions in the job definition looks as follows (sorry pastebin is blocked by our proxy): actions: - boot: method: u-boot commands: msd type: uimage auto_login: login_prompt: '\(none\) login: ' username: root prompts: - 'myiwg20m: # ' timeout: minutes: 2 failure_retry: 5 - test: timeout: minutes: 5 failure_retry: 3 name: kernel-version-singlenode definitions: - repository: metadata: format: Lava-Test Test Definition 1.0 name: kernel-version-basic description: "check kernel version" run: steps: - lava-test-case linux-INLINE-uname --shell uname -a from: inline name: kernel-version-inline path: inline/kernel-version-basic.yaml So far LAVA has been successful at powering on the board, interrupting u-boot, sending the u-boot commands, recognizing the boot login prompt and auto-login in. In other words, the boot actions seems to be working fine. The problem comes with the 'test' action. I have mostly copied the code from the inline example included in the help but I get the following errors: (sorry again for not pasting it on pastebin) - {"dt": "2017-09-11T05:19:03.602576", "lvl": "target", "msg": "Debian GNU/Linux 8 (none) /dev/ttySC0"} - {"dt": "2017-09-11T05:19:03.605709", "lvl": "debug", "msg": "Matched prompt #6: \\(none\\) login: "} - {"dt": "2017-09-11T05:19:03.606979", "lvl": "debug", "msg": "Sending username root"} - {"dt": "2017-09-11T05:19:03.608100", "lvl": "debug", "msg": {"sending": "root\n"}} - {"dt": "2017-09-11T05:19:03.864073", "lvl": "target", "msg": "(none) login: root"} - {"dt": "2017-09-11T05:19:03.865475", "lvl": "debug", "msg": "auto-login-action: Wait for prompt ['myiwg20m: # ']. 120 seconds"} - {"dt": "2017-09-11T05:19:03.868416", "lvl": "target", "msg": "root"} - {"dt": "2017-09-11T05:19:03.898283", "lvl": "target", "msg": ""} - {"dt": "2017-09-11T05:19:03.904742", "lvl": "target", "msg": "The programs included with the Debian GNU/Linux system are free software;"} - {"dt": "2017-09-11T05:19:03.911114", "lvl": "target", "msg": "the exact distribution terms for each program are described in the"} - {"dt": "2017-09-11T05:19:03.915433", "lvl": "target", "msg": "individual files in /usr/share/doc/*/copyright."} - {"dt": "2017-09-11T05:19:03.921821", "lvl": "target", "msg": "Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent"} - {"dt": "2017-09-11T05:19:03.923941", "lvl": "target", "msg": "permitted by applicable law."} - {"dt": "2017-09-11T05:19:03.927111", "lvl": "target", "msg": "login[816]: root login on 'ttySC0'"} - {"dt": "2017-09-11T05:19:03.928112", "lvl": "target", "msg": ""} - {"dt": "2017-09-11T05:19:03.933510", "lvl": "target", "msg": "BusyBox v1.22.1 (2017-09-01 01:37:39 UTC) built-in shell (ash)"} - {"dt": "2017-09-11T05:19:03.937734", "lvl": "target", "msg": "Enter 'help' for a list of built-in commands."} - {"dt": "2017-09-11T05:19:03.938979", "lvl": "debug", "msg": "Setting shell prompt(s) to ['myiwg20m: # ', 'lava-test: # ']"} - {"dt": "2017-09-11T05:19:03.939504", "lvl": "debug", "msg": {"sending": "export PS1=\"lava-test: # \"\n"}} - {"dt": "2017-09-11T05:19:05.310766", "lvl": "target", "msg": "myiwg20m: # [6nexport PS1=\\\"lava-test: # \\\""} - {"dt": "2017-09-11T05:19:05.311542", "lvl": "debug", "msg": "auto-login-action duration: 3.93"} - {"dt": "2017-09-11T05:19:05.312062", "lvl": "results", "msg": {"case": "auto-login-action", "definition": "lava", "duration": !!float "3.929234027862549", "extra": !!python/object/apply:collections.OrderedDict [[["success", "No kernel warnings or errors detected."]]], "level": "1.5.5", "result": "pass"}} - {"dt": "2017-09-11T05:19:05.313427", "lvl": "debug", "msg": "start: 1.5.6 expect-shell-connection (max 120s)"} - {"dt": "2017-09-11T05:19:05.313967", "lvl": "debug", "msg": "expect-shell-connection: Waiting for prompt myiwg20m: # , lava-test: # "} - {"dt": "2017-09-11T05:19:05.314522", "lvl": "debug", "msg": "expect-shell-connection: Wait for prompt ['myiwg20m: # ', 'lava-test: # ']. 300 seconds"} - {"dt": "2017-09-11T05:19:05.315249", "lvl": "target", "msg": "export PS1=\\\"lava-test: # \\\""} - {"dt": "2017-09-11T05:19:05.315963", "lvl": "debug", "msg": "expect-shell-connection duration: 0.00"} - {"dt": "2017-09-11T05:19:05.316851", "lvl": "debug", "msg": "start: 1.5.7 export-device-env (max 120s)"} - {"dt": "2017-09-11T05:19:05.317390", "lvl": "debug", "msg": "export-device-env duration: 0.00"} - {"dt": "2017-09-11T05:19:05.317890", "lvl": "debug", "msg": "Setting default test shell prompt"} - {"dt": "2017-09-11T05:19:05.318373", "lvl": "debug", "msg": ["myiwg20m: # ", "lava-test: # "]} - {"dt": "2017-09-11T05:19:05.318902", "lvl": "debug", "msg": "uboot-retry: Wait for prompt ['myiwg20m: # ', 'lava-test: # ']. 240 seconds"} - {"dt": "2017-09-11T05:19:05.339032", "lvl": "debug", "msg": "uboot-retry duration: 8.48"} - {"dt": "2017-09-11T05:19:05.339643", "lvl": "info", "msg": "uboot-action duration: 8.50"} - {"dt": "2017-09-11T05:19:05.340189", "lvl": "info", "msg": "start: 2 lava-test-retry (max 300s)"} - {"dt": "2017-09-11T05:19:05.340724", "lvl": "debug", "msg": "start: 2.1 lava-test-shell (max 300s)"} - {"dt": "2017-09-11T05:19:05.341253", "lvl": "info", "msg": "Executing test definitions using ShellSession"} - {"dt": "2017-09-11T05:19:05.341753", "lvl": "debug", "msg": {"sending": "#\n"}} - {"dt": "2017-09-11T05:19:05.442940", "lvl": "target", "msg": "lava-test: # [6n#"} - {"dt": "2017-09-11T05:19:05.443483", "lvl": "debug", "msg": "lava-test-shell: Wait for prompt ['myiwg20m: # ', 'lava-test: # ']. 300 seconds"} - {"dt": "2017-09-11T05:19:05.446189", "lvl": "target", "msg": "#"} - {"dt": "2017-09-11T05:19:05.469109", "lvl": "exception", "msg": "Traceback (most recent call last):\n File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py\", line 290, in run_actions\n new_connection = action.run(connection, args)\n File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/actions/test/shell.py\", line 243, in run\n for running in xrange(stage + 1):\nTypeError: unsupported operand type(s) for +: 'NoneType' and 'int'\n"} - {"dt": "2017-09-11T05:19:05.470260", "lvl": "debug", "msg": "start: 3.1 power_off (max 5s)"} - {"dt": "2017-09-11T05:19:05.470796", "lvl": "info", "msg": "nice curl http://admin:<omitted>@192.168.11.68/set.cmd?cmd=setpower+p61=0"} - {"dt": "2017-09-11T05:19:05.534407", "lvl": "debug", "msg": !!python/unicode "command output % Total % Received % Xferd Average Speed Time Time Time Current\n Dload Upload Total Spent Left Speed\n\r 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0\r100 20 0 20 0 0 371 0 --:--:-- --:--:-- --:--:-- 377\n<html>p61=0</html>\r\n"} - {"dt": "2017-09-11T05:19:05.535945", "lvl": "debug", "msg": "power_off duration: 0.07"} - {"dt": "2017-09-11T05:19:05.536462", "lvl": "results", "msg": {"case": "power_off", "definition": "lava", "duration": !!float "0.06516695022583008", "extra": !!python/object/apply:collections.OrderedDict [[["status", "success"]]], "level": "3.1", "result": "pass"}} - {"dt": "2017-09-11T05:19:05.644487", "lvl": "error", "msg": "Status: Incomplete\nErrors ['Traceback (most recent call last): File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py\", line 290, in run_actions new_connection = action.run(connection, args) File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/actions/test/shell.py\", line 243, in run for running in xrange(stage + 1):TypeError: unsupported operand type(s) for +: \\'NoneType\\' and \\'int\\'', 'Incomplete']"} - {"dt": "2017-09-11T05:19:05.646006", "lvl": "exception", "msg": "Traceback (most recent call last):\n File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py\", line 290, in run_actions\n new_connection = action.run(connection, args)\n File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/logical.py\", line 57, in run\n new_connection = self.internal_pipeline.run_actions(connection)\n File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py\", line 302, in run_actions\n raise RuntimeError(action.errors)\nRuntimeError: ['Traceback (most recent call last): File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py\", line 290, in run_actions new_connection = action.run(connection, args) File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/actions/test/shell.py\", line 243, in run for running in xrange(stage + 1):TypeError: unsupported operand type(s) for +: \\'NoneType\\' and \\'int\\'']\n"} - {"dt": "2017-09-11T05:19:05.647870", "lvl": "debug", "msg": "start: 3.1 power_off (max 5s)"} - {"dt": "2017-09-11T05:19:05.648393", "lvl": "debug", "msg": "power_off duration: 0.00"} - {"dt": "2017-09-11T05:19:05.648864", "lvl": "results", "msg": {"case": "power_off", "definition": "lava", "duration": !!float "3.0994415283203125e-05", "extra": !!python/object/apply:collections.OrderedDict [[["status", "success"], ["duration", !!float "0.06516695022583008"], ["connection-timeout", !!float "300.0"], ["timeout", !!float "5.0"], ["level", "3.1"]]], "level": "3.1", "result": "pass"}} - {"dt": "2017-09-11T05:19:05.650619", "lvl": "error", "msg": "status: ['Incomplete']"} Any hint of what's going on? # One thing I don't understand is that even though I have set the "prompts" variable on the job, LAVA seems to force it to become "lava-test: #". Thanks, Daniel

8 years, 6 months

← Newer
1
...
78
79
80
81
82
83
84
...
95
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users