lava-users

lava-users@lists.lavasoftware.org

1 participants
942 discussions

about the grub parameter : interrupt_prompts

by Xu, Hongyu

Hi , In our testing, we must test the os centos and Ubuntu, but the grub interrupt_prompts is different betweent Ubuntu and centos. So in my device_type template I use "menu_options: {{ grub_method }}", but the "grub_method" must define in device jinjia2 file. I don't want to often chang the device jinja2 file , whether I can define some options in the job file? Please give me some help! The attachmen are my device_type and device file! methods: grub: menu_options: {{ grub_method }} parameters: {% if grub_method == 'centos' %} interrupt_prompt: {{ grub_interrupt_prompt|default('Press \'e\' to edit the selected item, or \'c\' for a command prompt.') }} {% elif grub_method == 'ubuntu' %} interrupt_prompt: {{ grub_interrupt_prompt|default(' Press enter to boot the selected OS') }} {% elif grub_method == 'pxe' %} interrupt_prompt: {{ grub_interrupt_prompt|default('Press \'e\' to edit the selected item, or \'c\' for a command prompt.') }} {% endif %} bootloader_prompt: {{ grub_efi_bootloader_prompt|default('grub>') }} boot_message: {{ kernel_boot_message | default("Booting Linux Kernel...") }} Best Regards XuHongyu This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.

8 years, 2 months

Connection closed by foreign host

by Philippe BEGNIC

Hello Lava Team, We faced to errors when we launched long tests ( e.g LTP tests, stress tests ... ) since we use Lava dockers. The following messages are returned by Lava and the test stop : Connection closed by foreign host. err: lava_test_shell connection dropped Marking unfinished test run as failed These error messages appears during the test, if no message are generated on the console during approximatively six minutes. We found a workaround that consist to send periodically message to the console, allowing the test to complete. I would like to know if we can setup a setting to I would like to know if there is a way to inhibit this control, or to change the timeout settings of this control ? Our configuration : Lava 2017.6 with dockers Regards Philippe Begnic

8 years, 2 months

Troubles using custom notification client

by David Lewin

Hi, >From a client side, I'd like to be notified that jobs are achieved in a distant lava server. I started with the example provided at https://validation.linaro.org/static/docs/v2/data-export.html#write-your-ow… 1. In a 1st try I've changed the example - because I'm using port 10080 - and it works without the <lookup_publisher> . For that, I've hard coded the url returned by lookup_publisher but this only prints out one status at a time, ie :I needed to restart the script each time to have updates : "Submited"->*Ctrl-C*->Running->*Ctrl-C*->complete 2. In a 2nd time I've tried to implement lookup_publisher thinking the status would be updated automatically. In that case it wants to connect to 5500 and obviously fails after timeout import xmlrpclib > > import argparse > import yaml > import signal > import zmq > import xmlrpclib > from urlparse import urlsplit > > > FINISHED_JOB_STATUS = ["Complete", "Incomplete", "Canceled"] > > token = "mytoken" > username = "username" > #hostname = "lava-server:10080" > > > class JobEndTimeoutError(Exception): > """ Raise when the specified job does not finish in certain timeframe. > """ > > > class Timeout(object): > """ Timeout error class with ALARM signal. Accepts time in seconds. """ > class TimeoutError(Exception): > pass > > def __init__(self, sec): > self.sec = sec > > def __enter__(self): > signal.signal(signal.SIGALRM, self.timeout_raise) > signal.alarm(self.sec) > > def __exit__(self, *args): > signal.alarm(0) > > def timeout_raise(self, *args): > raise Timeout.TimeoutError() > > > class JobListener(object): > > def __init__(self, url): > self.context = zmq.Context.instance() > self.sock = self.context.socket(zmq.SUB) > > self.sock.setsockopt(zmq.SUBSCRIBE, b"") > self.sock.connect(url) > > def wait_for_job_end(self, job_id, timeout=None): > > try: > with Timeout(timeout): > while True: > msg = self.sock.recv_multipart() > try: > (topic, uuid, dt, username, data) = msg[:] > except IndexError: > # Droping invalid message > continue > > data = yaml.safe_load(data) > if "job" in data: > if data["job"] == job_id: > if data["status"] in FINISHED_JOB_STATUS: > return data > > except Timeout.TimeoutError: > raise JobEndTimeoutError( > "JobListener timed out after %s seconds." % timeout) > > def lookup_publisher(hostname): > """ > Lookup the publisher details using XML-RPC > on the specified hostname. > """ > xmlrpc_url = "http://%s:10080/RPC2" % (hostname) > server = xmlrpclib.ServerProxy(xmlrpc_url) > socket = server.scheduler.get_publisher_event_socket() > port = urlsplit(socket).port > listener_url = 'tcp://%s:%s' % (hostname,port) > print("Using %s" % listener_url) > return listener_url > > > > if __name__ == '__main__': > # timeout=1200 > > parser = argparse.ArgumentParser() > parser.add_argument("-j", "--job-id", type=int, help="Job ID to wait > for") > parser.add_argument("-t", "--timeout", type=int, help="Timeout in > seconds") > parser.add_argument("--hostname", help="hostname of the instance") > > options = parser.parse_args() > > # server = xmlrpclib.ServerProxy("http://%s:%s@%s/RPC2" % (username, > token, hostname)) > > #print(server.system.listMethods()) > # ret_status=server.scheduler.job_status(options.job_id) > # print (ret_status['job_status']) > > #publisher = 'tcp://%s' % (hostname) > publisher = lookup_publisher(options.hostname) > > listener = JobListener(publisher) > listener.wait_for_job_end(options.job_id, options.timeout) > >

8 years, 2 months

help: can't use specific branch of a test definition repository

by Xu, Hongyu

Hi all , I have saw the doc about : https://validation.linaro.org/static/docs/v2/test-repositories.html#test-re…! My test-definition is in the brach dev-br1, not the master . So I point the branch in my yaml file, but it do noting ! Why? Please give me some help? Best Regards XuHongyu This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.

8 years, 2 months

Problem with LAVA 2017.12

by LABBE Corentin

Hello I have installed a fresh 2017.12 in a docker and I hit two problem: - With the exception of lava-coordinator, all services (lava-master, lava-server, lava-slave, etc...) fail to start with: service lava-xxxx start lava-xxxx: unrecognized service All Other service successfully start (postgresql, apache2) - I have then re-added old init scripts and when I add a worker with: "lava-server manage workers add lab-slave" I get: Traceback (most recent call last): File "/usr/bin/lava-server", line 78, in <module> main() File "/usr/bin/lava-server", line 74, in main execute_from_command_line(django_options) File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 367, in execute_from_command_line utility.execute() File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 359, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 294, in run_from_argv self.execute(*args, **cmd_options) File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 345, in execute output = self.handle(*args, **options) File "/usr/lib/python2.7/dist-packages/lava_server/management/commands/workers.py", line 77, in handle options["disabled"]) KeyError: 'disabled' iNote that before I have successfully done commands like adding user or device-types Regards

8 years, 2 months

Device Integration Stories - request for contributions

by Neil Williams

Possibly the hardest thing that can be done with LAVA is to integrate a new device-type. Every story is different, every device has it's own issues. The LAVA software team would like to build a history of integration stories to document the recovery process, provide integration hints for others, build a wider picture of the requirements of automation across the ecosystem. A key part of any device integration is how to recover a device which has been taken offline by a broken build or broken test action. It is rare that a new device is suitable for LAVA directly out of the box, there are usually firmware updates, configuration changes, jumper settings or other mods required. Each of these steps needs to be documented so that someone else can integrate the same board into their instance and the same steps are useful when recovering a bricked device. Having the Jinja2 template is not usually enough. (As a side note on that, we do welcome all contributions of new jinja2 templates. The one place where everyone looks for new device-type support is lava_scheduler_app/tests/device-types/ in the master branch of http://git.linaro.org/lava/lava-server.git. If you have integrated a device-type which does not exist in that directory, please follow the contribution guidelines in the documentation and submit your Jinja2 template for review.) https://git.linaro.org/lava/lava-server.git/tree/lava_scheduler_app/tests/d… Recent device integrations in LAVA are documented through a process of comments on JIRA stories (all LAVA JIRA stories are accessible anonymously). Sometimes this turns out to be trial and error, so sometimes a README document or similar is created for easy reference. I'll post some of our recovery README documents on this thread later. This is a request for contributions of your integration stories, your device recovery README documents and your input on what are the minimum requirements for automation in general. It doesn't matter how unusual the hardware or how commonplace. It doesn't matter if it took months to integrate or days. Someone may need your information to setup the same device in their instance. If your device is available on the open market, someone could be thinking of how to automate it. Please post your recovery README texts, integration stories here. This list is publicly archived, so this should make it easy for others to find your contribution in their favourite search engine. In future, as well as unit tests, the LAVA software team may ask for the recovery notes and integration story to be posted here when reviewing contributions of Jinja2 templates. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

8 years, 3 months

Setting the "inactivity timeout" parameter

by Dragos Iorgulescu

Hello! Is there a way to set/override/disable the inactivity timeout? While working with a (sometimes) slower board, we end up with "Terminal.stop: Inactivity timeout." . I believe this might have to do with the fact that the board fails to respond in a timely fashion and LAVA marks this as hung. While searching for this in the docs, I only found a reference for hacking sessions. Kind regards, Dragos

8 years, 3 months

rootfs resize in LAVA2

by Dragos Iorgulescu

Hi everyone! Does LAVA offer a way to resize rootfs images (“ramdisk_files”, as they are referred to in the code) before deploying them? We are working with our own Linux distro on a Cavium board and we need to resize the rootfs image (which is ext4) after the test overlays are added by LAVA. This step is necessary since we need to run a series of community tests that imply a large number of package dependencies. Also, we do not want to resize the whole image by default, since this will have other CI storage side effects and, also, some policy implications (that I am not really aware of 😊). Anyway, we are currently looking at adding/altering apply_overlay.py (pipeline/actions/) in order to run a resize2fs command after the “updated” ramdisk is unmounted. Just wondering if there is already a more elegant way of doing this. We are also considering making some extensions and maybe get to the point where we could specify this type of requirement in the device dictionary or the device template itself, and then specific code would be executed only if such a setting would be encountered at runtime, but that remains to be discussed. Thanks in advance! Dragoș

8 years, 3 months

Local lava test

by Denis HUMEAU

Dear all, I'm quite sure I've seen somewhere in Lava documentation an article explaining how to replay some Lava jobs in a local mode, but I can't find this piece of information anymore. By local mode, I mean: - DUT at the developer desk, not in the test farm - Jobs available on a Lava server - Developer wants to replay/modify locally a job Can you share any link or help on this? Many thanks, Denis

8 years, 3 months

Customizing the deployment and booting actions

by Ros Dos Santos, Alfonso (CT RDA DS EVO OPS DIA SE 1)

Hello everyone, in our current project we have some devices that are not "directly" supported by lava. I would like to ask for you opinion on which would be the correct way to proceed. The main problem is that our devices have a EFI implementation in the firmware that is making the task of installing uboot very hard. To avoid this, we thought about serving the image through an "emulated" usb stick. On that regard, we made some progress by setting up a secondary device that would use the linux g_mass_storage module to serve the image through the USB otg port. Our setup is then: 1) The actual testing device 2) The secondary device which only serves the image with g_mass_storage 3) The host machine running the lava-slave application. We thought that we could add a new device-type template to the lava server that would somehow override the deployment and boot actions to address our setup. We tried to look into the base.jinja2 file for some sort of entry point that would allow us to, for example, run a script that would first send the image to the secondary device and secondly run the g_mass_storage module with the image file. Unfortunately, it is still not clear for us how exactly we could inject/override those steps and ignore for instance the boot loader commands. The first question would be, are we going in the right direction? Is there any piece of documentation that would describe a similar problem? What would be your recommendations on this topic? thanks a lot in advance. Best, Alfonso

8 years, 3 months

← Newer
1
...
75
76
77
78
79
80
81
...
95
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users