-----Original Message----- From: Neil Williams [mailto:neil.williams@linaro.org] Sent: Wednesday, September 27, 2017 12:12 AM On 26 Sep 2017 2:59 am, "Daniel Sangorrin" <daniel.sangorrin@toshiba.co.jp mailto:daniel.sangorrin@toshiba.co.jp > wrote:
Hi Neil,
-----Original Message----- From: Neil Williams [mailto:neil.williams@linaro.org 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@toshiba.co.jp mailto:daniel.sangorrin@toshiba.co.jp > wrote:
-----Original Message----- From: Neil Williams [mailto:neil.williams@linaro.org 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@toshiba.co.jp mailto:daniel.sangorrin@toshiba.co.jp > wrote:
Hi Neil,
Thanks for your reply.
-----Original Message----- From: Neil Williams [mailto:neil.williams@linaro.org 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@toshiba.co.jp mailto:daniel.sangorrin@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
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-...
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...
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
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-dispa...
You need a file named according to the hostname of the dispatcher as it appears in the dispatcher-master log file.
Thanks Neil. That worked.
This is what I did: # lava-server manage workers list * lava-docker (2 devices) # cp /usr/share/lava-dispatcher/dispatcher.yaml to /etc/lava-server/dispatcher.d/lava-docker.yaml # vi /etc/lava-server/dispatcher.d/lava-docker.yaml dispatcher_ip: 192.168.1.66 # service lava-server restart # service lava-slave restart <-- just in case I restarted both
By the way, I noticed that modifying the dispatcher.yaml directly also works (at least on a single host configuration): # vi /usr/share/lava-dispatcher/dispatcher.yaml dispatcher_ip: 192.168.1.66
I guess the master checks that file in case there are no files at /etc/lava-server/dispatcher.d/. Of course, editing under /etc is much cleaner.
Thanks, Daniel