lava-users

lava-users@lists.lavasoftware.org

1 participants
943 discussions

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

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.

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

8 years, 3 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.

8 years, 3 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/

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

8 years, 3 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/

8 years, 3 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…

8 years, 4 months

error while executing LAVA power on script

by Philippe BEGNIC

Hello Lava team, We have implemented new scripts to support flashing in our "power on" script. This script manage the PDU, boot pins configuration of the board and an external ST flasher. At the beginning of the job, the "power on" script is launched. Then I got the following error message <line way too long ...> . This cause the execution script to be interrupted, but the job is not interrupted and can continue without flashing the board. I do not have any additional logs regarding this error on the LAVA web interface. Our power on script is composed of several scripts that are "chained", script power on call another script, that call another one. Do you have an idea about this error ? Details concerning our configuration : * we use LAVA V2 ( version 06/2017 ). * our jobs are pipelined jobs ( LAVA V2) * Lava server // dispatcher are installed through dockers. BR Philippe

8 years, 4 months

Moving to systemd

by Neil Williams

LAVA, until now, has packaged SysVinit files to manage the various daemons but there have been longstanding problems with log rotation and the need to carry redundant code to manage the daemonize process for python scripts. This has allowed instances to support both SysVinit and systemd because systemd automatically converts the SysVinit files to systemd service files. Now that V1 has been removed, it has become possible and advantageous to drop SysVinit support and move to only systemd support. This is expected to mean that lava-dispatcher (and therefore lava-server) will depend on systemd-sysv, i.e. systemd needs to be the init system to be able to start the daemons upon which LAVA relies. A default install of Debian Jessie and Stretch already defaults to using systemd as the init system, so this does not necessarily involve any changes. If there are questions or issues with this, please reply to the lava-users mailing list. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

8 years, 4 months

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users