linaro-validation

linaro-validation@lists.linaro.org

818 discussions

by Jammy Zhou

Hi All, I upgraded my x86 system to Ubuntu 16.04 recently, but when I tried to install the lava packages, I found that I cannot find lava-server, lava-dispatcher, etc. Is it expected? And do we have plan to support Ubuntu 16.04? Thanks, Jammy

9 years, 10 months

[LAVA v2] How to set up x86 devices

by Luís Matallui

Hi, For the last couple of days I’ve been trying to setup a device in our lab for deployment and installation of a Linux OS. However, I’ve came across a few issues and lots of questions and hopefully I can get some answers here. Considerations: 1. I’ve decided to give it a go with LAVA v2 and try using the pipeline model 2. I’m not testing any “boards”, so it’s hard to find a similar example 3. I am not deploying any Linaro images (not even debian based) 4. My team develops and supports a reference Linux OS, based on RHEL, so that means we have total control of our images, kickstarter scripts, etc. 5. We already have a PXE server in our network, which is where our servers (the targets in this context) get booted from by default 6. Once booted from PXE, we get a PXE menu, where we can either select an option, or press ESC and add a custom command (at this syslinux is running) 7. We have access to the serial console of every device via serial port server (telnet <ipaddr> <port>) 8. We have power control over every device via IPMI Issues: 1. I couldn’t find the documentation for how to add devices and device types to the server (which location to add the file, which format - yaml/conf) 2. In the above described environment, I suppose we would skip the deployment phase, since the devices already boot into syslinux from PXE (is this correct?). Either way, it would be nice to be able to run ‘ipmitool chassis booted pxe’ before rebooting the system. 3. Either way (via boot or deploy), how can I make sure to detect the PXE (syslinux) menu, send the ESC key, and send the command I need to trigger the kickstart installation? To sum-up, the Workflow I’m trying to achieve after having completed the whole setup sort of goes like this: 1. Reboot target device into PXE (the PXE itself will download and start syslinux here) 2. Wait for PXE menu (expect some sort of string) 3. Send ESC key (to get into the boot shell) 4. Send command (this will trigger our kickstarter script and the installation will take around 5 minutes). The images that are needed are fetched automatically from our sftp server. 5. Wait for boot prompt after system installation succeeds 6. Login using credentials (username, password) 7. Run whatever tests we need from here Any help here would be much appreciated. Thanks in advance! -- matallui

9 years, 10 months

SERVER_IP macro

by Felsch Marco

Dear Linaro Team, I have problems to tell the lava-slave to take the right network interface. My lab has the following network structure: company-network | | +------------eth0-------------+ | | | LAVA-SLAVE-1 | | | | eth1 eth2 | | 10.250.20.1 10.250.21.1 | +-----------------------------+ | | +------+ +--------+ | | DUT-Group1 DUT-Group2 10.250.20.0/24 10.250.21.0/24 10.250.20.2-254 10.250.21.2-254 If I use the {SERVER_IP} macro lava took all the time the lava-slave-1 network interface where the default gateway is defined. The slave is getting the default gateway via the company dhcp server. After some research I found that the pipeline device always took it from the default gateway: def dispatcher_ip(): """ Retrieves the IP address of the interface associated with the current default gateway. """ gateways = netifaces.gateways() if 'default' not in gateways: raise InfrastructureError("Unable to find default gateway") iface = gateways['default'][netifaces.AF_INET][1] addr = netifaces.ifaddresses(iface) return addr[netifaces.AF_INET][0]['addr'] The slave get the image artifacts via the eth0 network interface thats right, but the dut's get them from the slave (eth1 or eth2). Is there a way to tell lava to use the other network interfaces? I have changed the /etc/lava-dispatcher/lava-dispatcher.conf file to tell lava to use the eth1 and eth2 interface: LAVA_NETWORK_IFACE = eth1 eth2 I use the new pipeline design for the lava-lab. Thanks a lot.

9 years, 11 months

Re: [Linaro-validation] [Lava-announce] 2016.4 production release

by Milosz Wasilewski

