Does lava has roadmap to separate resource management to some open source mechenisim, so it could share resource with other framework?
Like spark/hadoop could use mesos/yarn to share resource.
Hi Team,
While Running LAVA in localhost , facing the error while accessing the UI
related to Devices.
Here I have attached the screenshot , please find the attachment.
Please help me to solve this issue.
Thanks & Regards,
Dhanunjaya. P
Hi Team,
I was trying to run the first Job with the qemu device type , continuously
the job listing as submitted , not getting into the Running status to
observe the behaviour.
As a Initial step , How I need to run the Scheduler, what will the mac
address need to update in the device configuration file while running jobs
in the localhost.
Regards,
Dhanunjaya. P
Hi, everyone!
I'm using fastboot from lxc to flash image to device.
I have link to archive of my image.
How better operate with it?
In lxc test download archive, unzip it to lxc, and flash it ?
I've tried this option. And use lxc:/// url type. But I cant find it, can you suggest how to do it?
my job description : https://pastebin.com/LUmL6Qv3
and I see my downloads in lxc file system. I just removed other commands from job.
I understand,that it is wrong.
I found in glossary
http://59.144.98.45/static/docs/v2/glossary.html#term-lava-lxc-home
But I cant connect path from lxc-container, and lxc:///
Please, help.
Ilya
Hi Team,
i tried to add Device & Jobs to the LAVA instance for the device type
"qemu" , continuously getting the Configuration Error:missing or invalid
template(jobs requesting this device type (qemu) will not be able to start
until a template is available on the master).
Can you please let me know how to add Device Dictionary to the LAVA
instance.
Thanks in advance.
Regards,
Dhanunjaya. P
Hi, with lava2019.09 will has next issue, seems ok in 2019.01:if request is running, click something like next:http://lava_ip/results/171It will show:500 Internal Server Errorlist index out of range
Oops, something has gone wrong!
But if the request finish, the link ok again.
Hello!
I run ltp test on my device. And now ltp's output goes in one test log output.
Is it possible to separate output of ltp testcases? To show fail or pass on each test?
Ilya.
Hi,
I have a Lava job which runs VTS and CTS and Lava gives me time out because the maximum timeout I could set was 60 min.
How do I set no-Timeout for my test? Is it possible?
george
Perfect then.
Thanks
Le mer. 23 oct. 2019 à 09:42, Philippe BEGNIC <philippe.begnic(a)st.com> a
écrit :
> Hello Remi,
>
> The "start" parameters allows me to slice the windows by packets of 100
> jobs. This is OK for my usage.
>
> Thanks for your support
>
> Philippe Begnic
> On 10/22/19 5:32 PM, Remi Duraffort wrote:
>
> Hello,
>
> this is the lava server that limit the number of jobs that will be
> returned. But the api allows to iterate by setting the "start" parameter.
> See https://validation.linaro.org/api/help/#scheduler.jobs.list
>
>
> Rgds
>
> Le mar. 22 oct. 2019 à 16:17, Philippe BEGNIC <philippe.begnic(a)st.com> a
> écrit :
>
>> Hello everyone,
>>
>> I am using Lavacli to calculate basic statistics on the daily jobs
>> executed with LAVA. (Nbr of complete//incomplete//canceled jobs).
>> I also display the failure reason of the incomplete and canceled jobs by
>> parsing the jobs logs.
>> I can only do this operation for a limited number of jobs, because it
>> seems that Lavacli has a restriction on the number of jobs to be treated.
>> (100 jobs)
>>
>> Here the command lines I am using :
>> > lavacli jobs list --health INCOMPLETE --limit 200
>>
>> To count the number of computed jobs:
>> > lavacli jobs list --health INCOMPLETE --limit 200 |wc -l
>> > 101
>>
>> So, I have requested 200 jobs, and Lavacli has treated only 100 jobs (
>> Note that our jobs database contains more than 200 jobs incomplete)
>>
>> Is it possible to remove or to increase the limitation on the number of
>> jobs to be treated ?
>>
>>
>> Best regards
>>
>>
>> Philippe Begnic
>> STMicroelectronics | MDG Group – MCD Division
>>
>>
>> _______________________________________________
>> Lava-users mailing list
>> Lava-users(a)lists.lavasoftware.org
>> https://lists.lavasoftware.org/mailman/listinfo/lava-users
>
>
>
> --
> Rémi Duraffort
> LAVA Architect
> Linaro
>
>
--
Rémi Duraffort
LAVA Architect
Linaro
Hello everyone,
I have got an error in a lava job during to overlay unpacking operations.
This happen with jobs that flash the DUT before executing the tests. When the partitions are flashed on the DUT, I reboot the boards.
After kernel has started, the kernel boot prompt is detected. Then the commands to downloads the tests overlay are launched. ( wget ... )
But in my case, these commands are not immediately executed, because the DUT is beeing resizing the root filesystem to fit available disk space
on the SDCard.
This operation take time ( depending on capacity and characteristics of the SDCard), and cause overlay-unpack<https://citools.st.com/results/testcase/2039053> to fail with a timeout error,
because the command wget is not executed in the expected time ( 30 sec is the default time ).
I have tried to add a time out settings in the transfer_overlay part of my jobs, but this has no effect.
Is it possible to set specific "timeout trigger" for the "overlay-unpack" operation ?
My Lava version: 2019.01+stretch
Best regards
Philippe Begnic
STMicroelectronics
Hi, Remi,
You said:
> lava-master is receiving an invalid zmq message. I guess you are not using
encryption? Are you fuzzing it?
Sorry, I did not catch you. What does fuzzing it mean? I did not do anything special for LAVA.
Meanwhile, what does "not using encryption" mean? Is this a LAVA master configure item or something else? I did not change anything related to this.
And as I said, it could work ok for some a period, then I leave the whole environment there, no touch for anything. Then severial days later, it may encountered the issue.
BTW, even such things happen, why no a exception handing in LAVA to ignore such issue? Currently it just close the zeromq connection.
------------------------------------------------------------------
Sender:lava-users-request <lava-users-request(a)lists.lavasoftware.org>
Sent At:2019 Oct. 15 (Tue.) 00:25
Recipient:lava-users <lava-users(a)lists.lavasoftware.org>
Subject:Lava-users Digest, Vol 14, Issue 10
Send Lava-users mailing list submissions to
lava-users(a)lists.lavasoftware.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.lavasoftware.org/mailman/listinfo/lava-users
or, via email, send a message with subject or body 'help' to
lava-users-request(a)lists.lavasoftware.org
You can reach the person managing the list at
lava-users-owner(a)lists.lavasoftware.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Lava-users digest..."
Today's Topics:
1. Re: lava job without any flashing on a real device (George Nistor)
2. Re: Unexpected crash. (Remi Duraffort)
3. Re: repeat in lava not work (Diego Russo)
----------------------------------------------------------------------
Message: 1
Date: Mon, 14 Oct 2019 13:17:55 +0000
From: George Nistor <george.n(a)l4b-software.com>
To: "lava-users(a)lists.lavasoftware.org"
<lava-users(a)lists.lavasoftware.org>
Subject: Re: [Lava-users] lava job without any flashing on a real
device
Message-ID:
<VI1PR01MB38711749B69B27E8410ABB41F0900(a)VI1PR01MB3871.eurprd01.prod.exchangelabs.com>
Content-Type: text/plain; charset="utf-8"
Yes,
In my case the only way I could make lava to see the fastboot device was via
running pre-power-command, and I run a script (I customized device descriptor to run a this script as pre-power-command) which does:
1. Power Off
Wait 5s
2.Power On
Wait 30s
3. Login as root
Wait 5s
4. echo reboot bootloader. # make it go in fastboot mode
Immediately after this script runs, the udev rule is triggered and device id added (seen from Lava).
Otherwise the reboot does not work for me.
The line:
nice lxc-attach -n lxc-hikey-test-186 -- fastboot -s xxxxxxx reboot
gives timeout.
Because the device is not seen.
To make the job work without any flashing I removed the
- deploy section which does flashing entirely
For my case:
I have added to boot this section
protocols:
lava-lxc:
- action: fastboot-boot
request: pre-power-command
timeout:
minutes: 5
george
The full job I cannot post due to company policy with confidentiality on projects.
-----Original Message-----
From: Milosz Wasilewski <milosz.wasilewski(a)linaro.org>
Sent: luni, 14 octombrie 2019 15:58
To: George Nistor <george.n(a)l4b-software.com>
Subject: Re: lava job without any flashing on a real device
Could you send the question to ML? I don't know why adb is not enough.
Maybe LAVA waits for udev event?
milosz
On Mon, 14 Oct 2019 at 13:51, George Nistor <george.n(a)l4b-software.com> wrote:
>
> I have managed after all to do it with a job like this:
> My problem was to be able to run pre-power-command before boot, to make lava to see the fastboot device - trigger that python script lxc-device-add.
>
>
> -----Original Message-----
> From: Milosz Wasilewski <milosz.wasilewski(a)linaro.org>
> Sent: Monday, October 14, 2019 15:02
> To: George Nistor <george.n(a)l4b-software.com>
> Subject: Re: lava job without any flashing on a real device
>
> There was a feature called 'dummy deploy' but I can't find it any more. Did you try simply removing 'deploy' action? This should do the trick but you will need transfer_overlay in your boot section.
>
> milosz
>
> On Mon, 14 Oct 2019 at 12:33, George Nistor <george.n(a)l4b-software.com> wrote:
> >
> > Hi Milosz,
> >
> >
> >
> > I have a small question:
> >
> > Is it possible to run a lava job without any deploy – flashing sequence on a real device?
> >
> >
> >
> > I attach the job I’m working on.
> >
> >
> >
> > george
------------------------------
Message: 2
Date: Mon, 14 Oct 2019 15:34:24 +0200
From: Remi Duraffort <remi.duraffort(a)linaro.org>
To: cnspring2002 <cnspring2002(a)aliyun.com>
Cc: lava-users <lava-users(a)lists.lavasoftware.org>
Subject: Re: [Lava-users] Unexpected crash.
Message-ID:
<CANJfhHchH1UZOy=ScC5CUnPkZ55yi3QXrNPqqjk6wSJBFZbrzg(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
lava-master is receiving an invalid zmq message. I guess you are not using
encryption? Are you fuzzing it?
Le lun. 14 oct. 2019 à 11:18, cnspring2002 <cnspring2002(a)aliyun.com> a
écrit :
> Hi, Sometimes, lava master will show next error, then seems zemomq crash,
> do you know what's the potential cause?
>
> 2019-08-20 09:14:39,576 DEBUG lava-worker-1 => PING(20)
> 2019-08-20 09:14:39,578 DEBUG lava-worker-2 => PING(20)
> 2019-08-20 09:14:39,580 DEBUG lava-worker-3 => PING(20)
> 2019-08-20 09:14:44,467 ERROR [CLOSE] Unknown exception raised, leaving!
>
> 2019-08-20 09:14:44,467 ERROR 'utf-8' codec can't decode byte 0xc0 in position 10: invalid start byte
> Traceback (most recent call last):
>
> File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-master.py", line 687, in handle
> self.main_loop(options)
>
> File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-master.py", line 731, in main_loop
> while self.controler_socket(): # Unqueue all pending messages
>
> File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-master.py", line 234, in controler_socket
> hostname = u(msg[0])
>
> File "/usr/lib/python3/dist-packages/zmq/utils/strtypes.py", line 34, in cast_unicode
> return s.decode(encoding, errors)
>
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc0 in position 10: invalid start byte
>
> 2019-08-20 09:14:44,467 INFO [CLOSE] Closing the controler socket and dropping messages
> _______________________________________________
> Lava-users mailing list
> Lava-users(a)lists.lavasoftware.org
> https://lists.lavasoftware.org/mailman/listinfo/lava-users
--
Rémi Duraffort
LAVA Tech Lead
Linaro
I am still having this problem inside the lxc container with 'adb start-server' failed.
Should I define something special in the jinja2 device descriptor regarding adb or in the job to be able to use it?
george
-----Original Message-----
From: Milosz Wasilewski <milosz.wasilewski(a)linaro.org>
Sent: Wednesday, October 16, 2019 12:59
To: George Nistor <george.n(a)l4b-software.com>
Cc: lava-users(a)lists.lavasoftware.org
Subject: Re: [Lava-users] VTS does not start because of the adb
George,
I understand what the LAVA job is doing. I'm asking you to check whether there is _any_ adb server running on the host? If there is, the server you're running in a container will not be able to connect to the device.
milosz
On Wed, 16 Oct 2019 at 08:46, George Nistor <george.n(a)l4b-software.com> wrote:
>
> Hi Lava users,
>
> My adb is not running on the host but in the lxc container lava creates at runtime.
> I have tried to put also an: adb kill-server command before starting vts but I got the same error.
>
> The lava log looks like this:
> <LAVA_SIGNAL_STARTRUN 0_device-helpers 219_1.8.4.1>
> + cd /home/android-vts/tools
> + adb kill-server
> Received signal: <STARTRUN> 0_device-helpers 219_1.8.4.1 Starting test
> lava.0_device-helpers (219_1.8.4.1) Skipping test definition patterns.
> * server not running *
> + ./vts-tradefed
> Android Vendor Test Suite 9.0_R2 (eng.l4b.20190906.094644) Use
> \"help\" or \"help all\" to get more information on running commands.
> 10-16 07:30:15 E/adb: ADB server didn't ACK
> 10-16 07:30:15 E/ddms: 'adb start-server' failed -- run manually if
> necessary
> 10-16 07:30:15 E/adb: * failed to start daemon *
> 10-16 07:30:15 E/adb: error: cannot connect to daemon
> [udev_trigger-lxc-hikey-test-219-07:30:23] device /dev/bus/usb/001/008
> added
>
> george
>
>
> -----Original Message-----
> From: Milosz Wasilewski <milosz.wasilewski(a)linaro.org>
> Sent: Tuesday, October 15, 2019 17:11
> To: George Nistor <george.n(a)l4b-software.com>
> Cc: lava-users(a)lists.lavasoftware.org
> Subject: Re: [Lava-users] VTS does not start because of the adb
>
> Do you have adb server running on the host? If so, please kill it and
> try again. As with LoTR - there is only one adb server to rule them
> all :)
>
> milosz
>
> On Tue, 15 Oct 2019 at 15:01, George Nistor <george.n(a)l4b-software.com> wrote:
> >
> > Hello Lava users,
> >
> >
> >
> > Thanks to Tim Jaaks for previous problem I reported. I managed to configure default external shared folder for the lava lxc container.
> >
> >
> >
> > However,
> >
> > I try to run VTS from Lava but after displaying initial string with VTS I get an error saying adb server could not start. I have tried restart, no success. The adb seems to be installed in the container.
> >
> > Does anyone know how to solve this error?
> >
> >
> >
> > + ./vts-tradefed
> >
> > Android Vendor Test Suite 9.0_R2 (eng.l4b.20190906.094644)
> >
> > Use \"help\" or \"help all\" to get more information on running commands.
> >
> > 10-15 13:45:22 E/adb: ADB server didn't ACK
> >
> > 10-15 13:45:22 E/ddms: 'adb start-server' failed -- run manually if
> > necessary
> >
> > 10-15 13:45:22 E/adb: * failed to start daemon *
> >
> > 10-15 13:45:22 E/adb: error: cannot connect to daemon
> >
> > [udev_trigger-lxc-hikey-test-214-13:45:29] device
> > /dev/bus/usb/001/005 added
> >
> >
> >
> >
> >
> >
> >
> > The adb is put in tlcx deploy
> >
> >
> >
> > actions:
> >
> > - deploy:
> >
> > namespace: tlxc
> >
> > timeout:
> >
> > minutes: 5
> >
> > to: lxc
> >
> > packages:
> >
> > - adb
> >
> > - fastboot
> >
> > - wget
> >
> > - unzip
> >
> > - default-jre
> >
> > os: debian
> >
> >
> >
> >
> >
> > george
> >
> > _______________________________________________
> > Lava-users mailing list
> > Lava-users(a)lists.lavasoftware.org
> > https://lists.lavasoftware.org/mailman/listinfo/lava-users
> _______________________________________________
> Lava-users mailing list
> Lava-users(a)lists.lavasoftware.org
> https://lists.lavasoftware.org/mailman/listinfo/lava-users
Hi,
Today I started looking at our LAVA testing setup and discovered that
vland has been stopped for the last 7 months. Since no one complained
I assume it's either working flawlessly in production environments or
it's not needed. If there are any vland users, please reply to this
message so I know that fixing our testing setup is not a waste of
time.
milosz
Hi,
I have a board with 4 uarts connected to a lava worker via ser2net.
LAVA is giving me some strange results when I try to use two uarts (uart0 and uart2) in the same testcase.
The results are not consistent. Sometimes it works, but most of the time it gives an error:
KeyError: 'uart2'
At the end of the job, LAVA prints:
LAVABug: This is probably a bug in LAVA, please report it.error_type: Bug
error_msg: 'uart2'
case: job
result: fail
definition: lava
<http://lava-master.sw.nxp.com/results/testcase/16283386>
----
The connection parts of the device definition are:
% set connection_list = ['uart0', 'uart1', 'uart2', 'uart3'] %}
{% set connection_tags = {'uart0': ['primary', 'telnet']} %}
{% set connection_commands = {'uart0': 'telnet localhost 7001', 'uart1': 'telnet localhost 7002', 'uart2': 'telnet localhost 7003', 'uart3': 'telnet localhost 7004'} %}
The job uses two boots; one primary to boot non-POSIX to uboot, then it switches to 'uart2' to access another processor.
The job seems to work fine if I define only two uarts:
% set connection_list = ['uart0', 'uart1'] %}
{% set connection_tags = {'uart0': ['primary', 'telnet']} %}
{% set connection_commands = {'uart0': 'telnet localhost 7001', 'uart1': 'telnet localhost 7003 } %}
Thank you,
Nick
Hello Lava users,
Thanks to Tim Jaaks for previous problem I reported. I managed to configure default external shared folder for the lava lxc container.
However,
I try to run VTS from Lava but after displaying initial string with VTS I get an error saying adb server could not start. I have tried restart, no success. The adb seems to be installed in the container.
Does anyone know how to solve this error?
+ ./vts-tradefed
Android Vendor Test Suite 9.0_R2 (eng.l4b.20190906.094644)
Use \"help\" or \"help all\" to get more information on running commands.
10-15 13:45:22 E/adb: ADB server didn't ACK
10-15 13:45:22 E/ddms: 'adb start-server' failed -- run manually if necessary
10-15 13:45:22 E/adb: * failed to start daemon *
10-15 13:45:22 E/adb: error: cannot connect to daemon
[udev_trigger-lxc-hikey-test-214-13:45:29] device /dev/bus/usb/001/005 added
The adb is put in tlcx deploy
actions:
- deploy:
namespace: tlxc
timeout:
minutes: 5
to: lxc
packages:
- adb
- fastboot
- wget
- unzip
- default-jre
os: debian
george
actions:
- repeat:
count: 2
I just add above in job, and web submit validator told me:
Job submission error: extra keys not allowed @ data['actions'][1]['repeat']
Does it still work now?
Hello Lava users,
Thanks to Tim Jaaks for previous problem I reported. I managed to configure default external shared folder for the lava lxc container.
However,
I try to run VTS from Lava but after displaying initial string with VTS I get an error saying adb server could not start. I have tried restart, no success. The adb seems to be installed in the container.
Does anyone know how to solve this error?
+ ./vts-tradefed
Android Vendor Test Suite 9.0_R2 (eng.l4b.20190906.094644)
Use \"help\" or \"help all\" to get more information on running commands.
10-15 13:45:22 E/adb: ADB server didn't ACK
10-15 13:45:22 E/ddms: 'adb start-server' failed -- run manually if necessary
10-15 13:45:22 E/adb: * failed to start daemon *
10-15 13:45:22 E/adb: error: cannot connect to daemon
[udev_trigger-lxc-hikey-test-214-13:45:29] device /dev/bus/usb/001/005 added
The adb is put in tlcx deploy
actions:
- deploy:
namespace: tlxc
timeout:
minutes: 5
to: lxc
packages:
- adb
- fastboot
- wget
- unzip
- default-jre
os: debian
george
Hi Lava users,
For my test, instead of downloading android-vts.zip archive from git I decided it will be used from a location on a machine which hosts Lava.
The question is:
Is it possible to make like a shared folder for the lxc container lava has created? Or is any other way to access directly from the lxc container a folder on the host machine?
If so, how should be done?
george
Yes,
In my case the only way I could make lava to see the fastboot device was via
running pre-power-command, and I run a script (I customized device descriptor to run a this script as pre-power-command) which does:
1. Power Off
Wait 5s
2.Power On
Wait 30s
3. Login as root
Wait 5s
4. echo reboot bootloader. # make it go in fastboot mode
Immediately after this script runs, the udev rule is triggered and device id added (seen from Lava).
Otherwise the reboot does not work for me.
The line:
nice lxc-attach -n lxc-hikey-test-186 -- fastboot -s xxxxxxx reboot
gives timeout.
Because the device is not seen.
To make the job work without any flashing I removed the
- deploy section which does flashing entirely
For my case:
I have added to boot this section
protocols:
lava-lxc:
- action: fastboot-boot
request: pre-power-command
timeout:
minutes: 5
george
The full job I cannot post due to company policy with confidentiality on projects.
-----Original Message-----
From: Milosz Wasilewski <milosz.wasilewski(a)linaro.org>
Sent: luni, 14 octombrie 2019 15:58
To: George Nistor <george.n(a)l4b-software.com>
Subject: Re: lava job without any flashing on a real device
Could you send the question to ML? I don't know why adb is not enough.
Maybe LAVA waits for udev event?
milosz
On Mon, 14 Oct 2019 at 13:51, George Nistor <george.n(a)l4b-software.com> wrote:
>
> I have managed after all to do it with a job like this:
> My problem was to be able to run pre-power-command before boot, to make lava to see the fastboot device - trigger that python script lxc-device-add.
>
>
> -----Original Message-----
> From: Milosz Wasilewski <milosz.wasilewski(a)linaro.org>
> Sent: Monday, October 14, 2019 15:02
> To: George Nistor <george.n(a)l4b-software.com>
> Subject: Re: lava job without any flashing on a real device
>
> There was a feature called 'dummy deploy' but I can't find it any more. Did you try simply removing 'deploy' action? This should do the trick but you will need transfer_overlay in your boot section.
>
> milosz
>
> On Mon, 14 Oct 2019 at 12:33, George Nistor <george.n(a)l4b-software.com> wrote:
> >
> > Hi Milosz,
> >
> >
> >
> > I have a small question:
> >
> > Is it possible to run a lava job without any deploy – flashing sequence on a real device?
> >
> >
> >
> > I attach the job I’m working on.
> >
> >
> >
> > george
Hello,
I have a job with the following flow:
1) deploy the DUT
2) boot the DUT
3) while booting, I need to capture a string: it is the version/timestamp of BL2. For example:
NOTICE: BL2: v2.1(release):v2.1-232-g89a4d26-dirty
NOTICE: BL2: Built : 04:06:44, Sep 25 2019
4) perform an update of the BL2
5) reboot the device
6) while booting the second time, I need to capture again the version/timestamp
7) Compare the 2 strings: if they are different, the test passes.
How can I do 3) 6) and 7) with LAVA?
Thanks
--
Diego Russo | Staff Software Engineer | Mbed Linux OS
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - https://os.mbed.com/linux-os/
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 a Lava job, with the following section:
- boot:
namespace: target
prompts:
- 'root@xxxxx:~#'
auto_login:
login_prompt: 'xxxxx login:'
username: root
timeout:
minutes: 5
method: fastboot
and Lava does not complete with 'root' to do autologin. After 5 mins it give me timeout autologin.
Even if I run the job and waited till the login prompt comes as output in Lava and do a echo 'root' > /dev/ttyUSB2 still Lava detects timeout autologin. (even if the devices successfully logs in - I have sent the string 'root' 2 times from the terminal).
[ 25.440854] audit: type=1325 audit(1564586870.989:25): table=filter family=2 entries=8
BMW xxxxx 19w32.5-1-2 mgu22 ttyMSM0
mgu22 login: root
7[r[999;999H[6nroot@xxxxx:~# root
-sh: root: not found
root@mgu22:~# [ 79.848385] firmware cdsp.mdt: _request_firmware_load: firmware state wait timeout: rc = -110
[ 79.857777] subsys-pil-tz 8300000.qcom,turing: cdsp: Failed to locate cdsp.mdt(rc:-11)
auto-login-action timed out after 231 seconds
The complete lava job is here.
https://pastebin.com/MeV1AyeR
Where is the mistake I do?
george
Hi All,
I am installing an ODROID-N2 board into our LAVA setup. I see that there is support for ODROID-X2 and ODROID-XU3 in the LAVA codebase, but no mention of ODROID-N2.
Before I start, I wanted to know if anyone has successfully installed an ODROID-N2 in LAVA? Does it work with the existing support added for the other variants? Are there any specific bits of hardware I will need to use and/or device dictionary settings I need to ensure are set before I can get the board up and running?
Regards,
Malcolm
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.
Hi,
We've recently had an issue with our LAVA instance (version 2019.05.post1),
where a long running LAVA job which had a large log file led to
instabilities when serving web content.
The large job was seemingly causing lava-server-gunicorn workers to use up
more memory than was available, leading to workers crashing and then
restarting. This led to all the workers processing the large jobs most of
the time, while other requests would only be served once the workers
restarted. This led to the webpages being served extremely slowly and
lavacli usage timing out (if a larger timeout was not set).
We had "LOG_SIZE_LIMIT": 3 set in our /etc/lava-server/settings.conf, and
we did have the message on that job page for "*This log file is too large
to view"*, but it seems that some requests were still attempting to process
some aspect of the job causing these worker crashes. Is there any other
settings that might need to be set in order to cope with long running jobs
with large log files that might help with this situation?
Before we look into this any further, does anyone know if this is fixed
with a newer version of LAVA? Has anyone had any similar issues with their
instances?
Thanks,
Dean
Hi Lava users,
I have a problem with the lxc container which is created on the host machine, by getting an IP address.
Lava is installed in a, VM with Debian stretch.
Has anyone experienced this problem before? Or anyone any idee why lxc does not get the ip?
Here are the logs:
lava-dispatcher, installed at version: 2019.09+stretch
start: 0 validate
Start time: 2019-09-24 12:29:39.318789+00:00 (UTC)
lxc, installed at version: 1:2.0.7-2+deb9u2
Validating that file:///usr/mgu22/mgu22-19w32.5-1-2-bmw-image-mgu22-sa8155.rootfs.ext4 exists
validate duration: 0.07
definition: lava
result: pass
case: validate
start: 1 lxc-deploy (timeout 00:05:00) [tlxc]
start: 1.1 lxc-create-action (timeout 00:05:00) [tlxc]
nice lxc-create -q -t debian -n lxc-hikey-test-13 -- --release stretch --mirror http://mirror.bytemark.co.uk/debian --packages systemd,systemd-sysv
Container created successfully
end: 1.1 lxc-create-action (duration 00:01:22) [tlxc]
level: 1.1
case: lxc-create-action
definition: lava
result: pass
namespace: tlxc
duration: 82.21
extra: ...
start: 1.2 lxc-create-udev-rule-action (timeout 00:03:38) [tlxc]
device info file '/var/lib/lava/dispatcher/tmp/13/lxc-create-udev-rule-action-y0_d19aq/device-info.yaml' created with:
[{'board_id': '7d4452a4'}]
udev rules file '/var/lib/lava/dispatcher/tmp/13/lxc-create-udev-rule-action-nj_8pzv0/100-lava-lxc-hikey-test-13.rules' created
ACTION=="add", ATTR{serial}=="7d4452a4", RUN+="/usr/share/lava-dispatcher/lava_lxc_device_add.py --lxc-name lxc-hikey-test-13 --device-node $name --job-id 13 --logging-url tcp://localhost:5555"
'/etc/udev/rules.d/100-lava-lxc-hikey-test-13.rules' symlinked to '/var/lib/lava/dispatcher/tmp/13/lxc-create-udev-rule-action-nj_8pzv0/100-lava-lxc-hikey-test-13.rules'
nice udevadm control --reload-rules
udev rules reloaded.
end: 1.2 lxc-create-udev-rule-action (duration 00:00:00) [tlxc]
start: 1.3 boot-lxc (timeout 00:03:38) [tlxc]
nice lxc-start -n lxc-hikey-test-13 -d
output:
Wait until 'lxc-hikey-test-13' state becomes RUNNING
nice lxc-info -sH -n lxc-hikey-test-13
output: RUNNING
output:
'lxc-hikey-test-13' state is RUNNING
Wait until 'lxc-hikey-test-13' gets an IP address
nice lxc-info -iH -n lxc-hikey-test-13
output:
nice lxc-info -iH -n lxc-hikey-test-13
output:
nice lxc-info -iH -n lxc-hikey-test-13
output:
nice lxc-info -iH -n lxc-hikey-test-13
output:
nice lxc-info -iH -n lxc-hikey-test-13
output:
nice lxc-info -iH -n lxc-hikey-test-13
output:
Here is my Lava job:
https://pastebin.com/kiLbnjAX
Hi All,
i am new LAVA framework
i am trying to submit my first job , but error like "Invalid definition:
extra keys not allowed @ data['job_timeout']"
i am attaching screen shot & file.
Can someone please help me to solve this issue
Thanks
Veera
Hello everyone,
I am trying to send some information containing whitespaces via lava-send. Obviously this is not supported. Is this a bug or by design?
I tried the following command:
lava-send my-message my-variable="some string with whitespaces"
Which produces the following output:
<LAVA_SEND_DEBUG lava_multi_node_send preparing Tue Aug 27 15:02:41 CEST 2019>
<LAVA_SEND_DEBUG _lava_multi_node_send started Tue Aug 27 15:02:41 CEST 2019>
<LAVA_MULTI_NODE> <LAVA_SEND my-message my-variable=some>
<LAVA_SEND_DEBUG _lava_multi_node_send finished Tue Aug 27 15:02:41 CEST 2019>
<LAVA_SEND_DEBUG lava_multi_node_send finished Tue Aug 27 15:02:41 CEST 2019>
Received Multi_Node API <LAVA_SEND>
messageID: SEND-my-message
lava-multinode lava-send
1 key value pair(s) to be sent.
Handling signal <LAVA_SEND {"timeout": 360, "request": "lava_send", "messageID": "my-message", "message": {"my-variable": "some"}}>
So obviously the string is truncated on the first whitespace.
Is there any possibility to send a string containing whitespaces to another node?
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
WE MAKE IT YOURS!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
#
root@device:~# #
lava-test-shell: Wait for prompt ['root@device:~#'] (timeout 00:05:00)
#
Using /lava-133
export SHELL=/bin/bash
root@device:~# export SHELL=/bin/bash
export SHELL=/bin/bash
. /lava-133/environment
root@device:~# . /lava-133/environment
. /lava-133/environment
-sh: .: can't open '/lava-133/environment'
Will listen to feedbacks from 'tlxc' for 1 second
/lava-133/bin/lava-test-runner /lava-133/0
root@device:~# /lava-133/bin/lava-test-runner /lava-133/0
Test shell timeout: 10s (minimum of the action and connection timeout)
/lava-133/bin/lava-test-runner /lava-133/0
-sh: /lava-133/bin/lava-test-runner: not found
Device is successfully booted and logged in. But I cant run any commands.
Why lava running this command? :
. /lava-133/environment
And how it downloads to device.
Ilya
Hi!
Lava as default at beginning runs that command:
nice fastboot -s 261a1c5d reboot-bootloader
Is it possible to avoid this step? Dont run this command
Ilya
Hi Milosz,
Please take a look at the first message of this thread. There are 2
different information for this error.
First, this COMMA error happens when I'm trying to access the URL (LAVA
WebU), manually inserting the job_id in a browser, and not through the code.
Second, the previous code is returning:
lavac.server.NoSuchJob: No such job: 68271.0
Even though this job_id is been returned by the LAVA server.
Thanks
Em seg, 2 de set de 2019 às 11:32, Milosz Wasilewski <
milosz.wasilewski(a)linaro.org> escreveu:
> On Mon, 2 Sep 2019 at 10:26, Fabiano Ferronato <fabiferro(a)hotmail.com>
> wrote:
> >
> > Hi Milosz,
> >
> > I still couldn't update the server but, just to clarify, the mentioned
> job pasted in URL is 68271.0 as we can see in the error message:
> >
> > URL : http://lava.server.net/scheduler/job/68271.0
> >
> > > Trying to access LAVA WebUI using the jobid (68271.0)
> >
> > And then some process is translating that jobid into a comma " , " :
> >
> > > Reverse for 'lava.scheduler.job.detail' with arguments '('',)' not
> found. 1 pattern(s) tried: ['scheduler/job/(?P<pk>[0-9]+|[0-9]+\\.[0-9]+)$']
> >
> > Otherwise, a really not existent jobid in the URL, let's say 99999.9,
> results in "404 Not found".
> >
> > Here is the job submission code:
> >
> > try:
> > job_id = self._server.scheduler.submit_job(job_data)
> > if not isinstance(job_id, list):
> > job_id = [job_id]
> > return job_id
> >
> > And than the job_id is used to get job details:
> >
> > try:
> > return self._server.scheduler.job_details(job_id)
>
> scheduled.job_details expects a string:
> https://master.lavasoftware.org/api/help/#scheduler.job_details
>
> If I understand your code correctly you're passing a list to this
> function. Serialized list will contain "," character.
>
> milosz
>
> >
> > Best Regards,
> > Fabiano
> >
> > Em sex, 23 de ago de 2019 às 16:25, Milosz Wasilewski <
> milosz.wasilewski(a)linaro.org> escreveu:
> >>
> >> I don't think there was a problem with 2018.10 with this feature.
> >> Reading the error message I think you pasted "," character in the URL
> >> so the pattern didn't match. As you can see in the regex, "." is there
> >> and I don't recall any issues with multinode jobs then. Anyway, even
> >> if this is a bug it won't be fixed in 2018.10. When you migrate to
> >> latest version and you hit the same problem something can be done.
> >>
> >> If you can post full script you're using I can try on latest master
> >> and see what happens.
> >>
> >> milosz
> >>
> >> On Fri, 23 Aug 2019 at 13:10, Fabiano Ferronato <fabiferro(a)hotmail.com>
> wrote:
> >> >
> >> > Hi Milosz, thanks for your answer.
> >> >
> >> > Yes, it is a multinode job.
> >> > This is a known bug on version 2018.10? I need to install the new
> version and keep pipe lines running until I get the error to answer you.
> >> >
> >> > Fabiano
> >> >
> >> > Em qui, 22 de ago de 2019 às 18:58, Milosz Wasilewski <
> milosz.wasilewski(a)linaro.org> escreveu:
> >> >>
> >> >> On Thu, 22 Aug 2019 at 17:30, Fabiano Ferronato <
> fabiferro(a)hotmail.com> wrote:
> >> >> >
> >> >> > Hi,
> >> >> > we have a LAVA test setup working for some time. Automated
> pipelines are running tests on different devices in parallel.
> >> >> > After updating to version 2018.10+stretch and changing to in-line
> job definitions we started to get some sporadic errors.
> >> >> >
> >> >> > The error message shows up after jobs are submitted and the return
> from the submission is then used to ask for server job details:
> >> >> >
> >> >> > res = lava_server.submit_job(lava_test_job_description)
> >> >> > for entry in res:
> >> >> > job_details = lavasrv.job_details(entry)
> >> >> > ...
> >> >> >
> >> >> > Resulting in the following error:
> >> >> >
> >> >> > lib/python3.5/site-packages/lavac/server.py", line 272, in
> job_details
> >> >> > raise get_server_error(error, job_id)
> >> >> > lavac.server.NoSuchJob: No such job: 68271.0
> >> >>
> >> >> are you submitting a multinode job? Does this also happen in more
> >> >> recent version of LAVA (like 2019.07)?
> >> >>
> >> >> milosz
> >> >>
> >> >> >
> >> >> >
> >> >> > Trying to access LAVA WebUI using the jobid (68271.0):
> >> >> >
> >> >> > 500 Internal Server Error
> >> >> > Reverse for 'lava.scheduler.job.detail' with arguments '('',)' not
> found. 1 pattern(s) tried: ['scheduler/job/(?P<pk>[0-9]+|[0-9]+\\.[0-9]+)$']
> >> >> >
> >> >> > Can you give me a hint about this error?
> >> >> >
> >> >> > Thanks!
> >> >> >
> >> >> > _______________________________________________
> >> >> > Lava-users mailing list
> >> >> > Lava-users(a)lists.lavasoftware.org
> >> >> > https://lists.lavasoftware.org/mailman/listinfo/lava-users
> >> >
> >> > _______________________________________________
> >> > Lava-users mailing list
> >> > Lava-users(a)lists.lavasoftware.org
> >> > https://lists.lavasoftware.org/mailman/listinfo/lava-users
>
Hi!
I'm using lava from debian stretch.
I try flash image by fastboot.
At that step job just stuck and util timeout of 10 minutes.
nice fastboot -s '261a1c5d' flash persist /var/lib/lava/dispatcher/tmp/15/fastboot-deploy-7xj200yq/persist/persist.ext4
If run command from terminal
fastboot -s 261a1c5d flash persist /tmp/persist.ext4
device is flashed in 3 seconds
It looks like, that LAVA doesnt see my device.
Job desc : https://pastebin.com/ZNeS71Ev
Device desc: https://pastebin.com/rYRyEnjy
Job log : https://pastebin.com/fH0u3bUb
I know, that for fastboot better to work with lxc. I also tried with lxc. And it stuck on the same place.
Job log with lxc : https://pastebin.com/RnZLNfvN
Ilya
Hello,
I have a question regarding running a test that I have on my host machine inside a Lava job.
Basically, I start Lava and try to submit a job through: Scheduler/Submit
The job description looks like this:
device_type: qemu
job_name: qemu amd64 LTP
timeouts:
job:
minutes: 120
action:
minutes: 120
connection:
minutes: 120
priority: medium
visibility: public
metadata:
source: https://ci.linaro.org/view/lava-ci/job/lava-debian-stable-amd64-vm/
path: https://git.linaro.org/ci/job/configs.git/blob/HEAD:/lava-debian-stable-amd…
build-readme: https://images.validation.linaro.org/snapshots.linaro.org/components/lava/s…
build-console: https://ci.linaro.org/view/lava-ci/job/lava-debian-stable-amd64-vm/console
build-log: http://images.validation.linaro.org/snapshots.linaro.org/components/lava/st…
# CONTEXT_BLOCK
context:
arch: amd64
# ACTIONS_BLOCK
actions:
- deploy:
timeout:
minutes: 120
to: tmpfs
images:
rootfs:
image_arg: -drive format=raw,file={rootfs}
url: https://images.validation.linaro.org/snapshots.linaro.org/components/lava/s…
sha256sum: 4ab50cc69fc61faa9bf48edada8bc1a317247f77ced5a815f40e75cef1d62cc7
compression: gz
# BOOT_BLOCK
- boot:
method: qemu
media: tmpfs
timeout:
minutes: 120
prompts:
- "root@debian:"
auto_login:
login_prompt: "login:"
username: root
- test:
timeout:
minutes: 120
definitions:
- repository:
metadata:
format: Lava-Test Test Definition 1.0
name: apache-server
description: "server installation"
os:
- debian
scope:
- functional
run:
steps:
Here I would like to have my test.Something like:
- make
- ./home/user/folder/mytest
from: inline
name: apache-server
path: inline/apache-server.yaml
Can you maybe give me a short example on how to do that?
I tried using the "inline" keyword, but to no avail.
Best regards,
Emanuel-Vladut Magas
L4B Software, Iasi, Romania
E-mail: vladut.m(a)l4b-software.com
[cid:37eb12b3-1085-46f2-8e9a-e636f5edc7d8]
We've just discovered that the bulk canceling of test jobs in LAVA admin
does not work.
Issue in gitlab: https://git.lavasoftware.org/lava/lava/issues/310
We will fix this asap and roll it out with next release or hotfix,
whichever comes first.
A workaround is to either use XMLRPC API or cancel jobs one at a time.
Cheers,
--
Stevan Radaković | LAVA Engineer
Linaro.org <www.linaro.org> │ Open source software for ARM SoCs
Dear Lava users,
I'm looking for a way to measure, with Lava, time measurements between some power modes. Let's say the time between two messages :
- Standby exit trigger
- Actual standby exit from the kernel
The constraint is that we can't rely on kernel timestamps (frozen during standby) and the power process implies not only kernel but also boot stages. We can only rely on the time spent between two specific messages in the console.
Basically, if it was done without Lava, we'd use a tool like grabserial.
Do you have any clue on what can be done?
Best regards,
Hello again,
I have several test cases where we use LAVA multinode to test hardware and software interfaces externally. E.g. we have an SFTP server running on our DUT. In order to test that, we submit a test using two nodes:
1. The DUT
2. An LXC container
The LXC device connects to the DUT via SFTP and uploads a file. Both sides determine the MD5 sum and the DUT compares them.
This works as long as both the DUT and the LXC device are in the same network (or at least can reach each other via the network).
Now there are more test cases which require additional hardware connections between the worker and the DUT, e.g. a serial interface test. The serial interface on the DUT is connected via an RS232-USB converter to the worker. The LXC can access this converter and send or receive data from the serial interface.
This works as long as the LXC is running on the expected worker the serial interface of the DUT is connected to.
As we are growing our lab, we will add more workers to our setup. There will be LXC devices on all of the workers.
When submitting such a multinode job, which relies on hardware connections between the DUT and the worker, how can I make sure that the LXC part of the job is scheduled on an LXC device on the correct worker?
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
WE MAKE IT YOURS!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
Hi,
I'm looking into LAVA and I figured I'd give it a try by flashing a frdm-k64f MCU board and parse its output (the board behaves as a USB to UART adapter through /dev/ttyACM0 at 115200bps). I created the board instance as:
{% extends 'frdm-k64f.jinja2' %}
{% set board_id = '0240000048824e45004a700add89001a8761000097969900' %}
{% set usb_mass_device = '/dev/disk/by-id/usb-MBED_VFS_0240000048824e45004a700add89001a8761000097969900-0:0' %}
I'm able to launch a job (frdm-k64f.job) but LAVA complains and returns:
Invalid job data: ["Invalid device configuration - missing 'commands'"]
So I went looking for an example and found this<https://git.lavasoftware.org/fabo/lava/blob/bc44750733f57de09909f45ba7e65fa…> which defines something called connection_commands as:
{% set connection_commands = {'usb0': 'telnet lab-slave-0 7115'} %}
Based on the documentation<https://docs.lavasoftware.org/lava/connections.html> I'm under the impression that the slave/dispatcher is expected to momentarily open a telnet server on port 7115 and forward the output of the serial port through that server to be retrieved by a client implemented by the master.
If I match the example the dispatcher flashes the board, but a telnet server is never launched on the slave. It's not surprising as at no point did I specify a tty or a baud rate for the dispatcher to connect to the board in order and launch something like:
socat TCP-LISTEN:7115,fork,reuseaddr FILE:/dev/ttyACM0,b115200,raw
When I sit on the slave and manually launch the command the master successfully connects to TCP port 7115. Problem is it does so after the board outputted its results (and obviously it's not the right way to do it).
So I have 3 questions:
* How should a UART connection be specified (/dev/ttyACM0, 115200bps) to LAVA?
* Once the UART connection specified, will the dispatcher buffer the board's output until it is retrieved by the master?
* Why does LAVA rely on a telnet channel instead of the existing zmq channel to forward the output of the board from the slave to the master?
Thanks
Hello,
We have few device types in our LAVA instance that use ums mechanism to be deployed. This has worked well so far but we have now the need to test secure boot flow (BL1, BL2...) and we cannot rely anymore in u-boot for deploying them.
Assuming we have the HW in place to put the DUT in recovery mode, how can we achieve this via LAVA? Do you have an existent example where you automate the recovery mode of a board?
Thanks
--
Diego Russo | Staff Software Engineer | Mbed Linux OS
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - https://os.mbed.com/linux-os/
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 everyone,
I have the following entry in my lxc device dictionary:
{% set static_info = [
{'board_id': 'FTXTBHMA'},
] %}
This adds my USB-serial converter installed on the worker machine to the LXC. It appears correctly in the LXC:
root@lxc-generic-remote-5937:~# ls -la /dev/ttyUSB*
crw-r----- 1 root root 188, 0 Jul 30 13:15 /dev/ttyUSB0
crw-r----- 1 root root 188, 1 Jul 30 13:15 /dev/ttyUSB1
crw-r----- 1 root root 188, 2 Jul 30 13:15 /dev/ttyUSB2
crw-r----- 1 root root 188, 3 Jul 30 13:15 /dev/ttyUSB3
I cannot read from or write to it, though:
root@lxc-generic-remote-5937:~# cat /dev/ttyUSB0
cat: /dev/ttyUSB0: Operation not permitted
This does not seem to be a permission issue in the LXC, it fails even if I set all permissions:
root@lxc-generic-remote-5937:~# chmod a+rwx /dev/ttyUSB0
root@lxc-generic-remote-5937:~# cat /dev/ttyUSB0
cat: /dev/ttyUSB0: Operation not permitted
Does anybody have an idea what is missing here?
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
WE MAKE IT YOURS!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
Hello, LAVA Team!
I have question about device description.
I have problems with *pre_power_command*
If I don't use requests : pre_power_command in my job description, i get
error, that no request implementation.
So in my case, I need to switch device to fastboot mode by sending command
via serial connection. And I decided, that pre_power_command is better
solution for me. Cause before fastboot deploying by setting up this command
I will switch device's mode.
And here I stuck, cause I received error message:
no pre_power_command implementation.
Device description:
https://pastebin.com/FLhGUnyH
Job description:
https://pastebin.com/Ts6VUXZe
Error log:
https://pastebin.com/9jXvjxZb
best regards, Ilya
Hi, LAVA Team!
I'm trying to add my new device.
It must be flashed by fastboot.
To turn device into fastboot mode, I need to write "reboot bootloader" via
serial connection.
I have tried
set soft_reboot_command = ['reboot bootloader']
and received error message
lava-lxc protocol: FAILED executing 'lxc-attach -n lxc-hikey-test-4 -- adb
reboot bootloader'
Ilya
Hi,
we have a LAVA test setup working for some time. Automated pipelines are
running tests on different devices in parallel.
After updating to version 2018.10+stretch and changing to in-line job
definitions we started to get some sporadic errors.
The error message shows up after jobs are submitted and the return from the
submission is then used to ask for server job details:
res = lava_server.submit_job(lava_test_job_description)
for entry in res:
job_details = lavasrv.job_details(entry)
...
Resulting in the following error:
lib/python3.5/site-packages/lavac/server.py", line 272, in job_details
raise get_server_error(error, job_id)
lavac.server.NoSuchJob: No such job: 68271.0
Trying to access LAVA WebUI using the jobid (68271.0):
500 Internal Server Error
Reverse for 'lava.scheduler.job.detail' with arguments '('',)' not found. 1
pattern(s) tried: ['scheduler/job/(?P<pk>[0-9]+|[0-9]+\\.[0-9]+)$']
Can you give me a hint about this error?
Thanks!
Hi Milosz,
I am using the Raspberry Pi 3 B+ board as a real target. It has AOSP Pie 9 on it and runs.
I would be interested now, to see like you said if I could run CTS,VTS on the board and omit deploy section.
What should I put in the boot section as method:
Would be the same fastboot or another method? I ask because the board is connected to LAN (and not over USB).
Is it ok just to omit deploy section?
In other words how would Lava know to access the board on ADB over its IP. Where should I set this info?
Example section (Milosz CTS&VTS example):
https://pastebin.com/hBn0pq6U
Hi Lava Users,
I have decided to continue using a real device: a Raspberry Pi 3 B+.
Because I have an iso with Android 9 Pie, to flash the board I want to use
deploy:
to: iso-installer
The question I'm having is:
Is it possible to use this mode to flash the board with ADB via Wifi?
(The board, I connected wifi to our router and I am able to connect with adb using wifi)
(The board does not have USB/OTG interface so the only option is to use ADB on wifi.)
What I try to achieve is deploy the image I have - iso one (flash), with adb using wifi, and run as tests CTS and VTS.
george
-----Original Message-----
From: Milosz Wasilewski <milosz.wasilewski(a)linaro.org>
Sent: Wednesday, August 21, 2019 11:27 AM
To: George Nistor <george.n(a)l4b-software.com>
Cc: lava-users(a)lists.lavasoftware.org
Subject: Re: [Lava-users] old comercial phones supported by Lava
On Wed, 21 Aug 2019 at 08:00, George Nistor <george.n(a)l4b-software.com> wrote:
>
> Hi,
>
> But I do not understand exactly for example if I can use a Nexus5x; the device is in the list of supported devices Steve McIntyre sent me.
> Milosz Wasilewski said I cannot use it with Lava due to the lack of possibility to force power cycle on them (via serial interface - USB).
>
our current use case doesn't require power cycling the device. It uses the same OS build and tests are executed in chroot environment. This is pretty specific setup for the use case (doesn't require changing kernel).
> To be able to use it requires hw modification of the device?
yes, you need to be able to forcibly power cycle the device. With battery inside the phone this isn't possible, so you have to remove battery and replace it with power supply you can turn off.
>
> What we want to have for the moment is a real device (ex, Nexus 5) on which to run Tradef with Lava.
What is your use case? Are you testing tradefed (ex CTS) changes and stick with the same Android build or do you test Android (kernel, libraries, etc) changes? If it's the former you might be lucky and use existing nexus5 support. If you want to test android using CTS, HW modification is necessary.
milosz
>
> george
>
> -----Original Message-----
> From: Steve McIntyre <steve.mcintyre(a)linaro.org>
> Sent: Tuesday, August 20, 2019 8:51 PM
> To: George Nistor <george.n(a)l4b-software.com>
> Cc: lava-users(a)lists.lavasoftware.org
> Subject: Re: [Lava-users] real devices supported by Lava by default
>
> Hi George,
>
> On Tue, Aug 20, 2019 at 12:54:21PM +0000, George Nistor wrote:
> >
> >I have a question regarding real devices supported by Linaro Lava.
> >
> >Besides these dev boards I found here :
> >https://validation.linaro.org/static/
> >docs/v2/standard-armmp-ramdisk-bbb.html#standard-known-devices
> >
> >Are any other real devices supported in Lava by default? (any
> >commercial phone for example Nexus 5)?
>
> There's a huge set of supported devices. If you don't already have
> LAVA installed, the easiest way to find the list is by looking at the
> set of device type configurations at
>
>
> https://git.lavasoftware.org/lava/lava/tree/master/etc/dispatcher-conf
> ig/device-types
>
> Cheers,
> --
> Steve McIntyre steve.mcintyre(a)linaro.org
> <http://www.linaro.org/> Linaro.org | Open source software for ARM
> SoCs
>
>
> _______________________________________________
> Lava-users mailing list
> Lava-users(a)lists.lavasoftware.org
> https://lists.lavasoftware.org/mailman/listinfo/lava-users
It appears always, right from the start of the job.
lxc is installed on my dispatcher.
Job description
https://pastebin.com/5g15YrWy
DUT description:
https://pastebin.com/bTKdaM5i
I know dut description is not full, but I want do step by step, firstly run
lxc on device.
Maybe you can give some advice about DUT desc.
I'm using fastboot flash for few partitions after that fastboot reboot
flash_cmds_order - it is order of flashing partition
fastboot_sequence - what is it?
Do you have some manual about this parameters description, cause have not
found it on your website.
And one more question, lxc deployed on dispatcher, right?
Best regards,
Ilya Fedusiv
Hi,
But I do not understand exactly for example if I can use a Nexus5x; the device is in the list of supported devices Steve McIntyre sent me.
Milosz Wasilewski said I cannot use it with Lava due to the lack of possibility to force power cycle on them (via serial interface - USB).
To be able to use it requires hw modification of the device?
What we want to have for the moment is a real device (ex, Nexus 5) on which to run Tradef with Lava.
george
-----Original Message-----
From: Steve McIntyre <steve.mcintyre(a)linaro.org>
Sent: Tuesday, August 20, 2019 8:51 PM
To: George Nistor <george.n(a)l4b-software.com>
Cc: lava-users(a)lists.lavasoftware.org
Subject: Re: [Lava-users] real devices supported by Lava by default
Hi George,
On Tue, Aug 20, 2019 at 12:54:21PM +0000, George Nistor wrote:
>
>I have a question regarding real devices supported by Linaro Lava.
>
>Besides these dev boards I found here :
>https://validation.linaro.org/static/
>docs/v2/standard-armmp-ramdisk-bbb.html#standard-known-devices
>
>Are any other real devices supported in Lava by default? (any
>commercial phone for example Nexus 5)?
There's a huge set of supported devices. If you don't already have LAVA installed, the easiest way to find the list is by looking at the set of device type configurations at
https://git.lavasoftware.org/lava/lava/tree/master/etc/dispatcher-config/de…
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
Hello Lava users,
I have a question regarding real devices supported by Linaro Lava.
Besides these dev boards I found here : https://validation.linaro.org/static/docs/v2/standard-armmp-ramdisk-bbb.htm…
Are any other real devices supported in Lava by default? (any commercial phone for example Nexus 5)?
george
Hello, LAVA Team!
I'm trying to implement own device description. Run with standard fastboot
singlenode with lxc.
And received error:
lava-dispatcher, installed at version: 2019.03+stretchstart: 0 validateStart
time: 2019-08-19 15:01:03.367020+00:00 (UTC)validate duration: 0.00result:
fail
definition: lava
case: validate
<http://localhost:10080/results/testcase/8>Cleaning after the jobRoot tmp
directory removed at /var/lib/lava/dispatcher/tmp/2InfrastructureError: The
Infrastructure is not working correctly. Please report this error to LAVA
admins.error_msg: Cannot find command 'lxc-start' in $PATH
error_type: Infrastructure
result: fail
definition: lava
case: job <http://localhost:10080/results/testcase/9>
Best regards, Ilya Fedusiv