linaro-validation

linaro-validation@lists.linaro.org

818 discussions

Freezing support for LAVA on Ubuntu Trusty 14.04LTS

by Neil Williams

See also: https://lists.linaro.org/pipermail/lava-announce/2015-November/000002.html which was also sent to these lists (except linaro-dev). So far, nobody has come forward as a Trusty user. The only Trusty instance of which we are aware is already due to migrate to Debian Jessie. The LAVA software team are now applying updates which will freeze LAVA software support for Ubuntu Trusty at 2015.9 for lava-dispatcher and 2015.9.post1 for lava-server due to the complexities of supporting both django1.6 and the current django1.7 in Jessie and django1.8, possibly django1.9 by the time Debian Stretch is released. The last packages for Ubuntu Trusty 14.04LTS will be: lava-server 2015.9.post1 lava-dispatcher 2015.9 Once these changes are applied, the Debian packaging used to build future versions of LAVA packages will prevent builds against django1.6 and prevent installation if django1.6 is found, in order to prevent database corruption. This means that Trusty users will not be able to use the results of the dispatcher refactoring. Ubuntu Xenial Xerus - which is planned to be the 16.04LTS in April 2016 - is expected to pick up LAVA software releases from Debian up until the 2016.1 release (possibly 2016.2) and is also expected to be using django1.8. The next Debian stable release (Stretch), for which no date has yet been set, may use django1.9. Initial attempts at migrating a test instance from Trusty to django1.7 did not go well and the migration from Trusty to Xenial cannot be supported by the LAVA software team - the recommendation is to go directly from 2015.9 on Trusty to the same version available for Debian Jessie but there will still be work to be done to prepare and implement the migration which will be instance-dependent. Documentation is being added to assist with this migration but there will remain risks of data loss which will need to be managed for each instance. It is imperative that anyone using Trusty has an up to date backup of the postgresql database dump before considering any migration. If the existing data is to be dropped, a new install on Debian Jessie is recommended. It is not possible for the LAVA software team to support all versions of django from 1.6 to 1.9 - particular problems are known when going from django1.6 to django1.7 as the methods to migrate the lava-server database changed fundamentally in django1.7. Notes are being added to the documentation on the trusty branch based on 2015.9 to be released within lava-server 2015.9.post1 and to the documentation in the master branch (which will go into 2015.12). All future builds of LAVA software will now be made and uploaded only to Debian and releases.linaro.org. So far, nobody has come forward who is willing to maintain packaging for LAVA software on any distribution other than Debian. As the refactoring proceeds, we expect that it will become easier to package LAVA for other distributions but the migration to the refactoring must be complete first. Everyone interested in or using LAVA is encouraged to subscribe to the lava-announce mailing list which is low volume and only used for substantial changes like this. https://lists.linaro.org/mailman/listinfo/lava-announce See also https://validation.linaro.org/static/docs/support.html -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

10 years

LAVA job definition - git and password

by Bartosz Ziółek

Hi, How can I define git-repo with password and login field in job file? For example: { "command": "lava_test_shell", "parameters": { "testdef_repos": [ { "git-repo": "http://git.mpicosys.com/scm/git/lava-test-deployment", "parameters": { "BRANCH": "master", "LOGIN": "bartosz.ziolek", "PASSWORD" : "topsecretpass" }, "testdef": "test_example_1.yaml" } ], "timeout": 900 } }, Pozdrawiam / Kind regards Bartosz Ziółek Software Engineer MpicoSys Embedded Pico Systems Sp. z o.o. Pomeranian Science and Technology Park al. Zwycięstwa 96/98, 81-451 Gdynia, Poland T: +48 58 766 49 90 ext. 84 E: bartosz.ziolek(a)mpicosys.com W: http://www.mpicosys.com/

10 years

Calling all Trusty users of LAVA

by Neil Williams

This is a call to *all* users of LAVA on Trusty - please let us know who you are, what you're needs are and whether you are able to migrate to Debian Jessie instead of going from Trusty 14.04LTS to Xenial Xerus 16.04LTS. If you are using LAVA on any release of Ubuntu older than Trusty, the only advice from the LAVA team is to immediately migrate to Debian Jessie. If you are using LAVA on Wily Werewolf or Vivid Vervet, you should also consider testing the migration to Xenial and comparing with a migration to Debian Jessie, as below. LAVA is looking at a fix for the 2015.9 release but Django1.9 is in beta release already. There are issues with django1.8 which are in development. Currently, we are proposing that this update will be applied to 2015.9 and made into a frozen release. The master branch of LAVA will continue to develop and will need to use more features only available in Django1.7 and later. Documentation relating to installing Trusty would then be deprecated and removed in subsequent releases from the master branch. Equally, future database migrations on the master branch would no longer provide south support, using the django migration support provided by django1.7 and later. So these releases would not be built for Trusty - leaving only the frozen branch. Due to the complexity of supporting django1.6, it is unlikely that updates will be available for the frozen branch once this happens.. The changes in the lava-server due to the ongoing refactoring will mean that users of Trusty will be unable to migrate to pipeline support until the server has also been migrated to Xenial 16.04LTS. In addition to this, there is concern that migrating from Trusty and django1.6 all the way to django1.8 or possibly django1.9 in Ubuntu Xenial 16.04LTS is going to be problematic and the LAVA team will be unable to assist in most cases. The alternative is for someone with a reasonably complex lab running Ubuntu to take up a role as tester of the frozen branch *and* responsibility for patches which can maintain trusty support and migration to Xenial 16.04LTS. The problem then will be that it will be a very large transition when 16.04LTS actually becomes available - only for the same lag to start all over again. I'm unsure when Xenial will close the window for migrations from Debian into Xenial - I expect that the 2015.12 release of LAVA will migrate, I expect that 2016.1 will migrate too but I cannot be sure about 2016.2 or 2016.3. That migration is completely outside the control of the LAVA software team. https://launchpad.net/ubuntu/xenial/+source/lava-server Everyone considering staying on Ubuntu is advised to try a migration to Xenial *now* - in a VM, with and without a recent backup of your database and logs. Xenial currently has 2015.11. Also compare with a migration to Debian Jessie by dumping and reimporting the database. In each case, ensure that the permissions on /var/lib/lava-server and sub-directories are retained from the original. Please talk to us and test out what you are going to do. https://validation.linaro.org/static/docs/support.html -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

10 years

Skipping 2015.11 availability on Trusty

by Neil Williams

It has become impractical to maintain support for the latest production releases on Ubuntu Trusty 14.04LTS due to behaviour required by the server side changes needed by the dispatcher refactoring. These are important changes and are impractical to backport to the version of python-django available in Trusty. I have tried working around the issues but it involves pulling more dependencies from Jessie or Vivid and in my tests, the existing installation became confused and failed to install due to problems with the database migrations. The LAVA software team do not have the resources to maintain backports of the complete dependency chain in Ubuntu, it is a much more manageable set in Debian Jessie (where the same migration went without issues on multiple machines). The changes in 2015.11 are almost exclusively related to the dispatcher refactoring and therefore there is expected to be limited impact on current installations on Trusty. For the next release, we will investigate code changes which omit the new support for Trusty builds but this will have the effect of preventing those installs from working with the pipeline and the new YAML job submissions. The documentation for Trusty will also be updated, if necessary as a hotfix to 2015.9 just for Trusty. If the code changes do not work cleanly, then the current 2015.9 (and the documentation hotfix to follow) would become the last LAVA releases for Ubuntu Trusty 14.04LTS. Users of Ubuntu Trusty 14.04LTS are reminded that a new LTS is due for release in April 2016 but that the LAVA software team are not using Trusty any longer. Any issues with the migration from Trusty to the new LTS are outside of our control. Migrating an instance from Ubuntu to Debian would involve dumping and re-importing the database - bear in mind that Trusty has postgres9.3 and Jessie has 9.4, so care will be needed to migrate the postgresql cluster correctly - there is documentation for that migration in the lava-server docs. It is not recommended to attempt to migrate the OS itself from Ubuntu to Debian (or vice-versa), a reinstall is a better option, so make a backup and ensure that the backup works. -- Neil Williams ============= http://www.linux.codehelp.co.uk/

10 years

FYI LAVA in stretch or unstable & unit tests

by Neil Williams

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802677 This appears to only affect the unit tests in lava-server but can be confusing as the output makes it look like something more serious within django. It's not, it's in python-testtools. The solution is to downgrade python-testtools (use the version in Jessie as outlined in the bug report above). When this bug report is closed, the package can be upgraded again. -- Neil Williams ============= http://www.linux.codehelp.co.uk/

10 years, 1 month

Does deploy_linaro_kernel have a known issue of missing to setup network on fast model targets?

by Basil Eljuse

Hello All, Before I report this as a bug thought to check if this is a known issue or not. Do confirm. We were trying to use lava-test-shell in running pm-qa on AEMv8 and CortexA57xA53 model variants. Based on what we have run we could see that if we use boot_linaro_image as the image deployment mode, there are no issues, LAVA is able to run the lava-test-shell successfully. However when we use boot_linaro_kernel as the image deployment mode, we see lava-test-shell fails due to network being reported as 'down'. Is this something known already? Or should I raise a bug report? Details:: deploy_linaro_image - Attaching the exact test def for reference. Here we use the hwpack and a modified rootfs (added test suite in it) and then uses boot_linaro_image and provides some uefi boot commands through 'boot_cmds' and override some model flags using the 'options' parameter. deploy_linaro_kernel - Attaching the exact test def for reference Here we use 'boot_image' with commands through boot_cmds and model flags using 'sim_options' parameter. In the sim options even if we give "-C bp.hostbridge.interfaceName=anything", "-C bp.smsc_91c111.enabled=true", "-C bp.smsc_91c111.mac_address=00:11:22:33:44:53" It don't seem to get networking setup correctly. We could see the initial boot successful and as part of doing the lava-test-shell execution, the pre-requisite of network being up fails! Section 70<http://ssg-sw.cambridge.arm.com/lava/scheduler/job/4541/log_file#L_70> 70.0<http://ssg-sw.cambridge.arm.com/lava/scheduler/job/4541/log_file#L_70_0> linaro-test [rc=0]# <LAVA_DISPATCHER>2015-10-06 03:26:22 PM DEBUG: send (delay_ms=0): cd /tmp 70.1<http://ssg-sw.cambridge.arm.com/lava/scheduler/job/4541/log_file#L_70_1> <LAVA_DISPATCHER>2015-10-06 03:26:22 PM DEBUG: send (delay_ms=0): Section 71<http://ssg-sw.cambridge.arm.com/lava/scheduler/job/4541/log_file#L_71> 71.0<http://ssg-sw.cambridge.arm.com/lava/scheduler/job/4541/log_file#L_71_0> Section 72<http://ssg-sw.cambridge.arm.com/lava/scheduler/job/4541/log_file#L_72> 72.0<http://ssg-sw.cambridge.arm.com/lava/scheduler/job/4541/log_file#L_72_0> <LAVA_DISPATCHER>2015-10-06 03:26:22 PM DEBUG: expect (600): 'linaro-test \[rc=(\d+)\]# ' Section 73<http://ssg-sw.cambridge.arm.com/lava/scheduler/job/4541/log_file#L_73> 73.0<http://ssg-sw.cambridge.arm.com/lava/scheduler/job/4541/log_file#L_73_0> cd /tmp Section 74<http://ssg-sw.cambridge.arm.com/lava/scheduler/job/4541/log_file#L_74> 74.0<http://ssg-sw.cambridge.arm.com/lava/scheduler/job/4541/log_file#L_74_0> linaro-test [rc=0]# <LAVA_DISPATCHER>2015-10-06 03:26:23 PM INFO: Waiting for network to come up 74.1<http://ssg-sw.cambridge.arm.com/lava/scheduler/job/4541/log_file#L_74_1> <LAVA_DISPATCHER>2015-10-06 03:26:23 PM DEBUG: send (delay_ms=0): LC_ALL=C ping -W4 -c1 10.1.99.203 74.2<http://ssg-sw.cambridge.arm.com/lava/scheduler/job/4541/log_file#L_74_2> <LAVA_DISPATCHER>2015-10-06 03:26:24 PM DEBUG: send (delay_ms=0): Section 75<http://ssg-sw.cambridge.arm.com/lava/scheduler/job/4541/log_file#L_75> 75.0<http://ssg-sw.cambridge.arm.com/lava/scheduler/job/4541/log_file#L_75_0> Section 76<http://ssg-sw.cambridge.arm.com/lava/scheduler/job/4541/log_file#L_76> 76.0<http://ssg-sw.cambridge.arm.com/lava/scheduler/job/4541/log_file#L_76_0> <LAVA_DISPATCHER>2015-10-06 03:26:24 PM DEBUG: expect (60): '['1 received|1 packets received', '0 received|0 packets received', 'Network is unreachable']' Section 77<http://ssg-sw.cambridge.arm.com/lava/scheduler/job/4541/log_file#L_77> 77.0<http://ssg-sw.cambridge.arm.com/lava/scheduler/job/4541/log_file#L_77_0> LC_ALL=C ping -W4 -c1 10.1.99.203 77.1<http://ssg-sw.cambridge.arm.com/lava/scheduler/job/4541/log_file#L_77_1> PING 10.1.99.203 (10.1.99.203): 56 data bytes 77.2<http://ssg-sw.cambridge.arm.com/lava/scheduler/job/4541/log_file#L_77_2> ping: sendto: Network is unreachable Note: Attaching only the test definitions in the email, let me know if full logs from the successful and failed runs needs to be shared, or I do that via big report if it is confirmed so. Thanks Basil Eljuse... -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

10 years, 1 month

Android multinode test definitions update

by Milosz Wasilewski

Hi, I merged CTS and lava-android-test target test defintions into a single YAML file. It can be (in most cases) used as target side for any Android multinode test. In this case test are executed from host side using adb. Host test definitions will be different for each side, but target side can be unified. Here is a patch for this fix: https://review.linaro.org/#/c/8031/ If you have any concerns, please feel free to comment. This patch makes the following files obsolete: android/cts-target.yaml android/lava-android-test-target.yaml I will update all test plan templates to use the new definition. Obsolete files will be removed in 15.11 release. Best Regards, milosz

10 years, 1 month

New lists and upcoming changes

by Neil Williams

https://lists.linaro.org/pipermail/lava-announce/2015-September/000000.html The lava-announce mailing list has existed for some time but after discussions at SFO15, the list has taken on a particular purpose - to raise awareness of the upcoming refactoring, to announce when significant improvements are made in the refactoring and later to announce when parts of the current dispatcher support are to begin migrating to the new codebase. There is a new list for users to discuss problems (where users includes test writers and admins of instances outside Linaro) called lava-users. [0] This list is to be renamed to lava-devel for discussions directly relating to the refactoring, new support, use cases and discussions about the actual migrations themselves. linaro-validation is to remain as an alias, so your current email filtering will continue. At some point during the migration, the alias for linaro-validation pointing at lava-devel will be dropped. That will be announced here and on the lava-announce mailing list. The division between lava-users and lava-devel is a guidance, however, as the migration gets under way, it is likely that this list will become dominated by discussions of how to adapt existing tests to the new methods rather than support or discussion of deployments using the current dispatcher. lava-announce is recommended for anyone using LAVA in any way, especially admins. It will carry announcements from the LAVA software team on new support in the refactoring, new use case implementations, details of upcoming migrations and other announcements. The Reply-To of lava-announce is set to this list, so discussion of announcements will happen here. These new mailing lists will be included in the documentation included in next release of the LAVA software (2015.10). Documentation of the new code is already in the master branch of lava-server and installed via the lava-server-doc package and the initial code for the refactoring is being developed in parallel with the current code. This list will be used to announce when the refactoring codebase is ready for admins to begin migrating tests and test writers to the new code and methods - currently, the new dispatcher is developer only. At SFO15, there was also an update on the state of the refactoring. [1] lava-announce will continue to be a low volume list. Reply-To has been set to this list (transparently migrating to lava-devel once the linaro-validation alias is in place). The LAVA developers would ask that everyone running LAVA would subscribe to at least the lava-announce mailing list, to help with the migration to the new support. Videos will be available for most meetings at SFO15 in due course. The slides are already available. [0] https://sfo15.pathable.com/meetings/302656 [1] https://sfo15.pathable.com/meetings/303074 -- Neil Williams ============= Tech Lead LAVA Software http://www.linux.codehelp.co.uk/

10 years, 1 month

LAVA juno-r1 support: don't touch the firmware

by Kevin Hilman

How to tell LAVA to not try an update the firmware my juno-r1 board? The default juno device type points to a tarball[1] it uses to update/replace the juno firmware, unfortunately, that tarball seems to only be configured for Juno, not the juno R1. After and unpack/flash/reboot, the juno board fails to boot with: ERROR: File not found \MB\HBI0262C\board.txt Note the 'C' in the board name HBI0262C, whereas the tarball only contains HBI0262B. I have flashed working firmware onto my Juno R1 and would like LAVA to leave it alone. Is there a way to do that? Kevin [1] http://images.validation.linaro.org/juno/board-recovery-image.tgz

10 years, 2 months

lava device-type overrides in device file

by Kevin Hilman

Hello, How does one do a partial-override of boot_cmds from the device file? I have a panda and want to use the shipping device-type, except that I need to 'setenv usbethaddr ...' before any of the other commands. I can fix this by copy/paste'ing the whole boot_cmds_ramdisk section from the device-type into my device file, but what I really want to do to is just use the ones from the device-type with minor modifications (and ensure I get updates to the production device-type when they happen) Something like this (assuming python ConfigParser style formatting) in the device file would be useful: boot_cmds_ramdisk = setenv usbethaddr <MAC addr>, %(boot_cmds_ramdisk)s Is there a good way of doing that? Kevin

10 years, 2 months

← Newer
1
...
4
5
6
7
8
9
10
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation