Hi,
I am using the docker-compose file provided by lava community.
I don't understand why there is a separate tftpd container and also how my
device who is on host local network will communicate with it. Also same
things I don't understand for nfs container.
Please let me know
Thanks and regards
ROSHAN KUMAR
Hi,
I created a lava server docker container on amd64 machine using
lavasoftware/lava-server docker image present on docker hub.
But after running the container I didn't find any Dispatcher online except
lava-logs.
Did the current version of lava server docker container doesn't work as
dispatcher similar to normal lava server.
Please let me know.
Thanks and regards
ROSHAN KUMAR
Hi!
I want to mix two flashing types for device : fastboot and custom ( run custom script )
I already did both types separately using deploy methods : fastboot and flasher
How I can mix both types?
And in web gui in device panel what does mean that error?
Configuration Error: missing or invalid template.
Jobs requesting this device type (mix-type) will not be able to start until a template is available on the master.
Best regards,
Ilya
Hello everyone,
if you follow the latest developments, you might have seen that LAVA is now
using whitenoise to allow gunicorn to serve static files.
In the current releases (2020.01 and before), apache2 is forwarding dynamic
requests to gunicorn and serving static files himself.
In the next release, apache2 will forward all the requests to gunicorn that
will serve both dynamic and static content.
If you use the debian packages, apache2 will still be installed and
configured automatically.
We are proposing to drop the apache2 packages from the lava-server docker
container. In fact, if you use the docker container, you have anyway to
setup a reverse proxy to make the container visible to the outside world
and to do the SSL termination.
What do you think about this?
Rgds
--
Rémi Duraffort
LAVA Architect
Linaro
The slaves/worker logs are in /var/log/lava-dispatcher/lava-slave.log
Le mar. 11 févr. 2020 à 12:37, dhanu msys <dhanuskd.palnati(a)gmail.com> a
écrit :
> Hi Remi,
>
> After upgrading the LAVA Package , I have seen Worker Status show
> "Offline".
>
> As per Earlier Experience , I have check the Lava-Logs and Lava-Master
> Logs under /var/log/lava-server/lava-logs.log and
> /var/log/lava-server/lava-master.log , it seems both are running fine
> without any error.
>
> And also I have checked the Encryption in the both lava-master & lava-logs
> under /etc/lava-server/lava-logs & /etc/lava-server/lava-master. PFA.
>
> Please check the attachment logs once and let me know if any changes need
> to be done specific to the latest lava package.
>
> Thanks & Regards,
> Dhanunjaya. P
>
>
> On Wed, Feb 5, 2020 at 6:59 PM dhanu msys <dhanuskd.palnati(a)gmail.com>
> wrote:
>
>> Hi Remi,
>>
>> Thanks for sharing the Information.
>>
>> I can able to update the LAVA Package.
>>
>> Please find the latest packages list in below.
>>
>> doclava-aosp/stable 6.0.1+r55-1 all
>> klavaro/stable 3.03-2 amd64
>> lava-common/unknown,now 2020.01+10+buster all [installed]
>> lava-coordinator/unknown 2020.01+10+buster all [upgradable from: 0.1.7-1]
>> lava-dev/unknown 2020.01+10+buster all [upgradable from: 2019.01-5]
>> lava-dispatcher-host/unknown,now 2020.01+10+buster all
>> [installed,automatic]
>> lava-dispatcher/unknown,now 2020.01+10+buster all [installed]
>> lava-lxc-mocker/unknown 2020.01+10+buster all
>> lava-server-doc/unknown 2020.01+10+buster all [upgradable from: 2019.01-5]
>> lava-server/unknown,now 2020.01+10+buster all [installed]
>> lava-tool/stable,now 0.25-2 all [installed]
>> lava/unknown,now 2020.01+10+buster all [installed]
>> lavacli/unknown 0.9.7+buster all [upgradable from: 0.9.5-1]
>> lavapdu-client/stable,now 0.0.5-1 all [installed]
>> lavapdu-daemon/stable,now 0.0.5-1 all [installed]
>> r-cran-lava/stable 1.6.4-1 all
>> r-cran-lavaan/stable 0.6.3-1 all
>>
>> Thanks for immediate support.
>>
>> Regards,
>> Dhanunjaya. P
>>
>>
>> On Wed, Feb 5, 2020 at 3:55 PM Remi Duraffort <remi.duraffort(a)linaro.org>
>> wrote:
>>
>>> Hello,
>>>
>>> add the apt lavasoftware depository.
>>>
>>> See
>>> https://lava.readthedocs.io/en/latest/admin/basic-tutorials/instance/instal…
>>> This will create a new source
>>> "deb https://apt.lavasoftware.org/release buster main"
>>>
>>>
>>> Rgds
>>>
>>> Le mer. 5 févr. 2020 à 05:59, dhanu msys <dhanuskd.palnati(a)gmail.com> a
>>> écrit :
>>>
>>>> Hi Team,
>>>>
>>>> How to get the Latest Version changes in the LAVA Package for Single
>>>> Instance?
>>>>
>>>> What is the Latest version released ?
>>>>
>>>> Please let me know the "How to Upgrade the Lava package without
>>>> disturbing the existing test setup.
>>>>
>>>> Here I have attached the Lava packages list in my current setup to run
>>>> the lava for reference. PFA.
>>>>
>>>> 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,
How to get the Latest Version changes in the LAVA Package for Single
Instance?
What is the Latest version released ?
Please let me know the "How to Upgrade the Lava package without disturbing
the existing test setup.
Here I have attached the Lava packages list in my current setup to run the
lava for reference. PFA.
Thanks & Regards,
Dhanunjaya. P
Hi Andrei,
Thanks for suggestion, I too had a same doubt before proceeding with the
upgrade.
I will try to setup the latest version in new system or i will take a
backup of existing setup and run the test.
Thanks & Regards,
Dhanunjaya. P
On Mon, Jan 27, 2020 at 2:24 PM Andrei Gansari <andrei.gansari(a)nxp.com>
wrote:
> Hello Dhanunjaya,
>
>
>
> These are the instructions on installing lava, you have to do something
> similar to this in order to upgrade:
>
> https://docs.lavasoftware.org/lava/installing_on_debian.html
>
>
>
> I’m not sure if it will break or not your current setup, so be cautious
> when upgrading, better backup if you have a live setup that is testing
> other boards.
>
>
>
> I’m not a currently maintaining a LAVA server so I don’t have experience
> updating from one version to another.
>
> Better you search the mailing list, ask on the mailing list or tryout on a
> virtual machine.
>
>
>
>
>
> Andrei
>
>
>
> *From:* dhanu msys <dhanuskd.palnati(a)gmail.com>
> *Sent:* Friday, January 24, 2020 12:44 PM
> *To:* Andrei Gansari <andrei.gansari(a)nxp.com>
> *Subject:* Re: [EXT] Re: [Lava-users] Test jobs to boot the target
> through JLink
>
>
>
> *Caution: *EXT Email
>
> Hi Andrei,
>
>
>
> Can you please share the procedure to upgrade to the latest lava version.
>
>
>
> Thanks in advance.
>
>
>
> Regards,
>
> Dhanunjaya. P
>
>
>
>
>
> On Thu, Jan 23, 2020 at 7:33 PM Andrei Gansari <andrei.gansari(a)nxp.com>
> wrote:
>
> From the screenshot it looks like you have a version of LAVA that does not
> support jlink boot method.
>
> JLink was added in version 2019.10-1
>
>
>
> Andrei
>
>
>
> *From:* dhanu msys <dhanuskd.palnati(a)gmail.com>
> *Sent:* Thursday, January 23, 2020 3:13 PM
> *To:* Andrei Gansari <andrei.gansari(a)nxp.com>
> *Cc:* Kumar Gala <kumar.gala(a)linaro.org>; Andrei Gansari <
> andrei.gansari(a)linaro.org>; lava-users <lava-users(a)lists.lavasoftware.org>
> *Subject:* Re: [EXT] Re: [Lava-users] Test jobs to boot the target
> through JLink
>
>
>
> *Caution: *EXT Email
>
> Hi Andrei,
>
>
>
> I run the test job based on the references shared by you.
>
>
>
> But , facing the error , while running the test job.
>
>
>
> Here I have attached the device template & device configuration files
> along with the error.
>
>
>
> Please find the attachments & please provide me the inputs.
>
>
>
> Thanks in Advance.
>
>
>
> Regards,
>
> Dhanunjaya. P
>
>
>
>
>
> On Tue, Jan 21, 2020 at 5:29 PM Andrei Gansari <andrei.gansari(a)nxp.com>
> wrote:
>
> Hello Dhanunjaya. P,
>
>
>
> You need to create a yaml file in
> lava/lava_dispatcher/tests/sample_jobs/fpga_a64-jlink.yaml … assuming you
> have already created the device fpga_a64.
>
>
>
> You have an example of FRDM-K64F booting cmsis-dap here:
>
>
> https://github.com/Linaro/lite-lava-docker-compose/blob/lite/example/lava.j…
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>
>
> You need to replace “method: cmsis-dap” -> “method: jlink”
>
>
>
> I didn’t run a clean lava environment, so I maybe missing something.
>
>
>
>
>
> Andrei G.
>
>
>
> *From:* dhanu msys <dhanuskd.palnati(a)gmail.com>
> *Sent:* Tuesday, January 21, 2020 12:31 PM
> *To:* Andrei Gansari <andrei.gansari(a)nxp.com>
> *Cc:* Kumar Gala <kumar.gala(a)linaro.org>; Andrei Gansari <
> andrei.gansari(a)linaro.org>; lava-users <lava-users(a)lists.lavasoftware.org>
> *Subject:* Re: [EXT] Re: [Lava-users] Test jobs to boot the target
> through JLink
>
>
>
> *Caution: *EXT Email
>
> Hi Andrei,
>
>
>
> Based on the information shared earlier , i have tried to configure the
> device type to make use of jlink based boot method test job , but i have
> faced an issue "Configuration Error: missing or invalid template*.* Jobs
> requesting this device type (fpga_a64) will not be able to start until a
> template is available on the master."
>
>
>
> Can you please check once and share the updated Device-Type Template also.
>
>
>
> Thanks & Regards,
>
> Dhanunjaya. P
>
>
>
>
>
> On Tue, Jan 21, 2020 at 3:28 PM dhanu msys <dhanuskd.palnati(a)gmail.com>
> wrote:
>
> Hi Andrei ,
>
> Hi Kumar,
>
>
>
> Can you please share some of the Test Job definition references to check
> the Jlink-based test jobs configurations.
>
>
>
> Thanks & Regards,
>
> Dhanunjaya. P
>
>
>
>
>
> On Tue, Nov 26, 2019 at 2:36 PM Andrei Gansari <andrei.gansari(a)nxp.com>
> wrote:
>
> I’ve tested lava+jlink on Cortex M with both onboard debugger and external
> debugger, like the one you referenced.
>
> You should change the following if needed:
>
>
>
> address:
>
> *0x00000000*
>
> options:
>
> - '-device *MK64FN1M0xxx12'*
>
> - '-if SWD'
>
> - '-speed 4000'
>
>
>
> The interface SWD is supported, not JTAG, that can be easily changed if
> you need to.
>
>
>
> Regards,
>
> Andrei
>
>
>
> *From:* Lava-users <lava-users-bounces(a)lists.lavasoftware.org> *On Behalf
> Of *dhanu msys
> *Sent:* Tuesday, November 26, 2019 7:49 AM
> *To:* Kumar Gala <kumar.gala(a)linaro.org>
> *Cc:* Andrei Gansari <andrei.gansari(a)linaro.org>; lava-users <
> lava-users(a)lists.lavasoftware.org>
> *Subject:* [EXT] Re: [Lava-users] Test jobs to boot the target through
> JLink
>
>
>
> *Caution: *EXT Email
>
> Hi Kumar,
>
>
>
> Thanks for sharing the reference.
>
>
>
> It's better to have some references for the test jobs submission also.
>
>
>
> Currently we are in initial phase to make use of LAVA , so we wants to
> check the feasibility to deploy through JLink based test jobs.
>
>
>
> Here I have provided the JLink Interface , which we are going to use for
> the development.
>
>
>
>
> https://www.thingbits.net/products/segger-j-link-base-jtag-swd-debugger?utm…
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.thing…>
>
>
>
>
> Regards,
>
> Dhanunjaya. P
>
>
>
>
>
> On Sat, Nov 23, 2019 at 9:37 PM Kumar Gala <kumar.gala(a)linaro.org> wrote:
>
>
>
> > On Nov 21, 2019, at 11:06 PM, dhanu msys <dhanuskd.palnati(a)gmail.com>
> wrote:
> >
> > Hi Team,
> >
> > Can you please share some reference test jobs to run the tests using
> J-Link boot method.
>
> Here’s a reference to the board cfg side change for J-Link:
>
>
> https://github.com/agansari/lite-lava/blob/35a5bcbc01780638e6fd5e126bdfe180…
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>
>
> Andrei,
>
> Did you have a test job example to go along with this?
>
> - k
>
>
Hello,
Our internal LAVA setup has been hitting this crash intermittently (it reproduces about one out of every 30 job submissions). The below log snippet is from the 2019.07 LAVA docker images, but we updated to the 2019.12 images and the crash still occurs with the same error signature.
lava-master | 2019-10-22 15:37:17,539 DEBUG |--> [523] scheduling
lava-master | 2019-10-22 15:37:17,854 INFO [523] START => lava-dispatcher (CY8CKIT_062-01)
lava-master | 2019-10-22 15:37:17,969 INFO [523] lava-dispatcher => START_OK
lava-master | 2019-10-22 15:37:22,981 INFO [523] lava-dispatcher => END (lava-run crashed, mark job as INCOMPLETE)
lava-master | 2019-10-22 15:37:23,038 ERROR [523] Unable to dump 'description.yaml'
lava-master | 2019-10-22 15:37:23,038 ERROR [523] Compressed data ended before the end-of-stream marker was reached
lava-master | Traceback (most recent call last):
lava-master | File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-master.py", line 337, in _handle_end
lava-master | description = lzma.decompress(compressed_description)
lava-master | File "/usr/lib/python3.5/lzma.py", line 340, in decompress
lava-master | raise LZMAError("Compressed data ended before the "
lava-master | _lzma.LZMAError: Compressed data ended before the end-of-stream marker was reached
Please let me know if I can provide any other info to help debug.
Thanks,
Alex
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.
Hey everyone,
I have a problem where a physical hardware device on my worker passed through to an LXC container cannot be read from or written to when I am connected to the LXC in a hacking session via SSH.
I have registered the device in my static_info:
{% set static_info = [
{"board_id": "GO31472"},
] %}
LAVA starts the LXC and attaches the device to it correctly:
start: 2.2 lxc-add-static (timeout 00:04:50) [remote]
Adding /dev/ttyUSB16, /dev/serial/by-id/usb-GFL_M_504_G_GO31472-if00-port0, /dev/bus/usb/004/008, /dev/serial/by-path/pci-0000:00:1d.3-usb-0:1:1.0-port0
nice lxc-device -n lxc-remote-10577 add /dev/ttyUSB16
nice lxc-device -n lxc-remote-10577 add /dev/serial/by-id/usb-GFL_M_504_G_GO31472-if00-port0
nice lxc-device -n lxc-remote-10577 add /dev/bus/usb/004/008
nice lxc-device -n lxc-remote-10577 add /dev/serial/by-path/pci-0000:00:1d.3-usb-0:1:1.0-port0
end: 2.2 lxc-add-static (duration 00:00:00) [remote]
When I connect to the LXC via SSH using a hacking session, the device is there, but I cannot access it:
root@lxc-remote-10577:~# ls -la /dev/ttyUSB16
crw-r--r-- 1 root root 180, 0 Aug 27 11:26 /dev/ttyUSB16
root@lxc-remote-10577:~# cat /dev/ttyUSB16
cat: /dev/ttyUSB16: Operation not permitted
However, when I attach to the LXC directly from the worker using "lxc-attach", I can access it:
root@lxc-remote-10577:~# ls -la /dev/ttyUSB16
crw-r--r-- 1 root root 180, 0 Aug 27 11:26 /dev/ttyUSB16
root@lxc-remote-10577:~# cat /dev/ttyUSB16
����������^C
root@lxc-remote-10577:/#
Did anybody else encounter such a problem before? Any hints on what might be the difference between lxc-attach and the SSH connection?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Schlachthofstrasse 20
21079 Hamburg
Direct: +49 40 791 899 - 183
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
