I am building lava test system and currently add new addvice.
According to document than step of "Adding a dictionary to the first QEMU device",follow config items neet to write to .jianja2 file.
{% extends 'qemu.jinja2' %}
{% set mac_addr = '52:54:00:12:34:59' %}
{% set memory = '1024' %}
Which file is to be writen to above config items ?does its directory path must be at path:/etc/lava-server/dispatcher-config/device-types/?
How to make these items take effect immediatly?which command to use to take effect above config items? the document is not said.
Hi,
I using LAVA version 2018.5-post1 to boot from USB thumb drive using Yocto Project's image. The LAVA job definition contain 2 deployments and booting actions. The first deployment is deploy the image to NFS server and boot using TFTP method. The second deployment is download an image to DUT and flash it on USB thumb drive. The DUT was able to download the image however it failed at flash to thumb drive. I'm use dd command as my tool to flash the image. Below is an example on lava-job definition and output message from LAVA. Due to this issue, I unable to boot from USB thumb drive. Did anyone know what is the problem?
Snipped code from lava-job definition to deploy on USB thumb drive
- deploy:
timeout:
minutes: 30
to: usb
image:
url: file:///home/user/image/yocto-image.xz
compression: xz
root_partition: 1
device: 'boot'
download:
tool: '/usr/bin/wget'
prompt: 'HTTP request sent, awaiting response...'
options: '--S {DOWNLOAD_URL}'
os: oe
The command from LAVA
wget http://lavadisptcher.com/tmp/storage/image/yocto-image.xz | dd of=/dev/disk/by-id/<myusbthumdriveid> bs=4M
This is the output message form LAVA after download flash the image
0+0 records in
0+0 records out
0 bytes copied
Regards,
Alim Hussin
Hi,
I think the lava web document is relatively simple.I still have some basic questions that didn’t understand.
I want to add new real board(for example the arm development board,includes serial,ethernet interface etc)into lava environment. The board had ordinary uboot program, and uboot can download linux kernel image by ethernet interface. If treat it as DUT to run test,do the uboot and kernel program need to be modified or both configuration need to be modified?
When used real board(not qemu),is the uboot image location specified in the job definition file? If so, what keyword is used to indicate the uboot image location?
The lava document description is not enough.
Hello
I have a cubietruck in LAVA, but its devicetype does not follow the rule "devicetype should be the same as devicetree name".
Diverting from this rule, make difficult to find if the device is already handled by LAVA.
I have lots of other boards which suffer the same problem (odroid-xu3 for example)
Do you already have a process for renaming devicetype ?
If not, why about duplicating to the correct name (sun7i-a20-cubietruck) and adding some tags (comment like "{# set deprecated = true}") to the old one.
The deprectation warning could be printed by the LAVA web interface like the warning about not having health checks.
After some release, the deprecated devicetype could be removed.
Regards
Does board test system must include PDU device?
If test system has no PDU and in job definition the boot action method is u-boot. When board had startup to enter linux interactive environment and submit job at this time. Then how does dispatcher restart the board?
Hi LAVA team,
I meet one critical error.
We restart our LAVA server host machine. We can’t know how to restart our LAVA server service.
Could you tell me how to restart LAVA server master service with detail steps? Thanks!
The LAVA server is not installed by us. So we are not clear about this.
BR/Zhanghui
https://validation.linaro.org/static/docs/v2/actions-boot.html#index-9
- setenv loadkernel 'tftp {KERNEL_ADDR} {KERNEL}'
It say the {KERNEL} will be substituted. Where is {KERNEL} variable defined? When I submit job definition by web interface,I did't find where to define {KERNEL} variable
Hi,
I'm trying to use a situation where a large bulk of similar jobs are being sent to several devices of the same device type. These devices require the 'transfer_overlay' option in order for the tests to work due to their setup. We currently are using a single master and worker on the same server.
It seems that the same transfer overlay file location (i.e., /var/lib/lava/dispatcher/tmp/overlay-1.3.2.5.tar.gz) is used regardless of the job id and that some of our jobs are experiencing a collision trying to use different copies of that file at the same time. Thus, one of our jobs is deleting the transfer overlay file before another job tries to delete it and the second gets errors.
This is the error LAVA produces when viewing the job in the GUI:
File "/usr/bin/lava", line 11, in <module>
load_entry_point('lava-tool==0.25', 'console_scripts', 'lava')()
File "/usr/lib/python2.7/dist-packages/lava/tool/dispatcher.py", line 150, in run
raise SystemExit(cls().dispatch(args))
File "/usr/lib/python2.7/dist-packages/lava/tool/dispatcher.py", line 140, in dispatch
return command.invoke()
File "/usr/lib/python2.7/dist-packages/lava/dispatcher/commands.py", line 247, in invoke
self.args.validate)
File "/usr/lib/python2.7/dist-packages/lava/dispatcher/commands.py", line 91, in run_pipeline_job
exitcode = job.run()
File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/job.py", line 340, in run
self.cleanup(self.connection)
File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/job.py", line 375, in cleanup
self.pipeline.cleanup(connection)
File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py", line 251, in cleanup
child.cleanup(connection)
File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py", line 649, in cleanup
self.internal_pipeline.cleanup(connection)
File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py", line 251, in cleanup
child.cleanup(connection)
File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py", line 649, in cleanup
self.internal_pipeline.cleanup(connection)
File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py", line 251, in cleanup
child.cleanup(connection)
File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/actions/boot/__init__.py", line 458, in cleanup
os.unlink(self.url)
OSError: [Errno 2] No such file or directory: '/var/lib/lava/dispatcher/tmp/overlay-1.3.2.5.tar.gz'
We are working on the 2017.7 build of LAVA, so if this has been changed in a later build, please let me know. If this has not been updated, is there another way to change things so that each job uses a different name and/or location for the overlay file?
Thanks,
Jorgen Peddersen
Jorgen Peddersen
Researcher
t +61 2 6103 4700
m
e jorgen.peddersen(a)seeingmachines.com
a 80 Mildura Street, Fyshwick ACT 2609, Australia
SEEINGMACHINES.COM<http://seeingmachines.com>
[SEEINGMACHINES]
This email may contain confidential information. If you are not the intended recipient, destroy all copies and do not disclose or use the information within. Any content that is not concerned with the business of the Seeing Machines Group reflects the views of the sender only, not those of Seeing Machines. No warranties are given that this email does not contain viruses or harmful code. [http://www.seeingmachines.com/wp-content/uploads/2018/04/sm-email-twitter-i…] <https://twitter.com/seeingmachines> [http://www.seeingmachines.com/wp-content/uploads/2018/04/sm-email-linkedin-…] <https://www.linkedin.com/company/258949/>
Hello
I have queued jobs that I want to cancel but I get instead:
500 Internal Server Error
[Errno 2] No such file or directory: '/var/lib/lava-server/default/media/job-output/2018/07/10/7181/job_data.gz'
when I click on cancel.
Note that thoses queued jobs are only queued and not assigned to any device.
Regards
Hi,
I'm sending this email to confirm if anyone has encountered the same problem as me when using LAVA...I have installed a lava single node instance in a docker container and are trying to add an Android device for testing. But when I ran the adb devices command, in addition to the Android device I connected, an "emulator-5554 connecting" appeared. I have tried many ways to remove this device but I failed. I am sure that the emulator appeared after the docker container containing LAVA instance started, so I wonder if this issue is related to LAVA.
Thanks
Jiayan Kong
> Just configure the worker to connect to your master.
> This is done in /etc/lava-dispatcher/lava-slave
> An example configuration file is available at /usr/share/lava-dispatcher/
lava-slave
>
> For a first try, you can start without encryption and only define the
following variables in the configuration file:
> MASTER_URL="tcp://localhost:5556"
> LOGGER_URL="tcp://localhost:5555"
Hello Remi,
Do you, Linaro guys, have some Open Source Lava Server on the Cloud, where
I can create lava admin account, hook to it my Lava Worker and try it?
I need some access to create device-type BeagleBone Black and device BBB0x
as well.
This will be interesting experiment, don't you agree?
Thank you,
Zoran Stojsavljevic
_______
On Tue, Aug 7, 2018 at 1:53 PM, Remi Duraffort <remi.duraffort(a)linaro.org>
wrote:
> Hello,
>
> the worker will register itself to the master automatically. You don't
> have to create the worker manually.
>
> Just configure the worker to connect to your master.
> This is done in /etc/lava-dispatcher/lava-slave
> An example configuration file is available at /usr/share/lava-dispatcher/
> lava-slave
>
> For a first try, you can start without encryption and only define the
> following variables in the configuration file:
> MASTER_URL="tcp://localhost:5556"
> LOGGER_URL="tcp://localhost:5555"
>
> You can also specify the HOSTNAME if you want. By default the slave will
> use the name of the server it's running on.
>
> This will instruct you local lava-slave (this is the name of the service)
> to connect to the local lava-master.
> Then restart the lava-slave with "service lava-slave restart"
>
>
The document about installing lava system, does "Single Master Instance installation " mean master(include lava-server) and worker(include lava-dispatcher) can be installed in the one physical computer? In this simple mode,wheather the worker(logic unit)must only have one?
I am ready to deploy a local lava single master demo system. The server and dispatcher had be installed in a single computer.
In order to enable the server to kno the dispatcher(worker),Then how to configure something.
Is doing this?:
sudo lava-server manage workers add <HOSTNAME> ,that HOSTNAME is changed in /etc/lava-dispatcher/lava-slave file?
And when did,How to see whether dispatcher is working already?
Hi,
According to lava installation document ,I had installed lava-server to debian 9.5.0.Creating super user operation is ok(sudo lava-server manage createsuperuser --username $USERNAME --email=$EMAIL) . But when using firefox browser to login in by created name , response message:
--
SRF verification failed. Request aborted.
You are seeing this message because this site requires a CSRF cookie when submitting forms. This cookie is required for security reasons, to ensure that your browser is not being hijacked by third parties.
If you have configured your browser to disable cookies, please re-enable them, at least for this site, or for 'same-origin' requests.
--
After configured browser to disable cookies,the response is still so.
Jiang Lao
Hi,If there is no “dameon” program in DUT. How to add/update the program running in DUT
for example application test program or linux kernel or uboot etc.?Jiang Lao
--------------------------------------------
On Wed, 1 Aug 2018 at 10:18, ljh_dev <ljh_dev at 126.com> wrote:
> Hi,
> I have browsed the website documentation of lava overall. I think the
> DUT(Device Under Test) should has "dameon" program to communicate with the
> Worker Dispatcher module. But I did not find where the DUT "dameon"
> program source code is,and how to build&install this DUT "dameon" program.
>
It does not need to be built or installed. The lava-dispatcher package does
all that work for you.
https://validation.linaro.org/static/docs/v2/index.html#architecturehttps:/…
/var/log/lava-dispatcher/lava-slave.log
If there is no "dameon" program in DUT. How to add/update the program running in DUT for example application test program or linux kernel or uboot etc.?
Best regards,
Hi,
I have browsed the website documentation of lava overall. I think the DUT(Device Under Test) should has "dameon" program to communicate with the Worker Dispatcher module. But I did not find where the DUT "dameon" program source code is,and how to build&install this DUT "dameon" program.
thanks,
Jiang Lao
Hello Lava Users,
We are creating queries in LAVA and adding multiple conditions to query.For
example in our yaml job definition we have included os field in metadata
section which will have different values.For example following is the
metadata section for 2 different jobs
Job1:
metadata:
description: '"Build SiemensIPC-327E target with latest build"'
os: Debian
device: imx6q
Build_ID: QA-BUILD-F0150
Job2:
metadata:
description: '"Build SiemensIPC-327E target with latest build"'
os: Ubuntu
device: imx6q
Build_ID: QA-BUILD-F0150
Now with queries I am trying to just filter out job running with Build_ID(
QA-BUILD-F0150 ) and on only os debian.
Entity Field Operator Value
namedtestattribute
Build_ID
exact
QA-BUILD-F0150
namedtestattribute
os
exact
Debian
When I am creating queries with above information, as a user when I run the
query the query results will just list Job1 information but at present in
LAVA both the jobs are getting listed. Is this the expected behavior?The
LAVA server version used is 2018.5.post1 release.
Thanks,
Hemanth.
Hello everyone,
is there any documentation on how Linaro uses Salt for configuring LAVA nodes? I know the infrastructure code is hosted at https://git.linaro.org/lava/lava-lab.git, but since I am new to Salt (and configuration management in general), I would love to have some kind of starting point.
Where is this repository checked out? Who applies the defined Salt states and when? Are there any automatic processes happening when someone commits to the repository (e.g. changing a device type or health check job)? What is Linaro's workflow in these cases?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz
Hi,
I just install lava-server to latest release, 2018.5-post1 & created a local Django account. I unable to login using lava webpage from my local machine. Lava webpage did not prompt any error message and I have no idea how to debug this problem.
Any idea?
Regards,
Alim Hussin
Hello,
In my LAVA pipeline I have the following snippet:
notify:
recipients:
- to:
method: email
mail: diego.russo(a)arm.com
criteria:
status: finished
verbosity: verbose
When the job ends though I'm not receiving any email. I've looked at the documentation, but I couldn’t find anything about mail configuration. Logs also are not very helpful to debug this issue.
How/where can I configure the email client? I'm also interested in changing the "from:" field.
Thanks
--
Diego Russo
Staff Software Engineer - diego.russo(a)arm.com
Direct Tel. no: +44 1223 405920
Main Tel. no: +44 1223 400400
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - http://twitter.com/diegorhttp://www.linkedin.com/in/diegor
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello Lava-Users,
I have UEFI based x86 target board which I want to connect to LAVA and
execute tests.
When I go through
https://validation.linaro.org/static/docs/v2/integrate-uefi.html it
specifies different mechanism available.I am confused here as I am not
completely clear on differences between systems mentioned.
If I just know UEFI implementations method of target is it enough to select
which method can be used for booting.
What are the things I need to know before concluding the method to be used
for booting x86 based target board?
Thanks,
Hemanth.
Hey,
Where I work, we've been using LAVA since 2014 to test our in-house Linux distribution. Our devices are typically "low-end" devices with 128 to 256 MB RAM and up to 512 MB NAND flash. We use LAVA to test our BSPs, e.g lots of connectivity/interface/IO tests. We also use it for stability-testing and performance testing (like measuring the application context switch time or Ethernet TX rates).
For a while, there has been a growing concern within our team that LAVA might not be ideal for our testing needs. Right now, the team is discussing if we should drop LAVA and use something else. There is even talks about developing our own test framework. I personally like the idea behind LAVA but also agree that it has been a bumpy road these past 4 years. Due to various bugs and missing features, we've several times been forced to upgrade to an unstable version of LAVA just to get normal operations working. Two times we've lost the entire test database because we were unable to recover from a LAVA upgrade. In those cases, it was easier for us to just "start over". Today we use LAVA 2018.02. I've compiled a list that summarize the most pressing issues we've experience with LAVA:
1. Test development is slow. Several members of my team avoids test development because the process of developing a test with LAVA is tedious / very timeconsuming. I think it mostly boils down to making a change, pushing it to a Git repo, submitting a job, running the job and then watching the LAVA job output for result. This will in our environment take several minutes, just to verify a change in a test.
I'm aware of the guidelines for making portable tests and I personally think we can be a lot better at it for single-node tests which could enable us to run testscripts on local devices, but we have also quite a number of multinode jobs that we find are difficult to run in any other environment than LAVA. We've also tried using hacksessions to speed up development (e.g you edit the tests on the DUT and then synchronize it back to your host once you're happy). This works quite well, but feels a bit hacky and if the hacksession timeout hits, you lose all your work ;-)
2. Can't test bootloaders. Several of our hardware contain FPGAs and the FPGA images / "firmware" is tightly bundled with the bootloader. In addition to configuring the FPGA, the bootloader also contains in-house developed code for firmware update that we would like to autotest. We have a _lot_ of bootloader variants and we need a way of testing it along with the Linux system. Our current setup is that we manually flash bootloaders in our LAVA lab and then cross our fingers that the Linux system we test on the device is compatible with the bootloader. The ideal situation for us would be to always test the Linux system and the matching bootloader together. Granted, the better solution would be to move away the FPGA loading from the bootloader, but this is a design chosen by our SoC provider and we prefer to keep it.
We also manage a "LTS" branch of our Linux distro. We support it for several years and we need to ensure our test setup can test both our "master" branch and our LTS branch. With our current setup, this is not possible because all devices in our lab runs a bootloader that was manually flashed at some arbitrary time.
We've considered setting up several hardware of the same type, but with different bootloaders and then let LAVA treat them as different device types. This would work but our lab would fill up fast and the usage of each device would be low.
We also tried making jobs that boot a golden Linux system, write the software under test (including bootloader), reboot and run tests. This did work, but required customization per device since the test has to know where to write the bootloader. We would rather put this information into the LAVA device type definition somehow.
3. Can't write to NAND. Our devices are NAND-based and we use UBIFS ontop of UBI. We have not found a way for LAVA to write NAND because the LAVA mechanism that embeds stuff into the rootfs before deployment doesn't support UBIFS. At the moment, we ramboot our devices but we are now at a point where our devices OOM because they don't have enough RAM to fit both the rootfs and running the tests. Our current solution is to split the job into several jobs that each run a smaller amount of tests, but this is less than ideal because it makes our test run slower (we need to reboot) and it is a bit annoying that test results are spread across several jobs.
We have our own deployment tool that would be nice to integrate into LAVA as a deployment method. It accepts a kernel, rootfs, DT and bootloader and will write it using TFTP or DFU (USB) depending on target. To avoid forking all of LAVA in order to implement such deploy method, is there any plugin architecture that allows us to install additional boot methods alongside the LAVA packages?
I'd love to get your views on these issues and if there is a solution when using LAVA.
Best regards, Magnus.
Hello Lava-Users,
We are running tests on imxqsaberlite target in LAVA .The Lava version
that we are using is 2018.4 release.
We are facing 2 issues
1.Related to auto_login section in boot action.When we are specifying the
username as root in auto_login section sometimes out of 5 tries once the
root is getting changed as "oroot" due to which test execution is failing
Following is the boot action part of job definition
- boot:
namespace: nfs_boot
repeat: 3
method: u-boot
commands: nfs
auto_login:
login_prompt: 'login:'
username: root
prompts:
- 'root@mx6q:~#'
timeout:
minutes: 10
Following is the job log output
Matched prompt #6: login: Sending username root root mx6q login:root
auto-login-action: Wait for prompt ['root@mx6q:~#', 'Login incorrect',
'Login timed out'] (timeout 00:07:24) orot
2.Related to the Repeat action block of LAVA
https://validation.linaro.org/static/docs/v2/actions-repeats.html?highlight…
We are trying to use repeat action in boot action part of job definition as
we want to repeat booting of the target 3 times.Issue we are facing is it
is not stopping at the end of 3 iterations of boot and it is continuing
till the timeout specified duration of the job.
Thanks,
Hemanth.
Hi Dan,
>Here's an example of generating lava templates using jinja2. It's probably more complicated than you need.
>
>See
>https://git.linaro.org/ci/job/configs.git/tree/openembedded-lkft/lava-job-d…
>for a directory of templates, and see
>https://git.linaro.org/ci/job/configs.git/tree/openembedded-lkft/submit_for…
>for the python code that does the generation. Lastly, you can run https://git.linaro.org/ci/job/configs.git/tree/openembedded-lkft/test_submi…
>and it will generate all of the YAML files into "./tmp".
>
>Like I said, this is likely more complicated than you are looking for. I suggest starting simpler using https://pypi.python.org/pypi/jinja2-cli/0.6.0.
Thank you, that really helps a lot. We want to trigger the LAVA jobs from Jenkins as well, and we need lots of metadata because the tests will be part of our release notes in the end. So no, this is definitely not more complicated than we need. In fact, this is a very good starting point for us.
You should think about adding a chapter to the LAVA documentation about how to generate YAML job submissions via templates. I assume we are not the only ones facing this problem. And I had basically no experience with jinja2 at all before evaluating LAVA, so I would not have come up with the idea of using this mechanism for the job submissions myself.
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz
Hi,
I am getting the below error while adding device-dictionary for my device "xyz" for my worker "worker"
$ sudo lava-tool device-dictionary http://worker@url/RPC2/ xyz --update xyz.jinja2
Updating device dictionary for xyz on http://worker@url/RPC2/
<Fault 400: 'Unable to store the configuration for xyz on disk'>
Please help.
Regards,
Raghu
Hi LAVA mainters,
Nice to meet you.
I want to add my pub key after LAVA installed container.
But I don't which parameters should I need add in my job xx.yaml file.
Could you give me some help and advice.
>>>>>>>>>>>>>>> Some part information of my xx.yaml file: <<<<<<<<<<<<<<<<<<<<<<<<<<
actions:
- deploy:
timeout:
minutes: 300
to: lxc
os: ubuntu
packages: [python, wget, unzip, python-pexpect, python-serial, openssh-server]
- boot:
prompts:
- '[root(a)(.*) /]#'
timeout:
minutes: 300
method: lxc
- test:
timeout:
minutes: 300
gefinitionsg
- run:
steps:
lava-test-shell: echo "------------------------------------- debug 1 -----------------------"
lava-test-shell: wget --no-proxy -q http://otcpkt.bj.intel.com/downloads/pubkey/sys_oak.zip
lava-test-shell: mkdir -p ~/.ssh
lava-test-shell: unzip sys_oak.zip -d ~/.ssh
definitions:
- repository: ssh://sys_oak@git-amr-4.devtools.intel.com:29418/pk_osi_test-source.git
from: git
path: <device>/<test_type>_lxc.yaml
name: <test_type>-<device>
params:
BUILD_NUMBER: <build_number>
IMAGE_URL: <image_url>
PRODUCT: <build_name>
IRC_USER: "sys_oak"
PUB_KEY: "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDCDJvT5UPE***************************
>>>>>>>>>>>>>>> Some part information of my xx.yaml file: <<<<<<<<<<<<<<<<<<<<<<<<<<
Best Regards
Zhanghui Yuan
OTC Production Kernel Integration Test
Hi,
We are doing boot regression test using (in DB{410,820}c) an Android boot
image that contains a ramdisk [1].
We aim to do functional testing in a way that if the basic testing fails
the next test definition dosen't run, that's implies dependencies over
-test entries in the job [2].
Does LAVA test shell provides this kind of functionality?
If not, any idea to achieve this functionality.
Regards,
Anibal
[1] https://validation.linaro.org/scheduler/job/1884978/definition
[2]
https://validation.linaro.org/scheduler/job/1884978/definition#defline117
The LAVA software team created a document to summarise the experience, so
far, of automating devices for validation and that document formed the
basis of a presentation at Linaro Connect in Hong Kong earlier this year by
Steve McIntyre.
The content has been living inside a wiki within Linaro but there have been
delays in making the URL visible to anonymous viewers. I have therefore
migrated the content to my blog:
https://linux.codehelp.co.uk/automation-and-risk.html
A link to the presentation is included.
Available under CC BY-SA 3.0 and shortly to appear on planet.debian.org
Please share with anyone involved in designing hardware which is likely to
end up on your desk for automation support and anyone else who may be
interested in the hardware challenges of device automation.
A second shorter post on Firmware Best Practices will follow - some of the
elements of that document were also covered in the presentation at Connect.
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
发件人: Neil Williams [mailto:neil.williams@linaro.org]
发送时间: 2018年6月26日 16:25
收件人: Chenchun (coston) <chenchun7(a)huawei.com>
抄送: Lava Users Mailman list <lava-users(a)lists.linaro.org>; Lixuan (F) <joe.lixuan(a)huawei.com>; Fengguilin (Alan) <fengguilin(a)huawei.com>; yangjianxiang <yangjianxiang(a)huawei.com>; Yewenzhong (jackyewenzhong) <jack.yewenzhong(a)huawei.com>; Liyuan (Larry, Turing Solution) <Larry.T(a)huawei.com>; zengmeifang <zengmeifang(a)huawei.com>; pangbo (A) <pangbo6(a)huawei.com>; liuchunfeng (A) <liuchunfeng2(a)huawei.com>; Zhangyi ac <zhangyi.ac(a)huawei.com>
主题: Re: [Lava-users] Some problem I met in Setting up CI environment using Lava2
On Tue, 26 Jun 2018 at 09:08, Chenchun (coston) <chenchun7(a)huawei.com<mailto:chenchun7@huawei.com>> wrote:
Hi all
Problem 1:
I find Lava2 re-download Test case repository if more than two test suite needed test in a lava job. Personal think this is waste of time. How can I make lava download Test
case repository only once in a lava job ( ps : all of our test suite in some repository) .I want to know lava can do or cant not do, if can please tell me how to do THX.
Not currently supported. We already support shallow clones by default and you can use the history option to remove the .git directory if you are short of space.
https://staging.validation.linaro.org/static/docs/v2/test-repositories.html…
We have looked at various options for this support - none were reliable across all devices & test jobs at scale.
Not due to short of space But spent so many time to re-download
Problem 2:
As all we know lava must install os before execute the test task in standard procedure. But in our practical application we find no need mechanical implementation of the
Process. In some case, we just need install os only ones and repeated test, even we install manually os and just use lava to do test. We want lava2 like M-lab install os and
execute test task uncoupling. we met the problems : can not judge the os installed in DUT(device under test ) whether is our SUT(system under test). All caused by very little
information can we read from DUT. I want to know how can I uncoupling install system and execute test ,user can choose only install os 、only execute test 、install os and execute
test 、install os ones and repeat execute test ...
That is entirely down to your own test shell definitions - follow best practice for portability and then run separate test actions.
Do not use simplistic testing with the problems of persistence - each test job needs to start with a clean setup, not whatever was left behind by a previous test job.
Please explain in more detail what you are actually trying to achieve.
The test writer can already choose to install (i.e. deploy) and then test - the test job specifies deploy, boot and test actions.
*If* the test writer knows that it is then safe to run other tests, those can be added into another job by extending the list of test definitions used by the action.
Not all device-types support rebooting the device between test actions in the same test job. This is a limitation of the hardware.
We want lava more smarter. do not re-deploy system if more than two lava job show the same type system(centos、ubuntu、debian)—just deploy system ones. We
have eliminated destructive cases
problem 3:
According to your experience, optimally how many DUT can mount under a lava worker and what is a constrain bottleneck?
That depends on a wide range of factors.
* What kind of test jobs are being run on the worker?
** TFTP is lighter load, fastboot is high load (1 CPU core per fastboot device + at least 1 core for the underlying OS)
* What is the I/O performance of the worker?
** Many images need manipulation and that can produce high I/O load spikes
* Infrastructure limits play a role as well - network switch load and LAN topology.
There is no definitive answer to your question.
Start small, scale slowly and test with known good functional tests at every change.
We will try fellow the rules: Start small, scale slowly and test with known good functional tests at every change.
Best
coston
_______________________________________________
Lava-users mailing list
Lava-users(a)lists.linaro.org<mailto:Lava-users@lists.linaro.org>
https://lists.linaro.org/mailman/listinfo/lava-users
--
Neil Williams
=============
neil.williams(a)linaro.org<mailto:neil.williams@linaro.org>
http://www.linux.codehelp.co.uk/
The mailing list does not accept a long list of people on CC - everyone who
is expecting a reply from the list needs to be subscribed to the list.
(This is part of the spam management for the list.)
---------- Forwarded message ---------
From: Neil Williams <neil.williams(a)linaro.org>
Date: Tue, 26 Jun 2018 at 09:25
Subject: Re: [Lava-users] Some problem I met in Setting up CI environment
using Lava2
To:
<chenchun7(a)huawei.com>
Cc: Lava Users Mailman list <lava-users(a)lists.linaro.org>, <
joe.lixuan(a)huawei.com>, <fengguilin(a)huawei.com>, <yangjianxiang(a)huawei.com>,
<jack.yewenzhong(a)huawei.com>, <Larry.T(a)huawei.com>, <zengmeifang(a)huawei.com>,
<pangbo6(a)huawei.com>, <liuchunfeng2(a)huawei.com>, <zhangyi.ac(a)huawei.com>
On Tue, 26 Jun 2018 at 09:08, Chenchun (coston) <chenchun7(a)huawei.com>
wrote:
> Hi all
>
> Problem 1:
>
> I find Lava2 re-download Test case repository if more than two test
> suite needed test in a lava job. Personal think this is waste of time. How
> can I make lava download Test
>
> case repository only once in a lava job ( ps : all of our test suite in
> some repository) .I want to know lava can do or cant not do, if can please
> tell me how to do THX.
>
Not currently supported. We already support shallow clones by default and
you can use the history option to remove the .git directory if you are
short of space.
https://staging.validation.linaro.org/static/docs/v2/test-repositories.html…
We have looked at various options for this support - none were reliable
across all devices & test jobs at scale.
>
> Problem 2:
>
> As all we know lava must install os before execute the test task in
> standard procedure. But in our practical application we find no need
> mechanical implementation of the
>
> Process. In some case, we just need install os only ones and repeated
> test, even we install manually os and just use lava to do test. We want
> lava2 like M-lab install os and
>
> execute test task uncoupling. we met the problems : can not judge the os
> installed in DUT(device under test ) whether is our SUT(system under test).
> All caused by very little
>
> information can we read from DUT. I want to know how can I uncoupling
> install system and execute test ,user can choose only install os 、only
> execute test 、install os and execute
>
> test 、install os ones and repeat execute test ...
>
That is entirely down to your own test shell definitions - follow best
practice for portability and then run separate test actions.
Do not use simplistic testing with the problems of persistence - each test
job needs to start with a clean setup, not whatever was left behind by a
previous test job.
Please explain in more detail what you are actually trying to achieve.
The test writer can already choose to install (i.e. deploy) and then test -
the test job specifies deploy, boot and test actions.
*If* the test writer knows that it is then safe to run other tests, those
can be added into another job by extending the list of test definitions
used by the action.
Not all device-types support rebooting the device between test actions in
the same test job. This is a limitation of the hardware.
>
> problem 3:
>
> According to your experience, optimally how many DUT can mount under a
> lava worker and what is a constrain bottleneck?
>
That depends on a wide range of factors.
* What kind of test jobs are being run on the worker?
** TFTP is lighter load, fastboot is high load (1 CPU core per fastboot
device + at least 1 core for the underlying OS)
* What is the I/O performance of the worker?
** Many images need manipulation and that can produce high I/O load spikes
* Infrastructure limits play a role as well - network switch load and LAN
topology.
There is no definitive answer to your question.
Start small, scale slowly and test with known good functional tests at
every change.
>
> Best
>
> coston
>
> _______________________________________________
> 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/
Hi all
Problem 1:
I find Lava2 re-download Test case repository if more than two test suite needed test in a lava job. Personal think this is waste of time. How can I make lava download Test
case repository only once in a lava job ( ps : all of our test suite in some repository) .I want to know lava can do or cant not do, if can please tell me how to do THX.
Problem 2:
As all we know lava must install os before execute the test task in standard procedure. But in our practical application we find no need mechanical implementation of the
Process. In some case, we just need install os only ones and repeated test, even we install manually os and just use lava to do test. We want lava2 like M-lab install os and
execute test task uncoupling. we met the problems : can not judge the os installed in DUT(device under test ) whether is our SUT(system under test). All caused by very little
information can we read from DUT. I want to know how can I uncoupling install system and execute test ,user can choose only install os 、only execute test 、install os and execute
test 、install os ones and repeat execute test ...
problem 3:
According to your experience, optimally how many DUT can mount under a lava worker and what is a constrain bottleneck?
Best
coston
Hi All,
I am having a bit of problem running the lava_scheduler_app unit tests as per the instructions at https://validation.linaro.org/static/docs/v2/dispatcher-testing.html. I keep getting errors such as the following:
$ sudo ./ci-run lava_scheduler_app.tests.test_device.TestTemplates.test_x86_template
+ set -e
+ getopts :pdty opt
+ shift 0
+ pep8 --ignore E501,E722 .
+ '[' -n '' ']'
+ echo 'Removing old .pyc files and cache'
Removing old .pyc files and cache
+ echo
+ find . -name '*.pyc' -delete
+ rm -rf ./.cache/
+ rm -rf ./__init__.py
+ echo 'Starting unit tests'
Starting unit tests
+ echo
+ '[' -z '' -a -z '' -a -z '' ']'
+ echo 'If it exists, a broken test database will be deleted without prompting.'
If it exists, a broken test database will be deleted without prompting.
+ python3 ./lava_server/manage.py test --noinput -v 2 lava_scheduler_app linaro_django_xmlrpc.tests lava_results_app
Traceback (most recent call last):
File "./lava_server/manage.py", line 78, in <module>
main()
File "./lava_server/manage.py", line 74, in main
execute_from_command_line(django_options)
File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 364, in execute_from_command_line
utility.execute()
File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 356, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/lib/python3/dist-packages/django/core/management/commands/test.py", line 29, in run_from_argv
super(Command, self).run_from_argv(argv)
File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 283, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 330, in execute
output = self.handle(*args, **options)
File "/usr/lib/python3/dist-packages/django/core/management/commands/test.py", line 62, in handle
failures = test_runner.run_tests(test_labels)
File "/usr/lib/python3/dist-packages/django/test/runner.py", line 600, in run_tests
suite = self.build_suite(test_labels, extra_tests)
File "/usr/lib/python3/dist-packages/django/test/runner.py", line 526, in build_suite
suite = reorder_suite(suite, self.reorder_by, self.reverse)
File "/usr/lib/python3/dist-packages/django/test/runner.py", line 640, in reorder_suite
partition_suite_by_type(suite, classes, bins, reverse=reverse)
File "/usr/lib/python3/dist-packages/django/test/runner.py", line 663, in partition_suite_by_type
partition_suite_by_type(test, classes, bins, reverse=reverse)
File "/usr/lib/python3/dist-packages/django/test/runner.py", line 663, in partition_suite_by_type
partition_suite_by_type(test, classes, bins, reverse=reverse)
File "/usr/lib/python3/dist-packages/django/test/runner.py", line 667, in partition_suite_by_type
bins[i].add(test)
File "/usr/lib/python3/dist-packages/django/utils/datastructures.py", line 17, in add
self.dict[item] = None
TypeError: unhashable type: 'TestSchedulerAPI'
I have backed out all my changes and I still get the TypeErrors. I tried the latest in the master branch, and also the 2018.5 release tag. Could someone please let me know what I am doing incorrectly? Thanks!
Cheers,
Edmund
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
Hello Folks,
Long time no see. Seems that I am back (for limited time) to Lava testing,
and after all the setups and catches 22, I managed to get to the bottom of
it, within few days.
I have interesting problem to report.
vagrant@stretch:/etc/lava-server/dispatcher-config/device-types$ dpkg -l
lava-server lava-dispatcher
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
Architecture Description
+++-==========================================-==========================-==========================-==========================================================================================
ii lava-dispatcher 2018.5-3~bpo9+1
amd64 Linaro Automated Validation Architecture
dispatcher
ii lava-server 2018.5-3~bpo9+1
all Linaro Automated Validation Architecture server
## Issue Background
Issue CIP testing #16 seems to be very similar: Beaglebone Black
health-check job is failing at restart
## Issue description
Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid
## Acceptance criteria
The tftp 0x88080000 22/tftp-deploy-on2jld77/ramdisk/ramdisk.cpio.gz.uboot
Using cpsw devtftp 0x88080000
22/tftp-deploy-on2jld77/ramdisk/ramdisk.cpio.gz.uboot
The initramdisk is built by the following instructions:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipsystembuild…
I used both BusyBox 28.0 and latest stable BusyBox 28.4 (failure seems to
be the same)!
Should download seamlessly, but it does not. It reports that the image is
corrupt. The full log is at:
local test of ramdisk test on bbb - Lava job 22
https://pastebin.com/y9n4GM5G
The .yaml file is at:
[lava 2018.5-3] job_name: local test of ramdisk test on bbb
https://pastebin.com/kqS2dqWM
_______
Namely, the download order is somehow scrambled!
Thank you,
Zoran Stojsavljevic
Hello
Since our upgrade to 2018.4 we experience lots of lava-logs crash with the
following trace in lava-logs.log
2018-06-20 13:43:08,964 INFO Saving 1 test cases
2018-06-20 13:43:16,614 DEBUG PING => master
2018-06-20 13:43:16,618 DEBUG master => PONG(20)
2018-06-20 13:43:19,524 INFO Saving 21 test cases
2018-06-20 13:43:29,535 INFO Saving 62 test cases
2018-06-20 13:43:37,983 DEBUG PING => master
2018-06-20 13:43:37,985 DEBUG master => PONG(20)
2018-06-20 13:43:39,541 INFO Saving 3 test cases
2018-06-20 13:43:58,009 DEBUG PING => master
2018-06-20 13:43:58,010 DEBUG master => PONG(20)
2018-06-20 13:44:01,770 INFO Saving 9 test cases
2018-06-20 13:44:01,771 ERROR [EXIT] Unknown exception raised, leaving!
2018-06-20 13:44:01,771 ERROR 'bool' object has no attribute 'pk'
Traceback (most recent call last):
File
"/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py",
line 181, in handle
self.main_loop()
File
"/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py",
line 232, in main_loop
self.flush_test_cases()
File
"/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py",
line 217, in flush_test_cases
TestCase.objects.bulk_create(self.test_cases)
File "/usr/lib/python3/dist-packages/django/db/models/manager.py", line
85, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
File "/usr/lib/python3/dist-packages/django/db/models/query.py", line
441, in bulk_create
self._populate_pk_values(objs)
File "/usr/lib/python3/dist-packages/django/db/models/query.py", line
404, in _populate_pk_values
if obj.pk is None:
AttributeError: 'bool' object has no attribute 'pk'
2018-06-20 13:44:02,109 INFO [EXIT] Disconnect logging socket and
process messages
2018-06-20 13:44:02,109 DEBUG [EXIT] unbinding from 'tcp://0.0.0.0:5555'
2018-06-20 13:44:02,185 INFO Saving 9 test cases
2018-06-20 13:44:02,186 ERROR [EXIT] Unknown exception raised, leaving!
2018-06-20 13:44:02,186 ERROR 'bool' object has no attribute 'pk'
Traceback (most recent call last):
File
"/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py",
line 201, in handle
self.flush_test_cases()
File
"/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py",
line 217, in flush_test_cases
TestCase.objects.bulk_create(self.test_cases)
File "/usr/lib/python3/dist-packages/django/db/models/manager.py", line
85, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
File "/usr/lib/python3/dist-packages/django/db/models/query.py", line
441, in bulk_create
self._populate_pk_values(objs)
File "/usr/lib/python3/dist-packages/django/db/models/query.py", line
404, in _populate_pk_values
if obj.pk is None:
AttributeError: 'bool' object has no attribute 'pk'
2018-06-20 13:44:02,186 INFO Saving 9 test cases
Any idea on how to fix this ?
Thanks
Regards
Hello everyone,
I have two cases in which I need to reboot my device during tests:
1. Reboot is active part of the test (e.g. store some persistent settings, reboot, check if persistent settings are correctly loaded after reboot)
2. Reboot is triggered and has to be evaluated (e.g. activate watchdog, stop resetting it, wait, check if system reboots automatically)
How can I hadle these two cases in LAVA?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com<http://www.garz-fricke.com/>
SOLUTIONS THAT COMPLETE!
[cid:image001.jpg@01D407D7.E4232AA0]
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz
Dear users,
the corresponding CVEs has been assigned:
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12563
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12564
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12565
Regards
2018-06-15 23:29 GMT+02:00 Neil Williams <neil.williams(a)linaro.org>:
> 2018.5.post1
> ============
>
> During routine development, a new security scanning tool (bandit) was used
> on the LAVA codebase. Three security problems were found relating to the
> Job Submit UI and the loading of YAML files through XMLRPC. The problems
> date back to 2013, possibly earlier, so all releases of LAVA are affected.
>
> Fixes were developed and have now been released.
>
> https://review.linaro.org/#/c/25917/ Remove the ability to paste
> URLs in the submit page
>
> https://review.linaro.org/25918 Use requests instead of urlopen
>
> https://review.linaro.org/25919 Use yaml.safe_load when parsing
> user data
>
> Thanks to Remi Duraffort for identifying and fixing the issues.
>
> Note: These changes are not trivial to backport to previous releases. It
> is possible but some familiarity with the codebase will be required. We
> have packed a lot of changes into the time since the end of the migration
> and we are hoping to have a more stable time ahead. The LAVA software team
> recommend that all instances look to upgrade to 2018.5.post1. Our apologies
> for these problems.
>
> We are NOT aware of any exploits using these issues but now that the
> problems are public, it is prudent to apply the available fixes before
> anything happens.
>
> We expect to make more use of bandit and similar tools in future.
>
> CVE's have been requested but we don't have the CVE numbers back at this
> time.
>
> The production repo now carries these changes as 2018.5.post1-1+stretch
>
> An upload to Debian unstable will follow in due course. (The Debian
> security team were notified once we had a fix.) An upload to Debian
> Stretch to update 2016.12-1 is being prepared.
>
> --
>
> Neil Williams
> =============
> neil.williams(a)linaro.org
> http://www.linux.codehelp.co.uk/
>
> _______________________________________________
> Lava-announce mailing list
> Lava-announce(a)lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lava-announce
>
>
--
Rémi Duraffort
LAVA Team
Hi,
To match the result lines in the following log from zephyr sanity test:
— output —
***** Booting Zephyr OS v1.11.0-1194-g4b0b65c1b *****
Running test suite poll_api
===================================================================
starting test - test_poll_no_wait
PASS - test_poll_no_wait
===================================================================
starting test - test_poll_wait
PASS - test_poll_wait
===================================================================
starting test - test_poll_multi
PASS - test_poll_multi
===================================================================
===================================================================
— output ends —
I started with this pattern: '(?P<result>(PASS|FAIL))\s-\s(?P<test_case_id>\w+)', but the test_case_ids it matched are incomplete, shown as below. Refer to https://validation.linaro.org/scheduler/job/1807112
test_po
test_poll_
test_poll_mu
I also tried the following patterns, but no lucky.
'(?P<result>(PASS|FAIL))\s-\s(?P<test_case_id>\w+)$’ matched sth similar as above, but the not the same. Refer to https://validation.linaro.org/scheduler/job/1807117
'(?P<result>(PASS|FAIL))\s-\s(?P<test_case_id>\w+)\n’ didn’t match anything.
A search online hit https://stackoverflow.com/questions/14689531/how-to-match-a-new-line-charac… . Then I tried manually in python shell. '(?P<result>(PASS|FAIL))\s-\s(?P<test_case_id>\w+)’ works, '(?P<result>(PASS|FAIL))\s-\s(?P<test_case_id>\w+)$’ works only when re.M enabled.
— debug —
>>> s
"\nTrying ::1...\nConnected to localhost.\nEscape character is '^]'.\nFRDM-KW41Z-01 7113 [115200 N81]\n***** Booting Zephyr OS v1.11.0-1194-g4b0b65c1b *****\nRunning test suite poll_api\n===================================================================\nstarting test - test_poll_no_wait\nPASS - test_poll_no_wait\n===================================================================\nstarting test - test_poll_wait\nPASS - test_poll_wait\n===================================================================\nstarting test - test_poll_multi\nPASS - test_poll_multi\n===================================================================\n===================================================================\n"
>>> p.search(s).group()
'PASS - test_poll_no_wait'
>>> p = re.compile(r'(?P<result>(PASS|FAIL))\s-\s(?P<test_case_id>\w+)$')
>>> p.search(s).group()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'NoneType' object has no attribute 'group'
>>> p = re.compile(r'(?P<result>(PASS|FAIL))\s-\s(?P<test_case_id>\w+)$', re.M)
>>> p.search(s).group()
'PASS - test_poll_no_wait’
— ends —
Could you please advise me how to handle the parsing with the monitor action?
Thanks,
Chase
Good morning everyone,
I would like to know if the default password for lavaserver database
created in Postgresql is available somewhere in the default configuration
files?
Also, Is there a way to find out the default password for lavaserver user
in the host?
regards,
Hi all,
For the boards I am using in my LAVA lab, if I try an NFS job on my
jetson-tk1, it fails to mount the filesystem from the debian installed
NFS server.
http://lava.streamtester.net/scheduler/job/120050
my nfs-kernel-server version is 1:1.3.4-2.1, which was installed with
LAVA from Debian Stretch.
If I add 'vers=3' to the kernel NFS command line, it mounts the
filesystem successfully.
http://lava.streamtester.net/scheduler/job/120049
This is being discussed here to make it a default option
https://review.linaro.org/#/c/25666/
But really this does seem like there's an issue with the NFS kernel
server in Debian Stretch. Has anyone else had this issue?
Matt
Hello,
After upgrading to 2018.4 (also tried .5) many of our device-types
using base-uboot.jinja2 are broken. While I really like the major
improvement to run commands individually, there seems to be some
problems and the LAVA output logs are very confusing, showing
concatenated strings, etc.
Here is an example for an upstream device-type (meson-gxbb-p200), and
here is where it starts interacting with u-boot:
http://khilman.ddns.net/scheduler/job/15#L336
The "Parsed boot commands" look perfect, and all the commands in black
all look good, but notice the commands at the u-boot prompt, they
appear to be concatenated, starting right away at the "setenv
initrd_high ..."
However, observing the commands on the actual serial port (I use
conmux, so can observe the serial console interactions directly), I'm
not seeing concatenated strings, but the "setenv serverip ..." never
shows up, so the TFTP downloads fail, and the job fails.
Here's what I see directly on the serial console:
Hit Enter or space or Ctrl+C key to stop autoboot -- : 0
gxb_p200_v1#
gxb_p200_v1#setenv autoload no
gxb_p200_v1#setenv initrd_high 0xffffffff
gxb_p200_v1#setenv fdt_high 0xffffffff
gxb_p200_v1#dhcp
dwmac.c9410000 Waiting for PHY auto negotiation to complete.. done
Speed: 100, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
DHCP client bound to address 192.168.0.216 (267 ms)
gxb_p200_v1#tftp 0x1080000 14/tftp-deploy-5v1wo7fv/kernel/uImage
Speed: 100, full duplex
Using dwmac.c9410000 device
TFTP from server 192.168.0.1; our IP address is 192.168.0.216
Filename '14/tftp-deploy-5v1wo7fv/kernel/uImage'.
Load address: 0x1080000
Loading: *
TFTP error: 'File not found' (1)
Even more interesting is that on the same setup, a beaglebone-black
device, using the same base-uboot.jinja2 is working just fine:
http://khilman.ddns.net/scheduler/job/1
Any help would be appreciated, I'm thoroughly confused by what's going on here.
Thanks,
Kevin
At some point last week - I think because of network connectivity issues
a job got stuck and I I cancelled it, it when run again it again appeared to hang. I again
cancelled it and am now seeing the health check not start (at least no
output appears on the job's webspage.
Looking at the output.yaml (in /var/lib/lava-server/default/media/job-output/2018/05/23/32 ) I see
... progress output for downloading https://images.validation.linaro.org/kvm/standard/stretch-2.img.gz
- {"dt": "2018-05-23T07:39:54.728015", "lvl": "debug", "msg": "[common] Preparing overlay tarball in /var/lib/lava/dispatcher/tmp/32/lava-overlay-aye3n2ke"}
- {"dt":
- "2018-05-23T07:39:54.728root@stretch:/var/lib/lava-server/default/media/job-output/2018/05/23/32
But none of this appears in http://localhost:8080/scheduler/job/32
and at the head of that page I see the message:
Unable to parse invalid logs: This is maybe a bug in LAVA that should be reported.
which other logs are best for checking whether this is an error that
should be fed back?
(LAVA 2018.4)
Robert
Hi Lava-Users,
I have a device 'raspberry-pi' whose boot method doesn't stop at bootloader.
I tried removing 'method' from boot-action but then it doesn't accept it as
valid test job.
Changing of method from u-boot to fastboot or to any other also gives error
as not supported boot methods for this device.
After device bring up, it gives u-boot interrupt timed-out and job gets
incomplete.
Is there any way thru which we can run tests on such devices?
--
Regards,
Nikita Gupta