lava-users

lava-users@lists.lavasoftware.org

1 participants
941 discussions

by Milosz Wasilewski

Hi, I'm trying to change the way LAVA searches for and passes USB devices to LXC containers. Current code depends on arbitrary variables present in the static_info dictionary that is part of the device dictionary. This seems to be a problem for some users [1]. So the proposal was made to get rid of the arbitrary variables entirely and use udev variables (starting with ID_). The change was pretty simple to implement but when I started changing the docs I realized there were other classes of devices supported with static_info. Docs list ACME Cape that can be connected over LAN [2]. I'm not aware of any users of this code but I don't want to break the feature if there is anyone using it. So if you're users of LAVA who connect ACME Cape using static_info please reply to this thread. If I don't hear any replies I will remove this support. [1] https://git.lavasoftware.org/lava/lava/issues/335 [2] https://github.com/ARM-software/lisa/wiki/Energy-Meters-Requirements#user-c… Best Regards, milosz

6 years, 2 months

Re: [Lava-users] Deploy RTOS Based Application Image

by Remi Duraffort

What kind of command do you run to flash over usb? Le jeu. 28 nov. 2019 à 13:26, dhanu msys <dhanuskd.palnati(a)gmail.com> a écrit : > Hi Remi, > > We were flashing through USB otg cable. > > USB deploy method supported by lava right? > > Regards, > Dhanunjaya > > On Thu, Nov 28, 2019, 17:52 Remi Duraffort <remi.duraffort(a)linaro.org> > wrote: > >> Hello, >> >> you should give more information if you want to have a proper answer. >> >> How do you flash the board? is it fully automatic? >> Is this method already supported by LAVA? >> >> >> Rgds >> >> Le jeu. 28 nov. 2019 à 07:48, dhanu msys <dhanuskd.palnati(a)gmail.com> a >> écrit : >> >>> Hi Team, >>> >>> How can i deploy RTOS based Application Image on target. >>> >>> Notes : >>> Target HW : STM32F429I-DISC1. >>> RTOS : Open source RTOS >>> Application Image (RTOS + Application specific code). >>> >>> We are able to flash the Developed Application Firmware (.out/.bin) >>> through IAR IDE via USB, so we are in plan to make use of LAVA and run test >>> applications automatically. >>> >>> So , Can you please provide some references to deploy this test >>> scenarios in LAVA. >>> >>> Thanks & Regards, >>> Dhanunjaya. P >>> _______________________________________________ >>> Lava-users mailing list >>> Lava-users(a)lists.lavasoftware.org >>> https://lists.lavasoftware.org/mailman/listinfo/lava-users >> >> >> >> -- >> Rémi Duraffort >> LAVA Architect >> Linaro >> > -- Rémi Duraffort LAVA Architect Linaro

6 years, 2 months

RFC: when to drop stretch support?

by Remi Duraffort

Hello everyone, Summary: We would like to drop the support for stretch in the (near) future. Details: Currently lava-server and lava-dispatcher are supported on both debian stretch and debian buster. Since LAVA 2019.11, the lava-server and lava-dispatcher docker images are based on debian buster and not stretch. Unittest are still running on stretch, buster and bullseye but integration tests (lavafed and meta-lava mainly) are using the docker container so they run only on buster. Dropping the support for stretch will: * simplify testing * allow to use more recent version of python and django * remove some issues with old dependencies in stretch But before dropping the support we need to ensure that users/admins had some time to migrate to buster or to docker-based installations. In an ideal world, I would drop the support for stretch on the 1st of January 2020. But please answer to this mail so we can device of the right date all together. Thanks -- Rémi Duraffort LAVA Architect Linaro

6 years, 2 months

Value for connections lava-test-shell timeouts.

by Larry Shen

Hi, there, We can set lava-test-shell timeouts in test job like next: timeouts: connections: lava-test-shell: minutes: 1 My question is: what's the suitable value for this? Any performance consideration for this value, or in one word, what if I set it as small as possible?

6 years, 2 months

Interactive test action unreliable behavior

by Philippe Mazet

Hi All, I am experimenting with the interactive test action, but cannot get it to work reliably. I tried to replicate what is documented here: https://docs.lavasoftware.org/lava/interactive.html#writing-tests-interacti… I also took as example a job mentioned previously on this mailing list: https://validation.linaro.org/scheduler/job/1925569/definition But If I come down to the simplest uboot test job (yaml + log attached), I still see false verdicts. I first set 2 variables in uboot. Then I print them, and verify if the output contains the expected string. Only the first case behaves as expected: "fail-expected-1". All following tests go wrong: Test case "fail-expected-2" fails, but for a wrong reason: "Matched a prompt (was expecting a success): '=> '" And remaining test cases also show a wrong verdict because of this. Including the last 2 TCs which are supposed to pass, but are marked as failed. I also tested in Linux and on a different platform, and the behavior is the same. Am I missing something with the syntax? Or with serial console settings? Thanks a lot for your help, Philippe Mazet

6 years, 2 months

lxc creation fails with multiple containers

by Diego Russo

Hello, Sometimes LAVA slaves end up in a funky state where all jobs will be failing for the lxc-creation. This is an just a section of the pstree but actually the machine is not doing anything. No CPU/IO/memory usage at all. |-lxc-ubuntu,26488 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/mbl-rpi3-healthcheck-lxc-86216 --name=mbl-rpi3-healthcheck-lxc-86216 --rootfs=/var/lib/lxc/mbl-rpi3-healthcheck-lxc-86216/rootfs --release xenial ... | `-lxc-ubuntu,26495 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/mbl-rpi3-healthcheck-lxc-86216 --name=mbl-rpi3-healthcheck-lxc-86216 --rootfs=/var/lib/lxc/mbl-rpi3-healthcheck-lxc-86216/rootfs --release xenial ... | `-flock,26496 -x 9 |-lxc-ubuntu,29367 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/cellular-wifi-lxc-85573 --name=cellular-wifi-lxc-85573 --rootfs=/var/lib/lxc/cellular-wifi-lxc-85573/rootfs --release xenial --packages ... | `-lxc-ubuntu,29374 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/cellular-wifi-lxc-85573 --name=cellular-wifi-lxc-85573 --rootfs=/var/lib/lxc/cellular-wifi-lxc-85573/rootfs --release xenial --packages ... | `-rsync,29590 -Ha /var/cache/lxc/xenial/rootfs-amd64/ /var/lib/lxc/cellular-wifi-lxc-85573/rootfs/ | `-rsync,29593 -Ha /var/cache/lxc/xenial/rootfs-amd64/ /var/lib/lxc/cellular-wifi-lxc-85573/rootfs/ | `-rsync,29594 -Ha /var/cache/lxc/xenial/rootfs-amd64/ /var/lib/lxc/cellular-wifi-lxc-85573/rootfs/ |-lxc-ubuntu,30173 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/multi_component-image-update-pelion-lxc-85584 --name=multi_component-image-update-pelion-lxc-85584... | `-lxc-ubuntu,30186 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/multi_component-image-update-pelion-lxc-85584 --name=multi_component-image-update-pelion-lxc-85584... | `-flock,30187 -x 9 |-lxc-ubuntu,30226 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/helloworld-update-lxc-85537 --name=helloworld-update-lxc-85537 --rootfs=/var/lib/lxc/helloworld-update-lxc-85537/rootfs --release xenial --packages ... | `-lxc-ubuntu,30233 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/helloworld-update-lxc-85537 --name=helloworld-update-lxc-85537 --rootfs=/var/lib/lxc/helloworld-update-lxc-85537/rootfs --release xenial --packages ... | `-flock,30234 -x 9 |-lxc-ubuntu,30800 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/rootfs-image-update-mbl-cli-lxc-85588 --name=rootfs-image-update-mbl-cli-lxc-85588 --rootfs=/var/lib/lxc/rootfs-image-update-mbl-cli-lxc-85588/rootfs ... | `-lxc-ubuntu,30807 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/rootfs-image-update-mbl-cli-lxc-85588 --name=rootfs-image-update-mbl-cli-lxc-85588 --rootfs=/var/lib/lxc/rootfs-image-update-mbl-cli-lxc-85588/rootfs ... | `-flock,30808 -x 9 |-lxc-ubuntu,30837 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/mbl-cli-basic-commands-lxc-85540 --name=mbl-cli-basic-commands-lxc-85540 --rootfs=/var/lib/lxc/mbl-cli-basic-commands-lxc-85540/rootfs --release xenial ... | `-lxc-ubuntu,30844 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/mbl-cli-basic-commands-lxc-85540 --name=mbl-cli-basic-commands-lxc-85540 --rootfs=/var/lib/lxc/mbl-cli-basic-commands-lxc-85540/rootfs --release xenial ... | `-flock,30845 -x 9 |-lxc-ubuntu,31697 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/wifi-access-lxc-85591 --name=wifi-access-lxc-85591 --rootfs=/var/lib/lxc/wifi-access-lxc-85591/rootfs --release xenial --packages systemd,systemd-sysv | `-lxc-ubuntu,31704 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/wifi-access-lxc-85591 --name=wifi-access-lxc-85591 --rootfs=/var/lib/lxc/wifi-access-lxc-85591/rootfs --release xenial --packages systemd,systemd-sysv | `-flock,31705 -x 9 |-lxc-ubuntu,31800 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/multi_component-image-update-mbl-cli-lxc-85542 --name=multi_component-image-update-mbl-cli-lxc-85542... | `-lxc-ubuntu,31807 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/multi_component-image-update-mbl-cli-lxc-85542 --name=multi_component-image-update-mbl-cli-lxc-85542... | `-flock,31808 -x 9 I have tens and tens of this processes. LAVA jobs have failed but lxc processes are still there. It seems to be some sort of deadlock in the lxc world. I'm on Debian stretch 9.8. It recently started with no apparent reason. Regards -- Diego Russo | Staff Software Engineer | Mbed Linux OS ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom http://www.diegor.co.uk - https://os.mbed.com/docs/mbed-linux-os/ 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.

