lava-users

lava-users@lists.lavasoftware.org

3 participants
925 discussions

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ș

7 years, 7 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

7 years, 7 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

7 years, 7 months

how to add the overlay to my os, start the test definition

by Xu, Hongyu

Hi , I deploy the device with grub(uefi) method. Now it can interrupt to grub>, and run the boot cmd and auto login. I use the pxe iso installation boot or the sata boot, not the nfs boot. But the lava-overlay file only add into ramdisk(initrd.img), it will disappear when os bootup. So I use the transfer_overlay in my job , but it do nothing, the test shell can't be find . Please give me some help! Job.yaml: actions: - deploy: to: tftp kernel: url: http://swlab004/1680141/vmlinuz-4.11.0-7.1.hxt.aarch64 type: zimage ramdisk: url: http://swlab004/1680141/initramfs-4.11.0-7.1.hxt.aarch64.img compression: gz install_overlay: false preseed: url: http://swlab004/centos7/anaconda-ks_1026.cfg os: centos timeout: minutes: 5 - boot: timeout: minutes: 200 connection: serial method: uefi-menu commands: ramdisk_boot auto_login: login_prompt: ".* login:" username: root password_prompt: 'Password:' password: root transfer_overlay: download_command: ifconfig;wget -S --progress=dot:giga unpack_command: tar -C / -xzf prompts: - 'Last login: .*' - '[root@.* .*]#' parameters: shutdown-message: "reboot: Restarting system" - test: timeout: minutes: 50 definitions: - repository: metadata: format: Lava-Test Test Definition 1.0 name: smoke-tests-basic description: "Basic system test command for Linaro Ubuntu images. The test runs basic commands like pwd, uname, vmstat, ifconfig, lscpu, lsusb and lsb_release." maintainer: - hongyu.xu(a)hxt-semitech.com os: - centos scope: - functional run: steps: - echo "test1a:" "pass" from: inline name: smoke-tests1 path: inline/smoke-tests.yaml 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.

7 years, 7 months

LAVA and Mender

by Arnstein Kleven

Greetings, my embedded system is using Mender for over-the-air updates. The way Mender works is that the embedded system needs to have to rootfs partitions, where one is actively being used, and the other is written to when a over-the-air update is initiated. After the new rootfs is written, Mender will change a variable in the bootloader environment and reboot, so that the system boots into the new rootfs. If there is a problem booting into the new rootfs, the bootloader will be set to boot into the old one again. Has anyone here written LAVA tests for systems that use Mender? If so, have you experienced that Mender has complicated the test automation? Any Mender boot test templates would also be appreciated. -- Kind regards, Arnstein Kleven

7 years, 7 months

how to auto login the os with lava

by Xu, Hongyu

Hi dear all, I boot my device with nfs in lava, but it can't auto login the os , I put the logs to attachment ! Please give me some idear. And I can boot and auto login successful with sata boot, use the same job.yaml file! My job 454 : device_type: amberwing_rep1 job_name: amberwing_rep_nfs priority: medium visibility: public metadata: docs-filename: amberwing_rep_nfs timeouts: job: minutes: 300 action: minutes: 200 connection: minutes: 100 actions: - deploy: to: tftp kernel: url: http://swlab004/centos7/iso20171026-0/images/pxeboot/vmlinuz type: zimage ramdisk: url: http://swlab004/centos7/iso20171026-0/images/pxeboot/initrd.img compression: xz install_overlay: false nfsrootfs: url: http://autotest002/tmp/rootfs_centos.tar.gz install_overlay: true preseed: url: http://swlab004/centos7/anaconda-ks_1026.cfg os: centos timeout: minutes: 5 - boot: timeout: minutes: 200 connection: serial method: uefi-menu auto_login: login_prompt: '.* login:' username: root password_prompt: 'Password:' password: root commands: nfs_boot prompts: - 'Last login: .*' - '[root@.* .*]#' parameters: shutdown-message: "reboot: Restarting system" - test: timeout: minutes: 50 definitions: - repository: metadata: format: Lava-Test Test Definition 1.0 name: smoke-tests-basic description: "Basic system test command for Linaro Ubuntu images. The test runs basic commands like pwd, uname, vmstat, ifconfig, lscpu, lsusb and lsb_release." maintainer: - hongyu.xu(a)hxt-semitech.com os: - centos scope: - functional devices: - amberwing_rep-022 run: steps: - echo "test1a:" "pass" from: inline name: smoke-tests1 path: inline/smoke-tests.yaml 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.

7 years, 7 months

Migrating scheduling into lava-master

by Neil Williams

LAVA requires a range of singleton daemon processes to schedule, organise, publish and log the test job operations. 2017.12 will be retiring the lava-server daemon and the /var/log/lava-server/lava-scheduler.log, moving those operations into the lava-master daemon and the /var/log/lava-server/lava-master.log. This is one of the steps in the removal of V1. This leads a substantial change to how admins approach an instance running 2017.12 or later. When jobs don't appear to be running for some reason, the default action is to check /var/log/lava-server/lava-scheduler.log - once the instance is running 2017.12 or later, admins need to remember that it is correct for: * /var/log/lava-server/lava-scheduler.log to be empty * the status of the lava-server daemon to be active (exited) * the lava-server service to not restart At some point after 2017.12 has been running, admins can choose to archive or purge /var/log/lava-server/lava-scheduler.log* and / or disable the lava-server service using systemctl. The scheduler from 2017.12 onwards will consist of: * /var/log/lava-server/lava-master.log * /var/log/lava-server/lava-logs.log * the status of the lava-master daemon will be active (running) * the lava-master service will restart when admins request it. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 7 months

Fitting the LAVA overlay into an Android rootfs

by Steve McIntyre

[ Related-ish to the discussion in the "Fastboot - Android boot image apply-overlay" thread, but also slightly different so I'm starting a new discussion here... ] Hi folks, We were just discussing in IRC about potential problems with Android images in LAVA, in terms of fitting the overlay. Ideally, the Android builds would have a rootfs configured to be as small as possible - it's automatically resized to fit the available space at first boot, and leaving space otherwise is inefficient. However, if we're going to add the LAVA test overlay into the rootfs, space needs to be left for it to fit. That's not *necessarily* a problem, except that at build time the Android builds don't know how much space we're going to need! This leads to a bit of a chicken-and-eff problem. Anibal has already hacked around this a little bit as a workaround in a job definition - see https://validation.linaro.org/scheduler/job/1652299/definition#defline92 In the lxc, he's converting and expanding the rootfs image to make more space, then converting back ready for flashing. This is still quite hacky - there's still no information available there about the size of the LAVA overlay. It might fit now, but what happens if there's a new LAVA version next month with (hypothetically) a much bigger overlay? So, I'm thinking about a better way to do things here, in 2 parts: 1 .At the point when we apply the overlay, we know roughly how big it is and we could do the resizing of the image to fit directly without needing this guesswork. It's a relatively easy thing to do. 2. [Optionally] If we end up growing the rootfs image ourselves, it *might* end up overflowing the size available when we come to flash things, but "fastboot flash" will check this and abort. I even suggested that (to fail more quickly) we could parse the GPT partition table for size ourselves, but Nicolas pointed out that not all jobs will necessarily have such a partition table. Instead, *maybe* we could include a "maximum rootfs size" parameter somewhere if we care. Otherwise, just rely on fastboot doing the right thing. Does this sound sensible? Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

7 years, 7 months

Progress on LAVA-1133

by Neil Williams

LAVA: base-uboot: should not always pass console= https://projects.linaro.org/browse/LAVA-1133 Changes have now been made in review https://review.linaro.org/22540 This is one of the changes which is being migrated from the old bugzilla to the lava-users mailing list, so there is no current thread on this list for this topic. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 7 months

Fastboot - Android boot image apply-overlay

by Anibal Limon

Hi, I'm trying to apply-overlay (test tarball) to a ramdisk inside Android boot image , the image contains the kernel (zImage), ramdiisk (initrd.img) and a config file (bootimg.cfg). The Android boot image can be modified using abootimg, for example: $ abootimg -x boot.img $ abootimg-extract-unpack-initrd $ tar -xvzf overlay-5.2.4.tgz -C ramdisk $ abootimg-extract-pack-initrd $ abootimg -u boot.img -r init.rd Currently i can execute a test shell into LXC to make the extraction of the boot image [1][2], the issue i have is that the test overlay tarball (for example: overlay-5.2.4.tgz), isn't available because the creation is handled after the LXC pipeline by deploy action to the target device [3][4]. Any feedback would be appreciate. Best regards, Anibal [1] https://staging.validation.linaro.org/scheduler/job/196031/definition#defli… [2] https://staging.validation.linaro.org/scheduler/job/196031 [3] https://staging.validation.linaro.org/scheduler/job/196031/definition#defli… [4] https://git.linaro.org/lava/lava-dispatcher.git/tree/lava_dispatcher/action…

7 years, 7 months

← Newer
1
...
74
75
76
77
78
79
80
...
93
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users