Hi Team,
I am trying to run the test_jobs on the specific device type
"stm32mp1157c-dk2" , but its throwing an error message to deploy "flasher"
method in the deployment parameters.
Here I have attached the screenshots for reference. PFA.
Thanks & Regards,
Dhanunjaya. P
Guys,
We have a problem as next:
[cid:image001.jpg@01D5958F.E65E7670]
The story is we have kernel exception when device boot, then per next code:
if index == cls.TRACE or index == cls.EXCEPTION:
res = "fail"
if action:
action.logger.warning(
"%s: %s" % (action.name, cls.MESSAGE_CHOICES[index][2])
)
# TRACE may need a newline to force a prompt
connection.sendline(connection.check_char)
It will send a "#" to device, but unfortunately, the exception time is too close the final login, then the "#" was sent to user login as next:
Imx8qxpmek login: #
Then when we send "root", it definitely cannot login, how to resolve?
More, why lava send "#" to device when kernel have exception?
Hello,
could you give me the exact version? If you are admin, just ask debian to
give you the package version.
If you are a user, this is printed in the first line of every job logs.
Rgds
Le lun. 4 nov. 2019 à 07:58, dhanu msys <dhanuskd.palnati(a)gmail.com> a
écrit :
> Hi Remi,
>
> I was using LAVA Version V2, please correct me if i am quite wrong.
>
> Please let me know how to find out the lava version using command prompt.
>
> Thanks & Regards,
> Dhanunjaya. P
>
>
> On Thu, Oct 31, 2019 at 9:42 PM Remi Duraffort <remi.duraffort(a)linaro.org>
> wrote:
>
>> Hello,
>>
>> which version are you using?
>>
>>
>> Rgds
>>
>> Le jeu. 31 oct. 2019 à 13:19, dhanu msys <dhanuskd.palnati(a)gmail.com> a
>> écrit :
>>
>>> 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
>>> _______________________________________________
>>> 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
Hi Team,
I have submitted some sample test jobs for qemu device type on my local
lava setup.
After successful submission of tests , I can't able to see the jobs running
status , the state remains to "submitted".
When i gone through the lava-master logs , Observed the warnings saying
that can't able to schedule the jobs due to lava-logs is offline.
Here I have attached the screenshots. Please find the attachments.
Can you please let me know how to schedule the jobs on master by manual.
Thanks & Regards,
Dhanunjaya. P
Hello,
We upgrade from LAVA 2019.04 to 2019.10 and we have issues with the prompt matching when the device boots.
We test 2 kinds of Linux images:
* Development image
* it outputs data into the serial (secure boot, uboot, kernel, systemd)
* user: root, pass: empty
* Production image
* it doesn't output anything and *only presents the login prompt*
* user: root, pass: it could be anything
The workflow is the following:
* spin up LXC container for recovery mode
* boot the DUT waiting for the prompt. We don't need to login using the serial connection but we need to wait the prompt to understand that the board has successfully booted
* run tests from the LXC container and using ssh to the DUT
In LAVA 2019.04 everything was working as expected:
...
start: 7.3 auto-login-action (timeout 00:05:57) [target]
Using line separator: #'\n'#
No login prompt set.
Parsing kernel messages
['-+\\[ cut here \\]-+\\s+(.*\\s+-+\\[ end trace (\\w*) \\]-+)', '(Unhandled fault.*)\\r\\n', 'Kernel panic - (.*) end Kernel panic', 'Stack:\\s+(.*\\s+-+\\[ end trace (\\w*) \\]-+)', 'mbed-linux-os-(.*) login:', 'Login timed out', 'Login incorrect']
[auto-login-action] Waiting for messages, (timeout 00:05:57)
Waiting using forced prompt support. 178.45381999015808s timeout
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Mbed Linux OS mbl-warrior-dev-production_build64 mbed-linux-os-674 ttymxc5
Matched prompt #4: mbed-linux-os-(.*) login:
...
While in 2019.10 the job is failing with the following:
...
start: 7.3 auto-login-action (timeout 00:05:57) [target]
auto-login-action: Wait for prompt ['Linux version [0-9]'] (timeout 00:06:00)
Trying ::1...
Connected to localhost.
Escape character is '^]'.
�
Mbed Linux OS mbl-warrior-dev-production_build74 mbed-linux-os-1764 ttymxc5
...
Another thing we observed in LAVA 2019.10: using the dev images (hence with output data) it works without any problem.
Here a snippet of our pipeline:
....
- boot:
namespace: recovery
timeout:
minutes: 5
method: recovery
commands: recovery
- deploy:
timeout:
minutes: 10
to: recovery
namespace: recovery
connection: lxc
images:
images to download.....
os: debian
- test:
namespace: lxc
connection: lxc
timeout:
minutes: 10
definitions:
- from: inline
name: flash-image
path: inline/flash-image.yaml
repository:
metadata:
format: Lava-Test Test Definition 1.0
name: flash-image
description: "Flash image to board in recovery mode"
os:
- oe
run:
steps:
- steps to recover the board
- boot:
namespace: recovery
timeout:
minutes: 5
method: recovery
commands: exit
- boot:
namespace: target
method: minimal
failure_retry: 3
prompts:
- "mbed-linux-os-(.*) login:"
timeout:
minutes: 6
....
Looking at the LAVA code we think the following commit changed the behaviour: https://git.lavasoftware.org/lava/lava/commit/6b5698a2d3ed23031e40aa1d86181…
How are we supposed to change the pipeline to make it work again?
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/docs/mbed-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.
All,
I'm testing some feature about associated log lines in lava, job.yaml is as follows.
Job.yaml:
- test:
connection: lxc
definitions:
- from: inline
name: my_suite
path: me.yml
repository:
metadata:
format: Lava-Test Test Definition 1.0
name: smoke-case-run
description: Run smoke case
run:
steps:
- lava-test-case "Case001" --shell 'echo wow'
- lava-test-case "Case002" --shell 'ls'
namespace: lxcEnv
timeout:
minutes: 10
1. Then, let's see next picture of Case001:
[cid:image002.jpg@01D59322.5F8C2990]
it said startline=153, lastline=154, that's next:
Line153 is "Received signal: <STARTTC> Case001", Line 154 is "Received signal: <ENDTC> Case001".
You could see in fact the log "wow" not in the 2 lines.
[cid:image008.jpg@01D59322.5F8C2990]
2. let's see next picture of Case002:
[cid:image009.jpg@01D59322.5F8C2990]
It said startline=160, lastline=163, that's next:
[cid:image010.jpg@01D59322.5F8C2990]
It's ok, that between Ln160 & Ln163 I got the output of `ls`.
What happened for "Case001"? The startline & endline not correct. It seems if I directly do "echo", the info is wrong. while "execute command", the info is correct.
Of course my case will not just do "echo", just I want to know if any risk for me to fetch the wrong START/LAST lines in other scenario? (I will use script to fetch it with xmlrpc).
Hi,
When test job uses boot action with method: u-boot there was an option
to tell it which boot command to call in u-boot shell. This was done
using 'type' parameter. Example from docs:
- boot:
method: u-boot
commands: nfs
type: bootz
prompts:
- 'root@debian:~#'
This parameter was deprecated for more than a year. I just submitted a
patch to remove this feature. If you're using it, please consider
changing to setup where kernel image type is set using deploy section.
Example:
- deploy:
timeout:
minutes: 4
to: tftp
os: oe
kernel:
url: 'https://example.com/zImage'
type: 'zimage'
dtb:
url: 'https://example.com/dtb.dtb'
nfsrootfs:
url: 'https://example.com/rootfs.tar.xz'
compression: xz
Pull request: https://git.lavasoftware.org/mwasilew/lava/pipelines/5794
milosz
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.
