I added sha256 into the job definition as you requested:

ramdisk: image_arg: -drive format=raw,file={rootfs} url: http://localhost:8010/initramfs/initramfs.cpio.gz sha256sum: 2f3c091403548c05e79c25d602d631fbcc58af68a9266b78e43a97b0ded670d5 compression: gz # the bootloader needs a u-boot header on the modified ramdisk add-header: u-boot # despite this being a Debian initramfs, it is not a complete Debian rootfs, so use oe compatibility

And the downloading size is always the same:

downloading http://localhost:8010/initramfs/initramfs.cpio.gzsaving as /var/lib/lava/dispatcher/tmp/121/tftp-deploy-GmW9Hh/ramdisk/initramfs.cpio.gztotal size: 46275637 (44MB)

downloading http://localhost:8010/initramfs/initramfs.cpio.gz http://localhost:8080/scheduler/job/120#L14saving as /var/lib/lava/dispatcher/tmp/120/tftp-deploy-Lej43g/ramdisk/initramfs.cpio.gz http://localhost:8080/scheduler/job/120#L15total size: 46275637 (44MB)

downloading http://localhost:8010/initramfs/initramfs.cpio.gz http://localhost:8080/scheduler/job/119#L14saving as /var/lib/lava/dispatcher/tmp/119/tftp-deploy-APtybp/ramdisk/initramfs.cpio.gz http://localhost:8080/scheduler/job/119#L15total size: 46275637 (44MB)

And nothing really happens, everything stays the same, repeats!?

Actually, the whole job fails here:

beaglebone login: # # ShellCommand command timed out.: Sending # in case of corruption. Connection timeout 00:00:47, retry in 00:00:05 pattern: ['-+\[ cut here \]-+\s+(.*\s+-+\[ end trace (\w*) \]-+)', '(Unhandled fault.*)\r\n', 'Kernel panic - (.*) end Kernel panic', 'Stack:\s+(.*\s+-+\[ end trace (\w*) \]-+)', 'ALERT! .* does not exist.\s+Dropping to a shell!', '\(initramfs\)', 'Login timed out', 'Login incorrect'] # Password: # Login incorrect Matched prompt #7: Login incorrect *auto_login not enabled but image requested login details.*

Since the ramdiskfs id corrupted, it is obvious.

Can I add somehow in devices in my bbb01.jinja2 login and password (login root, password <empty>)? For the testing purposes?

What would be the command?

What could be cause to this effect???

Thank you, Zoran _______

On Wed, Mar 21, 2018 at 3:16 PM, Neil Williams neil.williams@linaro.org wrote:

On 21 March 2018 at 13:21, Zoran S zoran.stojsavljevic.de@gmail.com wrote:

...

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)

Downloading automatically calculates the checksum of the downloaded file. e.g.

https://staging.validation.linaro.org/results/testcase/5315362 https://staging.validation.linaro.org/results/testcase/5312933 https://staging.validation.linaro.org/results/testcase/5312928

In each case, identical files produce identical checksums.

You should add the checksum to the test job submission so that LAVA can validate that the file being downloaded is always the same.

https://staging.validation.linaro.org/scheduler/job/ 214255/definition#defline57

In our tests, the same file is always the same download size: https://staging.validation.linaro.org/scheduler/job/214334#L16 https://staging.validation.linaro.org/scheduler/job/214194#L16 https://staging.validation.linaro.org/scheduler/job/214193#L16

...

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/arm/omap2plus_defconfig/zImage http://localhost:8010/cip-example/cip_v4.4.120-cyclic/v4.4. 120-cip20-rt13/arm/omap2plus_defconfig/dtbs/am335x-boneblack.dtb

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?

Sounds like a local problem. Use the checksum support.

...

Thank you, Zoran _______________________________________________ Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users

--

Neil Williams

neil.williams@linaro.org http://www.linux.codehelp.co.uk/