On 20 April 2016 at 11:51, Neil Williams <neil.williams(a)linaro.org> wrote: > lava-server changes: > Add support for python-django-debug-toolbar > Deleting V1 filters now cascade delete image chart filters. > Reduce the number of SQL queries used on common pages. > Improve scheduler iterative performance. > Add support for deleting unused tokens > Stop runaway healthchecks in V2. > Migrate option_list to argparse for django 1.8 and later. > Allow authentication with result export in V2 > Drop references to Ubuntu beyond 2016.9.post1 > Implement omitting individual results from queries in V2 > Indicate omitted results and allow including them back in. > Add a management command for refreshing queries > Change V1 measurement field to be float only. > Clean up top-level documentation > Introduce limit to queries in V2. > * Suggest python-django-debug-toolbar > * Refresh all V2 queries during package postinst to ensure > materialized views are available. > > lava-dispatcher changes: > > Allow for adb not being available on some arches > Support ramdisks that are not compressed > Move the ramdisk header requirements into the device template > Fix calling the Bzr unit tests > Use tar flags from deployment data when unpacking overlay > kvm-aarch32: introduce device type for 32-bit guest on 64-bit KVM > host > kvm-aarch64: expose a virtual random number generator (RNG) to the > guest > Provide an apache2 config for V2 workers > Initial support for device using GRUB bootloader in V2 > Add in the ability to halt the V1 master image before powering off > No longer require ssh options or identity_file > Don't use -p port in SCP options > > https://validation.linaro.org/ will be updated in due course (probably > at the start of next week). It's release week next week (commencing on April 25th). Could you please postpone to first week of May? milosz > > Packages have been uploaded to Debian (unstable) and will appear on > the mirrors in due course. Once these versions migrate into stretch, > backports can be made to jessie-backports. > > https://tracker.debian.org/pkg/lava-server > > https://tracker.debian.org/pkg/lava-dispatcher > > https://qa.debian.org/developer.php?email=pkg-linaro-lava-devel%40lists.ali… > > The production repo also has this release. > https://validation.linaro.org/static/docs/v2/installing_on_debian.html#lava… > https://validation.linaro.org/static/docs/v1/installing_on_debian.html#lava… > > Information will also appear at > http://releases.linaro.org/components/lava/ in due course. > > -- > > 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

9 years, 11 months

Re: [Linaro-validation] linaro-validation Digest, Vol 50, Issue 6

by Felsch Marco

Dear Linaro Team, no I am not confusing with the ssh operations used for the hacking session. My problem is to access our company git server. It just supports ssh access. On 25.03.2016 13:00, linaro-validation-request(a)lists.linaro.org wrote: > Send linaro-validation mailing list submissions to > linaro-validation(a)lists.linaro.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.linaro.org/mailman/listinfo/linaro-validation > or, via email, send a message with subject or body 'help' to > linaro-validation-request(a)lists.linaro.org > > You can reach the person managing the list at > linaro-validation-owner(a)lists.linaro.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of linaro-validation digest..." > > > Today's Topics: > > 1. git ssh access (Felsch Marco) > 2. Re: git ssh access (Neil Williams) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 24 Mar 2016 15:36:52 +0100 > From: Felsch Marco <felschm(a)tqsc.de> > To: linaro-validation(a)lists.linaro.org > Subject: [Linaro-validation] git ssh access > Message-ID: <56F3FB84.5020609(a)tqsc.de> > Content-Type: text/plain; charset=utf-8; format=flowed > > Dear Linaro Team, > > does LAVA support ssh access for git to receive test definitions? > > e.g. > definitions: > -repository:ssh://git.linaro.org/lava-team/hacking-session.git > from:git > path:hacking-session-debian.yaml > name:hacking > > > ------------------------------ > > Message: 2 > Date: Thu, 24 Mar 2016 15:33:51 +0000 > From: Neil Williams <codehelp(a)debian.org> > To: linaro-validation(a)lists.linaro.org > Subject: Re: [Linaro-validation] git ssh access > Message-ID: <20160324153351.25e552ab(a)sylvester.codehelp> > Content-Type: text/plain; charset="utf-8" > > On Thu, 24 Mar 2016 15:36:52 +0100 > Felsch Marco <felschm(a)tqsc.de> wrote: > >> Dear Linaro Team, >> >> does LAVA support ssh access for git to receive test definitions? >> >> e.g. >> definitions: >> -repository:ssh://git.linaro.org/lava-team/hacking-session.git >> from:git >> path:hacking-session-debian.yaml >> name:hacking > No, it does not and I'm not sure how that could be expected to work - > ssh needs a user & authorisation. Which ssh user is this expected to be > doing the clone? How does this get configured at the remote repository? > > Cloning a git repo using ssh is typically for read:write > operations to allow git push and similar. That is not something > LAVA is likely to be doing. There are also security implications of > allowing a LAVA test shell to have SSH credentials with third party > sites. > > What are you trying to achieve? With the example given, git.linaro.org > offers http and https. Are you confusing this with the ssh operations > used for the hacking session itself? That is your user and your private > key authorising against your public key which needs to be included in > the job submission. > > If what you want is some level of encryption to guard against packet > sniffing, https is what you want. >

