Hi there,
When I run LAVA hacking session on Juno but found sometimes Juno
cannot be allocated IP properly:
- I created multinode definition for Juno:
https://validation.linaro.org/scheduler/job/845471.0: this
definition is to launch kvm so I can run testing suits on it;
https://validation.linaro.org/scheduler/job/845471.1: this
definition is to launch "deploy_linaro_image" on Juno board;
- After launched these two images, the kvm usually can work well and I
can smoothly log in it with ssh;
- But for juno board, it will have below log for ssh:
395.1 ./setup_session_oe: line 38: /etc/init.d/ssh: No such file or directory
395.2 <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=sshd-restart RESULT=fail>
395.3 sshd re-start failed
395.4 Target's Gateway: 10.0.0.1
395.5 ip: RTNETLINK answers: Network is unreachable
395.6
395.7
395.8 *********************************************************************************************
395.9 Please connect to: ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no root@ (juno-07)
395.10 *********************************************************************************************
395.11
So finally I cannot get the info for Juno's IP and cannot log in it
with ssh. It's not everytime I can reproduce this failure, so sometimes
it's lucky so I can get a correct IP.
- As a workaroud, I found if I create two saperated definitions for
Juno and kvm independently, then Juno's IP issue can be resolved:
https://validation.linaro.org/scheduler/job/845552https://validation.linaro.org/scheduler/job/845561
So could you help give suggestions for this?
Thanks,
Leo Yan
Hi,
I have made a test setup with LAVA to run some test cases on my AM335X
based platform. I want to execute some simple test cases like testing
the status of "ifconfig eth0" command. I don't want to deploy any image
and my goal is to execute only this test directly(target is booted with
root file system mounted).I have the below job submitted to the lava
worker. ethernet.yaml contains the shell script which actually performs
the ifconfig test.
=============================================================================================
{
"actions": [
{
"command": "dummy_deploy",
"parameters": {
"target_type": "oe"
}
},
{
"command": "lava_test_shell",
"parameters": {
"testdef_repos": [
{
"testdef": "/root/lava_tests/yaml/ethernet.yaml"
}
],
"timeout": 60
}
},
{
"command": "submit_results_on_host",
"parameters": {
"server": "http://10.24.252.13:81/RPC2/",
"stream": "/anonymous/lavaserver/"
}
}
],
"device_type": "ELIN",
"health_check": false,
"job_name": "elin-ethernet-test",
"logging_level": "DEBUG",
"timeout": 60
}
=======================================================================================================
Lava dispatcher is able to connect to the target and start the job. But
finally I am getting a timeout. Please find the attached log for
details. I can see that after connecting with the target the dispatcher
is checking/finding some information related to the file system, and
looks like it is getting timed out there. How can I avoid this and make
the dispatcher to directly perform the test on the target platform?
Any help any help would be appreciated.
Best Regards,
Pradeepkumar Soman
Hi all,
We are using LAVA to run jobs from KernelCI which is a test automation
system used to test latest versions of the kernel (upstream, next,
stable, ...). Our main goal is to put in our lab a maximum of boards
which are not yet in KernelCI to provide boot reports for these boards.
However, for some of these, we own a single copy while we definitely
need to work on them to add new features or improve them.
What we could do (and what we are currently doing), is to manually put a
board in maintenance mode, take it physically outside of the lab, work
on it and put it back in the lab when we have finished working on it.
This is not really efficient and during the time the board is physically
outside of the lab, not a single job (from KernelCI or ours) can run.
We would like to create a tool to be able to remotely control our boards
while they still are physically in the lab. We need to be able to do
everything we could do if the board would be on our desk. This means
getting the serial connection, powering on or off the board and sending
files (kernel, DTB, initramfs, ...) to it.
For the latter, we just have to copy the files in the directory used by
the TFTP server of LAVA master node.
I would like to know if it is possible to add an endpoint in the API to
power on or off a given board? Is it possible to get the serial
connection over the API?
To put a board virtually outside of the lab, we need to put it into
maintenance mode in LAVA. As of yet, this is only possible from the
browser, right? It would be great if we could add two endpoints to the
API: one for putting a board offline and one for putting a board online,
so we can remotely manage from our program whether a board is in the lab.
We may have few people working on the same board. Therefore, we need a
way to ensure only one person is able to use this board at a certain
time. I've seen the "created_by" attribute in the
DeviceStateTransition[1] which could help us to find who last put the
board virtually outside of the lab and thus denying access to other
users. However, we do not have a way to get this information today via
the API. Is it possible to add an endpoint to get the status of a given
device (like in 'all_devices'[2] but for one device) and the associated
user responsible of the last device state transition?
I can help with patches if you agree to add these endpoints to the API.
Thanks,
Quentin
[1]
https://github.com/Linaro/lava-server/blob/release/lava_scheduler_app/model…
[2]
https://github.com/Linaro/lava-server/blob/release/lava_scheduler_app/api.p…
The Cambridge LAVA Lab has a transparent squid proxy which saves having
to configure each dispatcher and device to use it. Outgoing HTTP
traffic from the lab has
no choice as it is intercepted at the internet gateway.
We did this because even after configuring the dispatcher, and
devices, it's almost
impossible to make all test shell tasks use the proxy. LAVA sets a
shell environment
inside a job but many of the clients in the various different types of
job simply ignore it.
Chasing every test writer was not feasible as the lab usage is so
large, but might be ok
in a smaller lab with tighter control of the jobs.
We don't proxy HTTPS requests because that's becomes very complicated
with faking
certificates etc
>>Marc Titinger <mtitinger at baylibre.com> writes:
>>
>> I had to make this change to get squid3 going with our LAVA 1.0 machine.
>> I thought this could be useful. I did not test extensively though.
>
>FWIW, I had problems getting lava-dispatcher to use my local squid proxy
>also. Seems setting LAVA_PROXY in lava-dispatcher.conf was working for
>the the devices (lava set the environment variable after booting the
>target), but lava-dispatcher itself was not using the proxy.
>
>I'll give this a try as well.
>
>Kevin
From: Marc Titinger <mtitinger(a)baylibre.com>
search_substr_from_array would return a false positive
in lava_dispatcher/downloader.py when trying to match
'no_proxy' exclusion list with the download object url.
This now uses a (too?) simple substring matching rather
than a greedy regex.
Signed-off-by: Marc Titinger <mtitinger(a)baylibre.com>
---
lava_dispatcher/utils.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lava_dispatcher/utils.py b/lava_dispatcher/utils.py
index f2fd79a..037f6b5 100644
--- a/lava_dispatcher/utils.py
+++ b/lava_dispatcher/utils.py
@@ -640,7 +640,7 @@ def search_substr_from_array(string, array, sep=','):
Strings in array are separated by default with ','
"""
for obj in array.split(sep):
- if re.search('.*' + str(obj) + '.*', str(string)):
+ if str(obj).find(string) is not -1:
return True
return False
--
2.5.0
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
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
