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
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
Hi all,
I'm running CTS tests on Android 9, with LAVA.
I noticed the CTS module CtsUsbTests failed because of the error:
"usb serial != adb serial expected:<[]> but was:<[a266fa0a5c85d6ee]>"
This module is a hostsidetest, and checks if usb serial matches adb serial
by running "lsusb -v" on the host and checking the iSerial returned by the
command. (
https://android.googlesource.com/platform/cts/+/refs/heads/master/hostsidet…
)
And this test fails when I run it with LAVA so I checked on my local PC and
the test passes. Indeed, if I run the command "lsusb -v" I get this output
for iSerial:
iSerial 3 351d5a0a5c85d936
The third field is the adb serial, so it matches well.
So I suspected the LXC container to not give the usb serial. So I checked
directly in the container and after running "lsusb -v" I got:
iSerial 3
The adb serial is missing.
So, do you know a way to make the LXC see correctly the usb serial ?
Regards,
Axel
Hello Lava Users,
The target on which I am trying to run tests from LAVA has # prompt after
login.
As specified in Documentation
https://lava.collabora.co.uk/static/docs/v2/actions-boot.html?highlight=pro…
- boot:
prompts:
# escape the brackets to ensure that the prompt does not match
# kernel debug lines which may mention initramfs
- '\(initramfs\)'
in the job definition I am including -
boot:
.....
failure_retry: 4
prompts:
- '\(# \)'
But in the job execution log getting "*auto-login-action: Wait for
prompt ['\\(# \\)', 'Login incorrect', 'Login timed out'] (timeout
00:07:52)*".
Also if we want to debug while running the job which will be the best
possible approach to follow.
In the Documentation got information on "Debugging Django issues"
which states two settings are required
in/etc/lava-server/settings.conf
- "DEBUG": true,
- "USE_DEBUG_TOOLBAR": true,
Thanks,
Hemanth.
Hello Denis,
in the timeouts dictionary, you can specify a connections dictionary.
So something like this should work:
timeouts:
connections:
overlay-unpack:
minutes: 10
See
https://docs.lavasoftware.org/lava/actions-timeout.html#connection-timeout
Le mer. 24 juil. 2019 à 14:30, Denis HUMEAU <denis.humeau(a)st.com> a écrit :
> Hi Rémi,
>
>
>
> Where do you set a connection timeout? In the job, in the device
> description?
>
> I didn’t find anything explicit in LAVA help.
>
>
>
> Denis
>
>
>
> *From:* Remi Duraffort <remi.duraffort(a)linaro.org>
> *Sent:* mercredi 24 juillet 2019 14:23
> *To:* Denis HUMEAU <denis.humeau(a)st.com>
> *Cc:* Lava-users(a)lists.lavasoftware.org
> *Subject:* Re: [Lava-users] overlay-unpack timeout error
>
>
>
> Hello Denis,
>
>
>
> have you tried settings the connection timeout? IIRC lava is expecting the
> board to send something and will timeout if not receiving anything during
> "connection timeout" seconds.
>
>
>
>
>
> Rgds
>
>
>
> Le mar. 23 juil. 2019 à 08:58, Denis HUMEAU <denis.humeau(a)st.com> a
> écrit :
>
> Hello Rémi,
>
>
>
> Here is a plain log corresponding to the case described by Philippe.
>
> Let me know if you need more.
>
>
>
> Denis
>
>
>
> *From:* Lava-users <lava-users-bounces(a)lists.lavasoftware.org> *On Behalf
> Of *Remi Duraffort
> *Sent:* lundi 22 juillet 2019 17:42
> *To:* Philippe BEGNIC <philippe.begnic(a)st.com>
> *Cc:* Lava-users(a)lists.lavasoftware.org
> *Subject:* Re: [Lava-users] overlay-unpack timeout error
>
>
>
> Hello Philippe,
>
>
>
> could you send the raw logs?
>
>
>
>
>
> Rgds
>
>
>
> Le ven. 19 juil. 2019 à 09:34, Philippe BEGNIC <philippe.begnic(a)st.com> a
> écrit :
>
> 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
>
>
>
> _______________________________________________
> Lava-users mailing list
> Lava-users(a)lists.lavasoftware.org
> https://lists.lavasoftware.org/mailman/listinfo/lava-users
>
>
>
>
> --
>
> Rémi Duraffort
>
> LAVA Team, Linaro
>
>
>
>
> --
>
> Rémi Duraffort
>
> LAVA Team, Linaro
>
--
Rémi Duraffort
LAVA Team, Linaro
Hi,
I'm trying to write a test definition that contains a repeat block (boot / test) as described in the help section.
However the repeat block gives me the syntax error:
"Invalid definition: extra keys not allowed @ data['actions'][2]['repeat']"
I then tried using https://git.lavasoftware.org/lava/lava/blob/master/lava_dispatcher/tests/sa… as an example and I get the same error message with the repeat.
Is this something that is expected to work? I would like to use repeat blocks for some soak tests that I am writing.
Pete
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,
I am working with Denis HUMEAU for STMicroelectronics.
I have a problem to perform several reboot with LAVA job when I am using an image with requested login.
I do not understand why 'root' login is sent to device under test when the prompt is received (lines 941, 942, 943, 944 in job_43624.log file). 'root' login should be sent only when a 'login_prompt' is received (like in lines 696, 697, 698, 699, 701, 702 in job_43624.log file).
Could you help me to solve this problem, please ?
Regards,
[Description: Description: Description: Description: Description: Description: logo_big5]
Jerome BESNARD | TINA: 166 7142 | Tel: +33 (0)244027142 | Mobile: +33 (0)623392912
MDG | SW Validation Ingineer
Hello everyone,
I have the following LAVA setup:
LAVA server - 1 LAVA worker - 16 DUTs
The LAVA server and the LAVA worker are located in my company network (172.20.0.0/16).
The DUTs are connected to the LAVA worker in a local network (192.168.20.0/24).
Thus, the DUTs are not accessible from outside the worker.
What is a good way to allow for hacking sessions to a DUT (let's say 192.168.20.247) from the company network?
I can think of the following solutions:
1. Use SSH forwarding on lava-worker:
ssh -g -L 50000:localhost:22 -N root(a)192.168.20.247
2. Forward the SSH port via netcat on lava-worker:
nc -l -p 50000 -c "nc 192.168.20.247 22"
3. Forward the SSH port via iptables on lava-worker:
iptables -t nat -A PREROUTING -p tcp --dport 50000 -j DNAT --to 192.168.20.247:22
All of these make the device accessible via "ssh -p 50000 root@lava-worker" from the company network. So far, so good.
However, in an ideal world this forwarding would be active only during the hacking session, so that in normal test jobs the DUT is not accessible.
Is there a way to achieve this? Does anyone have experience with such a scenario? How do you handle DUT access for hacking sessions?
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