6 years, 2 months

Deploy RTOS Based Application Image

by dhanu msys

Hi Team, How can i deploy RTOS based Application Image on target. Notes : Target HW : STM32F429I-DISC1. RTOS : Open source RTOS Application Image (RTOS + Application specific code). We are able to flash the Developed Application Firmware (.out/.bin) through IAR IDE via USB, so we are in plan to make use of LAVA and run test applications automatically. So , Can you please provide some references to deploy this test scenarios in LAVA. Thanks & Regards, Dhanunjaya. P

6 years, 2 months

Re: [Lava-users] None of the deployment strategies accepted your deployment parameters

by dhanu msys

Hi Milosz, Thanks for providing the document references. I will try my level best. Thanks & Regards, Dhanunjaya On Tue, Nov 12, 2019, 20:36 Milosz Wasilewski <milosz.wasilewski(a)linaro.org> wrote: > I'll defer you to the docs: > - boot commands: > https://master.lavasoftware.org/static/docs/v2/actions-boot.html#index-9 > - device type: > > https://master.lavasoftware.org/static/docs/v2/devicetypes.html#device-types > - u-boot bootloader: > https://master.lavasoftware.org/static/docs/v2/actions-boot.html#index-35 > > I didn't test tftp booting with this board, so I can't help. It should > work as this is supported in device type: > > https://git.lavasoftware.org/lava/lava/blob/master/etc/dispatcher-config/de… > > Good luck. > > milosz > > On Tue, 12 Nov 2019 at 13:59, dhanu msys <dhanuskd.palnati(a)gmail.com> > wrote: > > > > Hi Milosz, > > > > I was running tftp on my localhost & kept those uImage & dtb files in > the "tftpboot" repository. PFA. > > > > > > Thanks & Regards, > > Dhanunjaya. P > > > > > > On Tue, Nov 12, 2019 at 7:23 PM dhanu msys <dhanuskd.palnati(a)gmail.com> > wrote: > >> > >> Hi Milosz, > >> > >> Yes , I have booted my board manually using the tftp , here i have > attached those uImage & dtb images. PFA. > >> Once the device bootsup , through command prompt , i will set the > following commands. > >> > >> setenv ipaddr 192.168.1.201 > >> setenv gatewayip 192.168.1.200 > >> setenv serverip 192.168.1.200 > >> setenv netmask 255.255.255.0 > >> tftpboot 0xc2000000 uImage > >> tftpboot 0xc4000000 stm32mp157c-ev1.dtb > >> setenv bootargs 'root=/dev/mmcblk0p6 rootwait rw > console=ttySTM0,115200'bootm 0xc2000000 - 0xc4000000 > >> > >> Its basically ARM architecture based and bootloader "u-boot". > >> > >> Can you please suggest how i can deploy the tftp files through LAVA > test job ,what will be the url i need pass in the job definition ? > >> > >> Thanks & Regards, > >> Dhanunjaya. P > >> > >> > >> On Tue, Nov 12, 2019 at 7:07 PM Milosz Wasilewski < > milosz.wasilewski(a)linaro.org> wrote: > >>> > >>> Hmm, > >>> Do you know how tftp boot works? Loading 100M tarball into memory > >>> doesn't seem like a good idea. Which bootloader is running on your > >>> board? > >>> > >>> milosz > >>> > >>> On Tue, 12 Nov 2019 at 13:32, dhanu msys <dhanuskd.palnati(a)gmail.com> > wrote: > >>> > > >>> > Hi Milosz, > >>> > > >>> > As per earlier email , I am trying to boot the STM32mp157c-dk2 with > the tftp deploy method , but getting failed to have proper device > configuration. > >>> > > >>> > Here I have attached the device configuration , device template & > Job definition files. PFA. > >>> > > >>> > Please let me know how to get resolve the issue. > >>> > > >>> > Regards, > >>> > Dhanunjaya. P > >>> > > >>> > > >>> > On Tue, Nov 12, 2019 at 2:45 PM Milosz Wasilewski < > milosz.wasilewski(a)linaro.org> wrote: > >>> >> > >>> >> On Tue, 12 Nov 2019 at 08:14, dhanu msys < > dhanuskd.palnati(a)gmail.com> wrote: > >>> >> > > >>> >> > Hi Milosz, > >>> >> > > >>> >> > Currently eth008 was unavailable, Is there any possibility to > make use of Raspberry pi 4 as PDU to run power control commands on > STM32mp157c-dk2 ? > >>> >> > >>> >> Sure. Anything that can drive a relay will work. You will need to > >>> >> create a script that LAVA can call. Eth008 is a good choice for a > >>> >> bigger LAB where you need a lot of relays (these boards have > >>> >> configurable MAC addresses). If you need just one, than pick any > relay > >>> >> you can get on ebay and that will do the trick. > >>> >> > >>> >> milosz > >>> >> > >>> >> > > >>> >> > Thanks in advance. > >>> >> > > >>> >> > Regards, > >>> >> > Dhanunjaya. P > >>> >> > > >>> >> > > >>> >> > On Mon, Nov 11, 2019 at 5:36 PM dhanu msys < > dhanuskd.palnati(a)gmail.com> wrote: > >>> >> >> > >>> >> >> Hi Milosz, > >>> >> >> > >>> >> >> Thanks for the reply. > >>> >> >> > >>> >> >> I will try to get the eth008 if possible , otherwise i will try > to make use of TFTP or u-boot methods to run the test job on > STM32mp157c-dk2. > >>> >> >> > >>> >> >> Thanks & Regards, > >>> >> >> Dhanunjaya. P > >>> >> >> > >>> >> >> > >>> >> >> On Mon, Nov 11, 2019 at 4:57 PM Milosz Wasilewski < > milosz.wasilewski(a)linaro.org> wrote: > >>> >> >>> > >>> >> >>> On Mon, 11 Nov 2019 at 11:07, dhanu msys < > dhanuskd.palnati(a)gmail.com> wrote: > >>> >> >>> > > >>> >> >>> > Hi Milosz, > >>> >> >>> > > >>> >> >>> > Really Thanks for sharing the Information. > >>> >> >>> > > >>> >> >>> > I have basic question, we can't able to run any test job for > the STM32 without external hardware(PDU) ? > >>> >> >>> > > >>> >> >>> > Can you please share the device configuration , which helps > to run the test jobs without "ethernet controlled relay" for the STM32. > >>> >> >>> > >>> >> >>> > https://git.linaro.org/lava/lava-lab.git/tree/shared/lab-scripts/eth008_con… > >>> >> >>> > >>> >> >>> > > >>> >> >>> > As I requested earlier , is there any possibility to run the > STM32 specific jobs with any other deployment methods(tmpfs , tftp..etc). > >>> >> >>> > >>> >> >>> Our boards use EFI for booting and I never tried tftp with > that. You > >>> >> >>> might need grub EFI application for that. Alternatively you > might use > >>> >> >>> u-boot. I didn't try that either. > >>> >> >>> > >>> >> >>> milosz > >>> >> >>> > >>> >> >>> > > >>> >> >>> > Thanks & Regards, > >>> >> >>> > Dhanunjaya. P > >>> >> >>> > > >>> >> >>> > > >>> >> >>> > On Mon, Nov 11, 2019 at 4:19 PM Milosz Wasilewski < > milosz.wasilewski(a)linaro.org> wrote: > >>> >> >>> >> > >>> >> >>> >> Well, LAVA will try to switch the device into DFU mode for > deployment > >>> >> >>> >> step. These lines in the device dict do it: > >>> >> >>> >> '/usr/local/lab-scripts/eth008_control -a 172.27.19.27 -r 1 > -s on', > >>> >> >>> >> '/usr/local/lab-scripts/eth008_control -a 172.27.19.27 -r 2 > -s on', > >>> >> >>> >> Then it will power on the board: > >>> >> >>> >> '/usr/local/lab-scripts/snmp_pdu_control --hostname lngpdu01 > --command > >>> >> >>> >> on --port 3 --delay 20', > >>> >> >>> >> After that it will try to flash it using the > STM32_Programmer_CLI: > >>> >> >>> >> '/usr/local/bin/STM32_Programmer_CLI -c port=usb1 -w > {LAYOUT} -q', > >>> >> >>> >> Lastly it will power the board down and flip the dip > switches back: > >>> >> >>> >> '/usr/local/lab-scripts/snmp_pdu_control --hostname lngpdu01 > --command > >>> >> >>> >> off --port 3', > >>> >> >>> >> '/usr/local/lab-scripts/eth008_control -a 172.27.19.27 -r 1 > -s off', > >>> >> >>> >> '/usr/local/lab-scripts/eth008_control -a 172.27.19.27 -r 2 > -s off', > >>> >> >>> >> > >>> >> >>> >> So if you don't have HW moded board, this device dict won't > work for > >>> >> >>> >> you. Sources for the scripts are here: > >>> >> >>> >> > https://git.linaro.org/lava/lava-lab.git/tree/shared/lab-scripts > >>> >> >>> >> We're using pretty expensive HW in the LAB: > >>> >> >>> >> - managed APC PDUs: > >>> >> >>> >> > https://www.apc.com/shop/uk/en/products/Rack-PDU-Switched-1U-16A-208-230V-8… > >>> >> >>> >> (I couldn't find the exact models we have, they're > discontinued) > >>> >> >>> >> - ETH008 relay board: > https://www.robot-electronics.co.uk/htm/eth008tech.htm > >>> >> >>> >> > >>> >> >>> >> milosz > >>> >> >>> >> > >>> >> >>> >> On Mon, 11 Nov 2019 at 10:42, dhanu msys < > dhanuskd.palnati(a)gmail.com> wrote: > >>> >> >>> >> > > >>> >> >>> >> > Hi Milosz, > >>> >> >>> >> > > >>> >> >>> >> > No. > >>> >> >>> >> > Through Manual Setup , we are able to switch between the > modes. > >>> >> >>> >> > > >>> >> >>> >> > Here I have attached the kernel & dtb image for your > reference. PFA. > >>> >> >>> >> > > >>> >> >>> >> > Dhanunjaya. P > >>> >> >>> >> > > >>> >> >>> >> > > >>> >> >>> >> > On Mon, Nov 11, 2019 at 3:40 PM Milosz Wasilewski < > milosz.wasilewski(a)linaro.org> wrote: > >>> >> >>> >> >> > >>> >> >>> >> >> I think I forgot to ask key question when it comes to > this device: did > >>> >> >>> >> >> you do the HW mod to be able to switch between DFU and OS > boot modes > >>> >> >>> >> >> without manual step? > >>> >> >>> >> >> > >>> >> >>> >> >> milosz > >>> >> >>> >> >> > >>> >> >>> >> >> On Mon, 11 Nov 2019 at 10:01, dhanu msys < > dhanuskd.palnati(a)gmail.com> wrote: > >>> >> >>> >> >> > > >>> >> >>> >> >> > Hi Milosz, > >>> >> >>> >> >> > > >>> >> >>> >> >> > Thanks for reply. > >>> >> >>> >> >> > > >>> >> >>> >> >> > I am new to the LAVA usage. > >>> >> >>> >> >> > > >>> >> >>> >> >> > I have taken reference from the below link. > >>> >> >>> >> >> > > https://staging.validation.linaro.org/scheduler/device/staging-stm32mp157-0… > >>> >> >>> >> >> > > >>> >> >>> >> >> > Here I have attached the device_dictionary & device > configurations files, PFA. > >>> >> >>> >> >> > > >>> >> >>> >> >> > Note : I am not able to see the "lab-scripts" to have > power controlled commands in my local repository , is there any specific > package need to install in my localhost , can you please share the > lab-scripts to have pdu control and also please share the pdu device > details if required to connect with the hardware. > >>> >> >>> >> >> > > >>> >> >>> >> >> > Can you please share some references , which i can run > some jobs through any other deploy methods like "tmpfs , tftp " for > "STM32MP157C-DK2". > >>> >> >>> >> >> > > >>> >> >>> >> >> > Thanks & Regards, > >>> >> >>> >> >> > Dhanunjaya. P > >>> >> >>> >> >> > > >>> >> >>> >> >> > > >>> >> >>> >> >> > On Mon, Nov 11, 2019 at 2:59 PM Milosz Wasilewski < > milosz.wasilewski(a)linaro.org> wrote: > >>> >> >>> >> >> >> > >>> >> >>> >> >> >> Could you share your device dictionary? You might be > missing > >>> >> >>> >> >> >> flasher_deploy_commands. > >>> >> >>> >> >> >> > >>> >> >>> >> >> >> Please check here for reference: > >>> >> >>> >> >> >> > https://ledge.validation.linaro.org/scheduler/device/lng-stm32mp157-01/devi… > >>> >> >>> >> >> >> > >>> >> >>> >> >> >> milosz > >>> >> >>> >> >> >> > >>> >> >>> >> >> >> On Thu, 7 Nov 2019 at 07:48, dhanu msys < > dhanuskd.palnati(a)gmail.com> wrote: > >>> >> >>> >> >> >> > > >>> >> >>> >> >> >> > Hi Team, > >>> >> >>> >> >> >> > > >>> >> >>> >> >> >> > I am trying to run the test_jobs on the specific > device type "stm32mp1157c-dk2" , but its throwing an error message to > deploy "flasher" method in the deployment parameters. > >>> >> >>> >> >> >> > > >>> >> >>> >> >> >> > Here I have attached the screenshots for reference. > PFA. > >>> >> >>> >> >> >> > > >>> >> >>> >> >> >> > Thanks & Regards, > >>> >> >>> >> >> >> > Dhanunjaya. P > >>> >> >>> >> >> >> > _______________________________________________ > >>> >> >>> >> >> >> > Lava-users mailing list > >>> >> >>> >> >> >> > Lava-users(a)lists.lavasoftware.org > >>> >> >>> >> >> >> > > https://lists.lavasoftware.org/mailman/listinfo/lava-users >

6 years, 2 months

Re: [Lava-users] lxc creation fails with multiple containers

by Diego Russo

An update: as soon as I kll the rsync processes, all the lxc and flock processes get terminated. Before the killing I did try to create a lxc container from the command line but it was stuck. It continued after killing the rsync processes. How can I avoid this situation? Cheers -----Original Message----- From: Lava-users <lava-users-bounces(a)lists.lavasoftware.org> on behalf of Diego Russo <Diego.Russo(a)arm.com> Date: Tuesday, 26 November 2019 at 11:17 To: "lava-users(a)lists.lavasoftware.org" <lava-users(a)lists.lavasoftware.org> Subject: [Lava-users] lxc creation fails with multiple containers Hello, Sometimes LAVA slaves end up in a funky state where all jobs will be failing for the lxc-creation. This is an just a section of the pstree but actually the machine is not doing anything. No CPU/IO/memory usage at all. |-lxc-ubuntu,26488 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/mbl-rpi3-healthcheck-lxc-86216 --name=mbl-rpi3-healthcheck-lxc-86216 --rootfs=/var/lib/lxc/mbl-rpi3-healthcheck-lxc-86216/rootfs --release xenial ... | `-lxc-ubuntu,26495 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/mbl-rpi3-healthcheck-lxc-86216 --name=mbl-rpi3-healthcheck-lxc-86216 --rootfs=/var/lib/lxc/mbl-rpi3-healthcheck-lxc-86216/rootfs --release xenial ... | `-flock,26496 -x 9 |-lxc-ubuntu,29367 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/cellular-wifi-lxc-85573 --name=cellular-wifi-lxc-85573 --rootfs=/var/lib/lxc/cellular-wifi-lxc-85573/rootfs --release xenial --packages ... | `-lxc-ubuntu,29374 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/cellular-wifi-lxc-85573 --name=cellular-wifi-lxc-85573 --rootfs=/var/lib/lxc/cellular-wifi-lxc-85573/rootfs --release xenial --packages ... | `-rsync,29590 -Ha /var/cache/lxc/xenial/rootfs-amd64/ /var/lib/lxc/cellular-wifi-lxc-85573/rootfs/ | `-rsync,29593 -Ha /var/cache/lxc/xenial/rootfs-amd64/ /var/lib/lxc/cellular-wifi-lxc-85573/rootfs/ | `-rsync,29594 -Ha /var/cache/lxc/xenial/rootfs-amd64/ /var/lib/lxc/cellular-wifi-lxc-85573/rootfs/ |-lxc-ubuntu,30173 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/multi_component-image-update-pelion-lxc-85584 --name=multi_component-image-update-pelion-lxc-85584... | `-lxc-ubuntu,30186 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/multi_component-image-update-pelion-lxc-85584 --name=multi_component-image-update-pelion-lxc-85584... | `-flock,30187 -x 9 |-lxc-ubuntu,30226 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/helloworld-update-lxc-85537 --name=helloworld-update-lxc-85537 --rootfs=/var/lib/lxc/helloworld-update-lxc-85537/rootfs --release xenial --packages ... | `-lxc-ubuntu,30233 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/helloworld-update-lxc-85537 --name=helloworld-update-lxc-85537 --rootfs=/var/lib/lxc/helloworld-update-lxc-85537/rootfs --release xenial --packages ... | `-flock,30234 -x 9 |-lxc-ubuntu,30800 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/rootfs-image-update-mbl-cli-lxc-85588 --name=rootfs-image-update-mbl-cli-lxc-85588 --rootfs=/var/lib/lxc/rootfs-image-update-mbl-cli-lxc-85588/rootfs ... | `-lxc-ubuntu,30807 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/rootfs-image-update-mbl-cli-lxc-85588 --name=rootfs-image-update-mbl-cli-lxc-85588 --rootfs=/var/lib/lxc/rootfs-image-update-mbl-cli-lxc-85588/rootfs ... | `-flock,30808 -x 9 |-lxc-ubuntu,30837 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/mbl-cli-basic-commands-lxc-85540 --name=mbl-cli-basic-commands-lxc-85540 --rootfs=/var/lib/lxc/mbl-cli-basic-commands-lxc-85540/rootfs --release xenial ... | `-lxc-ubuntu,30844 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/mbl-cli-basic-commands-lxc-85540 --name=mbl-cli-basic-commands-lxc-85540 --rootfs=/var/lib/lxc/mbl-cli-basic-commands-lxc-85540/rootfs --release xenial ... | `-flock,30845 -x 9 |-lxc-ubuntu,31697 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/wifi-access-lxc-85591 --name=wifi-access-lxc-85591 --rootfs=/var/lib/lxc/wifi-access-lxc-85591/rootfs --release xenial --packages systemd,systemd-sysv | `-lxc-ubuntu,31704 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/wifi-access-lxc-85591 --name=wifi-access-lxc-85591 --rootfs=/var/lib/lxc/wifi-access-lxc-85591/rootfs --release xenial --packages systemd,systemd-sysv | `-flock,31705 -x 9 |-lxc-ubuntu,31800 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/multi_component-image-update-mbl-cli-lxc-85542 --name=multi_component-image-update-mbl-cli-lxc-85542... | `-lxc-ubuntu,31807 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/multi_component-image-update-mbl-cli-lxc-85542 --name=multi_component-image-update-mbl-cli-lxc-85542... | `-flock,31808 -x 9 I have tens and tens of this processes. LAVA jobs have failed but lxc processes are still there. It seems to be some sort of deadlock in the lxc world. I'm on Debian stretch 9.8. It recently started with no apparent reason. Regards -- Diego Russo | Staff Software Engineer | Mbed Linux OS ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom http://www.diegor.co.uk - https://os.mbed.com/docs/mbed-linux-os/ 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. _______________________________________________ Lava-users mailing list Lava-users(a)lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users 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.

6 years, 2 months

LAVA master

by 宿川

Hi all, We upgraded our LAVA master to 2019.11 (2019.11 + stretch) version , but when queried devices owned by current user , it listed all devices hooked to this master, can anybody help check it? Regards, Su Chuan

6 years, 2 months

← Newer
1
...
32
33
34
35
36
37
38
...
95
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users