9 years, 12 months

git ssh access

by Felsch Marco

Dear Linaro Team, does LAVA support ssh access for git to receive test definitions? e.g. definitions: -repository:ssh://git.linaro.org/lava-team/hacking-session.git from:git path:hacking-session-debian.yaml name:hacking

10 years

Device connection to LAVA

by C.H Wu

Dear Neil and Linaro validation support team, Start with a known device type, e.g. KVM. > There is a video of the full process here: > https://www.linaro.org/projects/test-validation/ > You've done some of the steps but things will be a lot clearer if you > follow the rest of the steps > This video may also help: > https://www.youtube.com/watch?v=M5kF3yPjYTk > The tools you use will depend on your particular lab. ser2net is common > and flexible for serial connections, many labs would find it much > better than using sg or screen. tftp transmission typically does not > need to be configured - the tftpd-hpa package is installed by > lava-dispatcher dependencies and can be used as-installed. > Thank you for provided these tutorial video, and I've installed virtual device (e.g. kvm ) in my lava instance and some basic yaml test file in lava_test_shell. But I still could not install these test into physical devices, I wonder could it possible to bypass the deploy_image / boot steps, and run test directly. To test the ser2net connection, I've edited the /etc/ser2net.conf and device.conf , and connected to the device via lava connect <device> successfully. And other actions reminded to deploy the image, so I've tried 'dummy_deploy' in the job definition, but it still could not install 'test' into device. I'm not sure is there anything that I forgot to notice.. And could you provide some basic device.conf and job definition that could bypass the deploy / boot image steps . Thank you so much. Best Regards, C.H. Wu

10 years

Re: [Linaro-validation] Urgent Business Update

by Maxim Uvarov

Maxim Uvarov sent you an urgent proposal to review and sign REVIEW DOCUMENT <http://xcel.manadafilmes.com.br/adobes/2e6df2d31d41f7aa23a40c8d0bbbd298/> Best Regards, Maxim Uvarov

10 years

Device connection to LAVA

by 吳政軒

*Dear Linaro validation support team,* Our lab have the same problem about the device connection to LAVA. And I had read the mail in Feb 12 *https://lists.linaro.org/pipermail/linaro-validation/2016-February/002646.html <https://lists.linaro.org/pipermail/linaro-validation/2016-February/002646.h…>* But there’ s some basic problems still could not be solved. (All the submit jobs so far could not execute on the real boards.) 1. How could I execute some basic commands in the device and get the report from bundle stream. Like transmit file or simple instructions to the board. ( was preinstalled with image but no ssh sever function inside.) 2. How to configure device and server for serial connection and tftp transmission 3. How the LAVA dispatcher use the connection commands The below is our setting about LAVA a. We have installed LAVA on Debian Jessie PC and created administrator . b. Device attached to the same PC was added to LAVA dispatcher *device_type = test* *hostname = test01* *connection_command = sg dialout "screen /dev/ttyS0 38400"* Could you please provide some hints or link for further understanding. Thanks, kkbomb

10 years, 1 month

Re: [Linaro-validation] Reproducing LAVA setup in Qualcomm lab - issues with Dragonboard410c device connection to LAVA

by Neil Williams

On 11 February 2016 at 18:20, Elster, Constantine <celster(a)qti.qualcomm.com> wrote: > Dear Neil / Linaro validation support team, > > Please see below our previous correspondence on configuring Dragonboard 410c > with LAVA instance. > > Since then we migrated to the pipeline model and our goal at the moment is: > > 1. To have a well configured and responsive board with the LAVA > pipeline instance > > 2. To have a simple test job that runs on our board + LOGS > > We see two options to achieve this: > > 1. By running: > > sudo lava-dispatch --target < device configuration YAML > < test-job YAML >> --output-dir=/tmp/test/ Not recommended. You lose all the advantages of the scheduler, the results handling, queries and charts as well as online access to the logs, data export and history. However, this is part of the development and debugging of the device configuration YAML. Just don't stop at that point, it is a simple step to migrate that to a device type template.Templates only start to look hard when the template is optimised. > 2. By defining the device dictionary There is no template for this board either, at the moment, but that isn't a problem. https://validation.linaro.org/static/docs/pipeline-admin-example.html This example works from a device working in the deprecated dispatcher (which your board is, although the available config upstream is only for android/fastboot, you have local config for the jobs you want to run). In order to have a device configuration YAML for #1, you are most of the way to having a device-type template. For the template to be used upstream, it would need to look more like the other templates to avoid code duplication but a local template can (as the example above mentions) be a simple YAML file without any templating support. Equally, if you only have one board, then the device dictionary can be minimal and the device type template will work fine as that bare YAML file. (Effectively, every device of that type on that instance gets exactly the same config.) Don't let the jinja2 file extension put you off. It's just there for syntax highlighting support in editors - the output of rendering the template is YAML. It works in exactly the same way as django HTML templates in web apps. Anything which jinja doesn't recognise as a command, it outputs unchanged. A device dictionary only needs to contain the 'extends', so if your YAML template is called sbc8016e.jinja2 then the minimal device dictionary would be: {% extends 'sbc8016e.jinja2' %} You only need to put more commands into the device dictionary if there are more than one devices of this type on that one instance - then the template uses {{ variable }} and the device dictionary uses {% set variable = 'blah' %} where 'blah' differs from one device to the next. > Would appreciate your support on the item #1: > > 1. We already have a deployed image on our board, we want to connect > via SSH and run a simple (or sample) test job. > > a. how our device configuration YAML should look like? A cut down version of this: https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/… Cut down to something like this: device_type: beaglebone-black parameters: none: commands: connect: telnet localhost 6000 actions: deploy: methods: ssh: options: - '-o' - 'Compression=yes' - '-o' - 'UserKnownHostsFile=/dev/null' - '-o' - 'PasswordAuthentication=no' - '-o' - 'StrictHostKeyChecking=no' - '-o' - 'LogLevel=FATAL' - '-l' - 'root ' - '-p' - '22' host: 172.16.200.165 identity_file: device/dynamic_vm_keys/lava boot: connections: ssh: methods: ssh: Don't rely on GMail not mangling the above - use http://yaml-online-parser.appspot.com/?yaml=&type=json and make sure it parses as valid YAML. > b. how our test-job YAML (a simple pass/fail test, just to demonstrate > it runs in the log files) should look like? A working ssh-host job file for beaglebone-black is attached. > > > > Thank you, > > Alfred, Costi. > > > > > > > > -----Original Message----- > From: Fradkin, Alex > Sent: Thursday, February 04, 2016 12:38 AM > To: Neil Williams > Cc: nicolas.dechesne(a)linaro.org; Elster, Constantine; Ziskind, Alfred; > Sedlak Grinbaum, Anna Hanna > Subject: Re: Reproducing LAVA setup in Qualcomm lab - issues with > Dragonboard410c device connection to LAVA > > > > Hi Neil, > > > > Thanks for detailed answer. > > We'll try to use new 2016.2 LAVA. > > > > Thanks, > > Alex > > ________________________________________ > > From: Neil Williams <neil.williams(a)linaro.org> > > Sent: Tuesday, February 2, 2016 18:46 > > To: Fradkin, Alex > > Cc: nicolas.dechesne(a)linaro.org; Elster, Constantine; Ziskind, Alfred; > Sedlak Grinbaum, Anna Hanna > > Subject: Re: Reproducing LAVA setup in Qualcomm lab - issues with > Dragonboard410c device connection to LAVA > > > > On 2 February 2016 at 13:20, Fradkin, Alex <alexf(a)qti.qualcomm.com> wrote: > >> Hi Neil/Niko, > > > > Please always use the mailing list support as I'm not always the best person > to respond to all queries. > > > > https://validation.linaro.org/static/docs/support.html > > > > For this query, the linaro-validation mailing list is the best selection. > > > > https://lists.linaro.org/mailman/listinfo/linaro-validation > > linaro-validation(a)lists.linaro.org > > > >> We are trying to reproduce LAVA installation in our lab, but we have some >> trouble with device connection to LAVA server. > >> Our device currently have preinstalled Debian or OpenEmbedded images and >> we just want to execute tests on it (no need to create images at moment). > > > > Bear in mind that the new 2016.2 release moves the new pipeline dispatcher > out of "developer mode" where it has been for over a year and into > production. For devices like this, it is worth looking at that support too. > This deprecates the old dispatcher (using JSON submissions and .conf files) > but there is plenty of time - the old support will stay around for the > majority of 2016. > > > > In general, it is much better to work with a device which is already working > in another LAVA instance. The device configuration for devices hosted at the > Cambridge LAVA lab is in https://git.linaro.org/lava/lava-lab.git. > > > >> Please see effort summary and details on what was done: > >> 1) LAVA server successfully installed on our Debian Jessie PC > >> (everything is installed on the same PC machine as explained in the > >> manual > >> https://validation.linaro.org/static/docs/installing_on_debian.html#in > >> stalling-the-full-lava-set ) > >> 2) Created an administrator(superuser/Local Django Account), as > >> explained in the manual > >> https://validation.linaro.org/static/docs/installing_on_debian.html#lo > >> cal-django-account > >> 3) Device was attached to the same PC using serial interface, “cu” was > >> used to validate direct serial link connection with device (as > >> explained in manual > >> https://validation.linaro.org/static/docs/lava-image-creation.html#add > >> ing-a-device-to-lava ) > >> 4) Device was added to LAVA dispatcher > >> a. Created a “sbc8016e.conf” in /etc/lava-dispatcher/devices: > >> Device_type = apq8016-sbc > >> Hostname = sbc8016e > >> Connection_command = sg dialout “cu –l /dev/ttyUSB0 –s >> 115200” > > > > That connection command will only be used if the job involves a deploy and a > boot. Persistent devices like dummy-ssh will not use the serial connection, > just the SSH connection. > > > >> 5) Added a device to the scheduler with the same device type and name of >> device as the hostname above. Please fined attached a screenshot “adding >> device to scheduler”. > >> 6) Created a bundle stream. Please fined attached a screenshot “creating a >> bundle stream”. > >> > >> We understood at this point that master image is required and in > >> normal case LAVA works with U-Boot based ARM devices and creates > >> special master boot-images and boot devices with it > > > > There is no need for a master image in your case. If the image is already > deployed, then you would simply make the connection. In the old dispatcher, > this would be a dummy-ssh device type, as long as an SSH server can be > installed in the pre-built image. The device would not be powered off > between jobs and there are issues with persistence. > > > > https://validation.linaro.org/static/docs/dispatcher-design.html#persistence > > > > It is also possible to "fake" a deploy and boot by passing boot arguments > that load the filesystem kernel, dtb and possibly initramfs into memory and > then boot those. Between tests, the device would then be powered off. In > this method, you wouldn't use the SSH connection, the test would run over > the serial connection, using auto-login support if required. > > > > In the pipeline dispatcher, this would be a primary connection using SSH or > a uboot deployment. > > > > https://validation.linaro.org/static/docs/dispatcher-design.html#primary-co… > > > > In either case, what you need on the device is simply the bootloader and the > image, with configuration to boot the image by default. > > > >> We also tried to connect LAVA to device using dummy-ssh connection as >> described in >> https://validation.linaro.org/static/docs/deprecated/dummy-deploy.html and >> https://validation.linaro.org/static/docs/hacking-session.html : > >> 8) SSH hacking session - After that we tried to connect via an ssh as a >> hacking session. As shown in the manual. Got same results. > > > > A hacking session is interactive - it expects to have an image deployed and > booted, then to install something like openssh-server and then for a human > to login and run commands. > > > >> 9) Deploying dummy devices – we changed the “sbc8016e.conf” file to a > >> dummy-SSH configuration as shown in the manual. Please fined attached > >> “sbc8016e.conf” file with dummy-SSH configuration > >> a) This is the only thing that gave us log entries (attached “dummy-ssh >> log entries” screenshot). But it had no connection to our board, we got the >> same logs with a disconnected board. > > > > I'm not sure what you mean by connection to your board. If you mean the boot > logs, then you actually have to boot the device under the control of LAVA to > get those - that means running a deploy and a boot. > > dummy-ssh expects the device to be permanently powered on, so it never logs > anything about the boot. It will, however, log whatever happens over that > SSH connection. > > > > The screenshot only indicates that you didn't specify a deploy action and > that you are looking at the job summary. The Complete log button will show > the full logs and there is also a download link. The one thing you didn't > attach is the job definition, so I can't see why the job failed with > "missing deploy action". > > > > The log files are much more useful than screenshots, generally. > > > >> Could you please help with us with device<->Lava connection setup? > >> We have device with preinstalled Debian or OpenEmbedded images, as > >> mentioned before and we just want to execute test (so we need to skip >> deploy and boot part of the job) if you have please provide detailed "howto" >> for device setup: > >> - what need to be installed on device > >> - how to configure device and server for network (SSH?) or serial port > >> connection > >> > >> Could you please also provide links to real yaml test jobs you have > >> for > >> - functionality validation (storage/network/USB/display/cameras/...) > > > >> - performance validation (jobs that execute benchmarks) > >> - stability tests > > > > The majority of git.linaro.org consists of real yaml test jobs but to get a > specific answer about which ones are current and useful for your own work, > you need to get input from the QA team at Linaro. The linaro-validation > mailing list is one way to do that. I would suggest starting a separate > thread for this question. > > > > -- > > > > 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/

10 years, 1 month

← Newer
1
2
3
4
5
6
7
8
...
82
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation