lava-users

lava-users@lists.lavasoftware.org

2 participants
944 discussions

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

Hi everyone, in the last few months my team and I have being using LAVA in our Continuous Integration process for the development of a Yocto Linux image for some development boards. These boards were not compatible with the available strategies in LAVA so we had to improvise a little. These boards are however capable of booting from a USB device. Our idea was then to create a new deployment strategy that will download the image file into some Linux device with a OTG USB port and "expose" it using the g_mass_storage kernel module. The OTG USB port will be connected to the test development board USB. For the booting strategy we use the already existing minimal boot where we simply power up the device and let it boot from the USB. We would like to know your thoughts about this idea and if you see any value in these changes for a possible contribution. In the board's device configuration we add the host to where download and mount the image actions: deploy: methods: usbgadget: usb_gadget_host: {{ usb_gadget_host }} We developed these changes on top of the lava-dispatcher verision 2017.7-1~bpo9+1 from the strerch-backports repository. Here is our patch with the changes: We also added some options to apply a patch to the image boot partition to make it usb bootable, but if the image is already usb bootable it is not needed. --- .../pipeline/actions/deploy/strategies.py | 1 + .../pipeline/actions/deploy/usbgadget.py | 254 +++++++++++++++++++++ 2 files changed, 255 insertions(+) create mode 100644 lava_dispatcher/pipeline/actions/deploy/usbgadget.py diff --git a/lava_dispatcher/pipeline/actions/deploy/strategies.py b/lava_dispatcher/pipeline/actions/deploy/strategies.py index da1e155..cfd6438 100644 --- a/lava_dispatcher/pipeline/actions/deploy/strategies.py +++ b/lava_dispatcher/pipeline/actions/deploy/strategies.py @@ -32,3 +32,4 @@ from lava_dispatcher.pipeline.actions.deploy.lxc import Lxc from lava_dispatcher.pipeline.actions.deploy.iso import DeployIso from lava_dispatcher.pipeline.actions.deploy.nfs import Nfs from lava_dispatcher.pipeline.actions.deploy.vemsd import VExpressMsd +from lava_dispatcher.pipeline.actions.deploy.usbgadget import USBGadgetDeployment diff --git a/lava_dispatcher/pipeline/actions/deploy/usbgadget.py b/lava_dispatcher/pipeline/actions/deploy/usbgadget.py new file mode 100644 index 0000000..65347f4 --- /dev/null +++ b/lava_dispatcher/pipeline/actions/deploy/usbgadget.py @@ -0,0 +1,254 @@ +import os +import patch +import guestfs +import errno +import gzip + +from paramiko import SSHClient, AutoAddPolicy +from scp import SCPClient +from tempfile import mkdtemp +from shutil import rmtree + +from lava_dispatcher.pipeline.action import Pipeline, InfrastructureError, Action +from lava_dispatcher.pipeline.logical import Deployment +from lava_dispatcher.pipeline.actions.deploy import DeployAction + +from lava_dispatcher.pipeline.actions.deploy.download import ( + DownloaderAction, +) + +from lava_dispatcher.pipeline.actions.deploy.overlay import ( + OverlayAction, +) + +from lava_dispatcher.pipeline.actions.deploy.apply_overlay import ( + ApplyOverlayImage, +) + + +class PatchFileAction(Action): + + def __init__(self): + super(PatchFileAction, self).__init__() + self.name = "patch-image-file" + self.summary = "patch-image-file" + self.description = "patch-image-file" + + def run(self, connection, max_end_time, args=None): + connection = super(PatchFileAction, self).run( + connection, max_end_time, args) + + decompressed_image = self.get_namespace_data( + action='download-action', label='image', key='file') + self.logger.debug("Image: %s", decompressed_image) + + partition = self.parameters['patch'].get('partition') + if partition is None: + raise JobError( + "Unable to apply the patch, image without 'partition'") + + patchfile = self.get_namespace_data( + action='download-action', label='file', key='patch') + + destination = self.parameters['patch'].get('dst') + + self.patch_file(decompressed_image, partition, destination, patchfile) + return connection + + @staticmethod + def patch_file(image, partition, destination, patchfile): + """ + Reads the destination file from the image, patchs it and writes it back + to the image. + """ + guest = guestfs.GuestFS(python_return_dict=True) + guest.add_drive(image) + guest.launch() + partitions = guest.list_partitions() + if not partitions: + raise InfrastructureError("Unable to prepare guestfs") + guest_partition = partitions[partition] + guest.mount(guest_partition, '/') + + # create mount point + tmpd = mkdtemp() + + # read the file to be patched + f_to_patch = guest.read_file(destination) + + if destination.startswith('/'): + # copy the file locally + copy_dst = os.path.join(tmpd, destination[1:]) + else: + copy_dst = os.path.join(tmpd, destination) + + try: + os.makedirs(os.path.dirname(copy_dst)) + except OSError as exc: + if exc.errno == errno.EEXIST: + pass + else: + raise + + with open(copy_dst, 'w') as dst: + dst.write(f_to_patch) + + # read the patch + ptch = patch.fromfile(patchfile) + + # apply the patch + ptch.apply(root=tmpd) + + # write the patched file back to the image + with open(copy_dst, 'r') as copy: + guest.write(destination, copy.read()) + + guest.umount(guest_partition) + + # remove the mount point + rmtree(tmpd) + + +class USBGadgetScriptAction(Action): + + def __init__(self, host): + super(USBGadgetScriptAction, self).__init__() + self.name = "deploy-usb-gadget" + self.summary = "deploy-usb-gadget" + self.description = "deploy-usb-gadget" + self.host = host + + def validate(self): + if 'deployment_data' in self.parameters: + lava_test_results_dir = self.parameters[ + 'deployment_data']['lava_test_results_dir'] + lava_test_results_dir = lava_test_results_dir % self.job.job_id + self.set_namespace_data(action='test', label='results', + key='lava_test_results_dir', value=lava_test_results_dir) + + def print_transfer_progress(self, filename, size, sent): + current_progress = (100 * sent) / size + if current_progress >= self.transfer_progress + 5: + self.transfer_progress = current_progress + self.logger.debug( + "Transferring file %s. Progress %d%%", filename, current_progress) + + def run(self, connection, max_end_time, args=None): + connection = super(USBGadgetScriptAction, self).run( + connection, max_end_time, args) + + # # Compressing the image file + uncompressed_image = self.get_namespace_data( + action='download-action', label='file', key='image') + self.logger.debug("Compressing the image %s", uncompressed_image) + compressed_image = uncompressed_image + '.gz' + with open(uncompressed_image) as f_in, gzip.open(compressed_image, 'wb') as f_out: + f_out.writelines(f_in) + + # # Try to connect to the usb gadget host + ssh = SSHClient() + ssh.set_missing_host_key_policy(AutoAddPolicy()) + ssh.connect(hostname=self.host, username='root', password='') + dest_file = os.path.join('/mnt/', os.path.basename(compressed_image)) + + # # Clear /mnt folder + self.logger.debug("Clearing /mnt directory") + stdin, stdout, stderr = ssh.exec_command('rm -rf /mnt/*') + exit_code = stdout.channel.recv_exit_status() + if exit_code == 0: + self.logger.debug("/mnt clear") + else: + self.logger.error("Could not clear /mnt on secondary device") + + # # Transfer the compressed image file + self.logger.debug( + "Transferring file %s to the usb gadget host", compressed_image) + self.transfer_progress = 0 + + scp = SCPClient(ssh.get_transport(), + progress=self.print_transfer_progress, + socket_timeout=600.0) + scp.put(compressed_image, dest_file) + scp.close() + + # # Decompress the sent image + self.logger.debug("Decompressing the file %s", dest_file) + stdin, stdout, stderr = ssh.exec_command('gzip -d %s' % (dest_file)) + exit_code = stdout.channel.recv_exit_status() + if exit_code == 0: + self.logger.debug("Decompressed file") + else: + self.logger.error("Could not decompress file: %s", + stderr.readlines()) + + # # Run the g_mass_storage module + dest_file_uncompressed = dest_file[:-3] + self.logger.debug( + "Exposing the image %s as a usb storage", dest_file_uncompressed) + + stdin, stdout, stderr = ssh.exec_command('rmmod g_mass_storage') + exit_code = stdout.channel.recv_exit_status() + + stdin, stdout, stderr = ssh.exec_command( + 'modprobe g_mass_storage file=%s' % (dest_file_uncompressed)) + exit_code = stdout.channel.recv_exit_status() + if exit_code == 0: + self.logger.debug("Mounted mass storage file") + else: + self.logger.error("Could not mount file: %s", + stderr.readlines()) + + ssh.close() + return connection + + +class USBGadgetDeploymentAction(DeployAction): + + def __init__(self): + super(USBGadgetDeploymentAction, self).__init__() + self.name = 'usb-gadget-deploy' + self.description = "deploy images using the fake usb device" + self.summary = "deploy images" + + def populate(self, parameters): + self.internal_pipeline = Pipeline( + parent=self, job=self.job, parameters=parameters) + path = self.mkdtemp() + + # Download the image + self.internal_pipeline.add_action(DownloaderAction('image', path)) + + if self.test_needs_overlay(parameters): + self.internal_pipeline.add_action(OverlayAction()) + self.internal_pipeline.add_action(ApplyOverlayImage()) + + # Patch it if needed + if 'patch' in parameters: + self.internal_pipeline.add_action(DownloaderAction('patch', path)) + self.internal_pipeline.add_action(PatchFileAction()) + + host = self.job.device['actions']['deploy'][ + 'methods']['usbgadget']['usb_gadget_host'] + self.internal_pipeline.add_action(USBGadgetScriptAction(host)) + + +class USBGadgetDeployment(Deployment): + """ + Only for iot2000-usb + """ + compatibility = 4 + + def __init__(self, parent, parameters): + super(USBGadgetDeployment, self).__init__(parent) + self.priority = 1 + self.action = USBGadgetDeploymentAction() + self.action.section = self.action_type + self.action.job = self.job + parent.add_action(self.action, parameters) + + @classmethod + def accepts(cls, device, parameters): + """ + Accept only iot2000-usb jobs + """ + return device['device_type'] == 'iot2000-usb' -- 2.7.4

7 years, 12 months

u-boot commands in Lava

by Denis HUMEAU

Dear all, I'm adding a new device to my test farm This device supports u-boot. Device-type and device have been created, I want to test a simple nfs job. To manage to start the kernel, I need to trigger 2 commands from u-boot before launching the nfs boot command: dcache off and icache off My question here is to know how to manage that with Lava V2. Should it be done in the device or device-type, or should it be done in the test job? Any example is welcome. Best regards, Denis

7 years, 12 months

Executing JSON scripts in Lava

by Zoran S

Hello, I have another problem/ignorance with Lava, so I need a bit of push here. I did execute cyclic test (timer interrupt measurements, time of reaction), using as application hackbench, which introduces tremendous application load (in the peak around 300 loads per 1m/3m/15m) on the core. So, poking around, I found the following JSON script: https://github.com/kernelci/lava-ci/blob/master/templates/cyclictest/generi… Since i know (at least this is my understanding) that the Lava V2 works as a pipeline, so the test jobs must be broken to some blocks *(deploy*, *boot* and *test)*. I would like to a bit change this JSON script to get hackbench as load, but much more important is how I can use this JSON script as Lava test job? I guess, I need to incorporate this script into some yaml format, as explained/described above... Am I correct? How to do this? Any description, example... Advice? Thank you, Zoran _______

7 years, 12 months

Yet another problem I discovered with Lava 2018.2

by Zoran S

Hello Folks, I have really interesting problem with Lava, this time while executing tests. Lava versions: root@stretch:/usr/share# dpkg -l lava-server lava-dispatcher Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==========================-==================-==================-========================================================= ii lava-dispatcher 2018.2.post2-1+str amd64 Linaro Automated Validation Architecture dispatcher ii lava-server 2018.2-1+stretch all Linaro Automated Validation Architecture server root@stretch:/usr/share# _______ This problem appears while downloading initramfs. Although the initramfs I am using from localhost://8010 has the fixed size: 46275637 (decimal), while I download ramdisk.cpio.gz.uboot (which in theory should be 64 bytes more, exactly 46275701): I am getting the following on The Same Jobs, which I repeated in Lava: Job #113: 46597208 (decimal) Job #114: 46596349 (decimal) Job #115: 46595788 (decimal) In other words, I am downloading each time The Same ingredients: http://localhost:8010/initramfs/initramfs.cpio.gz http://localhost:8010/cip-example/cip_v4.4.120-cyclic/v4.4.120-cip20-rt13/a… http://localhost:8010/cip-example/cip_v4.4.120-cyclic/v4.4.120-cip20-rt13/a… Where I have all three time exact size for: zImage - 4167704 (3f9818 hex) am335x-boneblack.dtb - 31552 (7b40 hex) I removed u-boot-tools, then I installed it back. But this did not help. service tftpd-hpa restart did not help as well. So, Iwill continue investigating this problem myself, but did amybody notice the same? Thank you, Zoran

8 years

LAVA V2 | 500 Internal Server Error

by Conrad Djedjebi

Good morning everyone, I would like to know if someone here already face the following message while opening a LAVA results page or LAVA alljobs page : I am looking around LAVA documentation to check if it is a known issue. But if someone here already knows something about it, it could help me also. regards,

8 years

Re: [Lava-users] Running large test suites

by Tim Jaacks

On 19 March 2018 at 16:26, Neil Williams <neil.williams at linaro.org> wrote: >The problem of picking a number is that it depends a lot on the resources >available to the server and the performance of the devices themselves. I get the point. But that information is helpful as well, so maybe some examples of the dimensions in which LAVA can be (and actually is) used might be worth mentioning. I have read most of the LAVA documentation, but had no idea that there are actually running test jobs with 50,000 test cases in it on your servers. >Templating. > >Check out how Jinja2 is used for the server-side device configuration >templates - Jinja2 can output any text-based format, we chose YAML. The >same principles are used by the Linaro QA team to produce the test job >submissions. Templates live in version control, the commit hash of the >template gets included into the metadata of the output. That’s a very good hint, thank you. I haven’t thought of this, yet. Are the repositories containing your templates publicly available? 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 SOLUTIONS THAT COMPLETE! Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz

8 years

Re: [Lava-users] Running large test suites

by Tim Jaacks

>150 test cases does not necessarily mean large - we have test jobs which >produce 50,000 test cases per test job, that is when a large test set can >become a problem, depending on the available resources on the server. It >was these test jobs which led to the sections in the documentation which >you mention later. If your server doesn't struggle with the current test >jobs, you might not have anything to do at this stage. > >However, if you have clear groups of test cases, you should investigate >using test sets which preserve those boundaries within the reported results: >https://staging.validation.linaro.org/static/docs/v2/results-intro.html#tes… Thanks for the information. Perhaps it would be a good idea to add these figures to the documentation, so that new users have an idea of what a “large” test set is. I am just starting out with LAVA, so I haven’t set up any productive tests yet. At the moment I am creating a concept of how we can include LAVA into our workflow. Part of this is the question how we handle test jobs and how we store them in our SCM. >MultiNode does offer a possible option but MultiNode itself is complex and >not all test jobs would be able to use it - essentially you can use >MultiNode with SSH to have multiple logins to the same device running the >same software. Problems include issues with locking resources, load on the >device from running tests in parallel, problems within the test being able >to run in parallel in the first place amongst others. > >>From your enquiry, it does not sound as if you need any of that. You might >want to look at a wrapper script which consumes the output of the tests and >filters out noise but apart from that, 150 test cases is really not large. >We routinely run functional tests which produce more test cases than that: >https://staging.validation.linaro.org/results/214157 >https://staging.validation.linaro.org/scheduler/job/214157 I actually have to use MultiNode for some of our testcases anyway. These testcases need a remote server or client connected to the DUT (e.g. testing hardware interfaces like RS485, CAN, etc.). And this is actually part of the question: When I declare all of my testcases in one test job, I have to declare the remote nodes for ALL of the tests in there as well. This makes the test job huge and confusing, though, I think. How do you handle such cases? Do you ever test that kind of interfaces at all? 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 SOLUTIONS THAT COMPLETE! Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz

8 years

Not able to have any U-boot scripts executed on Lava

by Zoran S

Hello, I have very interesting problem: I would like to do Lava testing of BBB01, but I am not suceeding. Simple and plain, my U-Boot scripts gets somehow rejected, they are not executed. I do download correctly, I have all the correct ingredients in place, but the U-Boot scripts are not activated, at the time of U-boot prompt. Here is my output, from the testing: https://pastebin.com/hTQQSLU1 Rather, the thing gets executed from SDCard (from /boot on rootfs). I have no idea why this is not executed. Help appreciated! Thank you, Zoran

8 years

Re: [Lava-users] Sending commands with the minimal bootloader class

by Tim Jaacks

Hi Neil, thanks for your reply. >>(*) As a sidenote I'd like to add, that using "BootloaderCommandsAction" alone does not work. I had to add "BootloaderCommandOverlay" as well, because the "commands" are set at the end of the "run" function of this class: >> >> self.set_namespace_data(action='bootloader-overlay', label=self.method, key='commands', value=subs) >> >>Is this by design? It seems like a bug to me, since I did not find any documentation about this dependency. > >The majority of classes in lava-dispatcher have dependencies which are entirely determined by the way that the test devices need to operate. A new Strategy class would ensure that both are added for this use case. > >You also need to consider whether the test job itself contains a test action and therefore whether an overlay is needed at all. Simple boot testing doesn't have to include a test action at all, just deploy and boot. That's the point: I don't need the overlay action in my strategy. But I had to include it, because the command action did not work without it. And to clarify things: The overlay you are talking about (adding LAVA files to the rootfs) is not the overlay I am talking about (replacing placeholders in the commands with actual values). >I assume that simply no one has ever used "BootloaderCommandsAction" without "BootloaderCommandOverlay", so no one ever noticed. In my opinion "BootloaderCommandsAction" should work on its own. > >No, it should not. The commands frequently need to be modified by other actions. That's okay. But why are they set in "BootloaderCommandOverlay" in the first place? This is totally unexpected. I am new to the code, so I don't know anything about the internals. But from a user's perspective, it seems like bad design to have an action's essential variable set in a different action. 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 SOLUTIONS THAT COMPLETE! Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz

8 years

Sending commands with the minimal bootloader class

by Tim Jaacks

Hello everyone, I have a device with a very basic proprietary bootloader and want to automate it with LAVA. I figured out that the "minimal" bootloader class covers basically everything I need, except that it cannot send commands to the bootloader. So for a quick test, I added "self.internal_pipeline.add_action(BootloaderCommandsAction())" to actions/boot/minimal.py. With this modification (*) I was able to create a device class which can run a smoke test successfully on my device. In a former question on this mailing list concerning the integration of my bootloader, someone recommended me to implement a new boot strategy. Would you accept a code contribution which adds a new boot strategy only differing from the "minimal" strategy in this one addition? Or would it perhaps make sense to add the "BootloaderCommandsAction" directly to the "minimal" strategy? (*) As a sidenote I'd like to add, that using "BootloaderCommandsAction" alone does not work. I had to add "BootloaderCommandOverlay" as well, because the "commands" are set at the end of the "run" function of this class: self.set_namespace_data(action='bootloader-overlay', label=self.method, key='commands', value=subs) Is this by design? It seems like a bug to me, since I did not find any documentation about this dependency. I assume that simply no one has ever used "BootloaderCommandsAction" without "BootloaderCommandOverlay", so no one ever noticed. In my opinion "BootloaderCommandsAction" should work on its own. 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 SOLUTIONS THAT COMPLETE! Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz

8 years

← Newer
1
...
68
69
70
71
72
73
74
...
95
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users