linaro-validation February 2013

linaro-validation@lists.linaro.org

22 participants
32 discussions

lava configuration for multiple test-machines

by Talat Oz

Hi, I'm trying tofigure out howto setup lava with multiple test-machines (for example, 2 test-machines with multiple android devices connected to each of them). Could you please indicate whether this is possible, and how the configuration should be done(if possible with links to relevant documentation)? Thanks in advance, Talat

13 years

Fwd: Android failing to mount properly

by Dave Pigott

And more... Begin forwarded message: > From: Liviu Dudau <Liviu.Dudau(a)arm.com> > Subject: Re: Android failing to mount properly > Date: 14 February 2013 12:53:23 GMT > To: Dean Arnold <Dean.Arnold(a)arm.com> > Cc: Dave Pigott <dave.pigott(a)linaro.org> > > Hi Dave, > > The script is trying to edit the partition table so that it take into account the fact that the master image also has some partitions on that SD card. > > Unfortunately, the file it is trying to edit (init.rc) is wrong. The partition table information has not been stored there for a while, but in a file that used to be called fstab.partitions and now in the new image is called fstab.arm-versatileexpress for Versatile Express boards. > > We need an updated LAVA script that does the sed editing of the partition table on the correct file. > > Best regards, > Liviu > > On Thu, Feb 14, 2013 at 12:28:30PM +0000, Dean Arnold wrote: >> Hi Dave, >> >> I have attached a log of our failing job alongside the tinkering Liviu was doing with the initrd on the board itself. >> >> We have used the boot.tar.bz2 file from this build: http://snapshots.linaro.org/android/~linaro-android/vexpress-linaro-mp/last… and replaced the kernel. We have not touched the initrd. >> >> Liviu, could you explain to Dave what you think is going wrong please? >> >> Cheers >> Dean > >> * Documentation: https://wiki.linaro.org/ >> root@master:~# >> root@master:~# fdisk -l /dev/mmcblk0 >> mmcblk0 mmcblk0p2 mmcblk0p4 mmcblk0p6 >> mmcblk0p1 mmcblk0p3 mmcblk0p5 mmcblk0p7 >> root@master:~# fdisk -l /dev/mmcblk0 >> >> Disk /dev/mmcblk0: 15.9 GB, 15931539456 bytes >> 4 heads, 16 sectors/track, 486192 cylinders, total 31116288 sectors >> Units = sectors of 1 * 512 = 512 bytes >> Sector size (logical/physical): 512 bytes / 512 bytes >> I/O size (minimum/optimal): 512 bytes / 512 bytes >> Disk identifier: 0x00000000 >> >> Device Boot Start End Blocks Id System >> /dev/mmcblk0p1 * 8192 114687 53248 e W95 FAT16 (LBA) >> /dev/mmcblk0p2 114688 2097151 991232 83 Linux >> /dev/mmcblk0p3 2097152 2228223 65536 c W95 FAT32 (LBA) >> /dev/mmcblk0p4 2228224 31116287 14444032 5 Extended >> /dev/mmcblk0p5 2230272 10618879 4194304 83 Linux >> /dev/mmcblk0p6 10620928 14815231 2097152 83 Linux >> /dev/mmcblk0p7 14817280 31116287 8149504 c W95 FAT32 (LBA) >> root@master:~# ls /tmp/ >> root@master:~# ls /mnt/lava/boot/ >> root@master:~# mount /dev/disk/by-label/testboot /mnt/lava/boot >> root@master:~# ls /mnt/lava/boot/ >> cmdline u-boot_v2p-ca9.bin uefi_v2p-ca9.bin >> config uImage v2p-ca15-tc1.dtb >> initrd uInitrd v2p-ca15-tc2.dtb >> rtsm uefi_v2p-ca15-tc1.bin v2p-ca5s.dtb >> u-boot_v2p-ca15-tc1.bin uefi_v2p-ca15-tc2.bin v2p-ca9.dtb >> u-boot_v2p-ca5s.bin uefi_v2p-ca5s.bin zImage >> root@master:~# ls tm >> ls: cannot access tm: No such file or directory >> root@master:~# ls ~/tm >> ls: cannot access /root/tm: No such file or directory >> root@master:~# ls /tmp/ >> root@master:~# dd if=/mnt/lava/boot/uInitrd of=/tmp/initrd.data bs=64 skip=1 >> 3540+1 records in >> 3540+1 records out >> 226572 bytes (227 kB) copied, 0.944946 s, 240 kB/s >> root@master:~# cd /tmp/ >> root@master:/tmp# lsl >> -bash: lsl: command not found >> root@master:/tmp# ls -al >> total 232 >> drwxrwxrwt 2 root root 4096 Feb 14 11:46 . >> drwxr-xr-x 23 root root 4096 Oct 12 08:30 .. >> -rw-r--r-- 1 root root 226572 Feb 14 11:46 initrd.data >> root@master:/tmp# gunzip -c -f initrd.data | cpio -i >> 755 blocks >> root@master:/tmp# ls -al >> total 484 >> drwxrwxrwt 8 root root 4096 Feb 14 11:49 . >> drwxr-xr-x 23 root root 4096 Oct 12 08:30 .. >> drwxrwx--x 2 root root 4096 Feb 14 11:49 data >> -rw-r--r-- 1 root root 116 Feb 14 11:49 default.prop >> drwxr-xr-x 2 root root 4096 Feb 14 11:49 dev >> -rw-r----- 1 root root 688 Feb 14 11:49 fstab.arm-versatileexpress >> -rw-r----- 1 root root 688 Feb 14 11:49 fstab.v2p-aarch64 >> -rwxr-x--- 1 root root 129908 Feb 14 11:49 init >> -rwxr-x--- 1 root root 1744 Feb 14 11:49 init.arm-versatileexpress.rc >> -rwxr-x--- 1 root root 2487 Feb 14 11:49 init.goldfish.rc >> -rwxr-x--- 1 root root 21091 Feb 14 11:49 init.rc >> -rwxr-x--- 1 root root 1795 Feb 14 11:49 init.trace.rc >> -rwxr-x--- 1 root root 3915 Feb 14 11:49 init.usb.rc >> -rwxr-x--- 1 root root 1595 Feb 14 11:49 init.v2p-aarch64.rc >> -rwxr-x--- 1 root root 27288 Feb 14 11:49 initlogo.rle >> -rw-r--r-- 1 root root 226572 Feb 14 11:46 initrd.data >> drwxr-xr-x 2 root root 4096 Feb 14 11:49 proc >> drwxr-x--- 2 root root 4096 Feb 14 11:49 sbin >> drwxr-xr-x 2 root root 4096 Feb 14 11:49 sys >> drwxr-xr-x 2 root root 4096 Feb 14 11:49 system >> -rw-r--r-- 1 root root 45 Feb 14 11:49 ueventd.arm-versatileexpress.rc >> -rw-r--r-- 1 root root 272 Feb 14 11:49 ueventd.goldfish.rc >> -rw-r--r-- 1 root root 4024 Feb 14 11:49 ueventd.rc >> -rw-r--r-- 1 root root 45 Feb 14 11:49 ueventd.v2p-aarch64.rc >> root@master:/tmp# cat fstab.arm-versatileexpress >> # Android fstab file. >> #<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags> >> # The filesystem that contains the filesystem checker binary (typically /system) cannot >> # specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK >> >> >> /dev/block/mmcblk0p2 /system ext4 ro wait >> /dev/block/mmcblk0p3 /cache ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait >> /dev/block/mmcblk0p5 /data ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait >> root@master:/tmp# grep mmcblk init.rc >> root@master:/tmp# grep block init.rc >> root@master:/tmp# less init.rc >> # Copyright (C) 2012 The Android Open Source Project >> # >> # IMPORTANT: Do not create world writable files or directories. >> # This is a common source of Android security bugs. >> # >> >> import /init.usb.rc >> import /init.${ro.hardware}.rc >> import /init.trace.rc >> import /init.partitions.rc >> >> on early-init >> # Set init and its forked children's oom_adj. >> write /proc/1/oom_adj -16 >> >> # Set the security context for the init process. >> # This should occur before anything else (e.g. ueventd) is started. >> setcon u:r:init:s0 >> >> start ueventd >> >> # create mountpoints >> mkdir /mnt 0775 root system >> root@master:/tmp# cat init.arm-versatileexpress.rc >> on init >> export EXTERNAL_STORAGE /mnt/sdcard >> symlink /mnt/sdcard /storage/sdcard0 >> symlink /mnt/sdcard /sdcard >> >> # mount debugfs >> mount debugfs /sys/kernel/debug /sys/kernel/debug >> >> # power management >> # Enable off mode by default >> #write /sys/kernel/debug/pm_debug/enable_off_mode 1 >> >> on boot >> # create dhcpcd dir >> mkdir /data/misc/dhcp 0770 dhcp dhcp >> chmod 0770 /data/misc/dhcp >> >> # For TC2, set A15 and A7 clusters A7s to interactive governor >> # (Other CoreTiles don't have cpu_freq so this doesn't affect them.) >> write /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor interactive >> write /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor interactive >> >> # change permissions for alsa nodes >> chmod 0777 /dev/snd/pcmC0D0c >> chmod 0777 /dev/snd/pcmC0D0p >> chmod 0777 /dev/snd/controlC0 >> chmod 0777 /dev/snd/timer >> >> #change permissions for alsa nodes for audio modem >> chmod 0777 /dev/snd/pcmC0D5c >> chmod 0777 /dev/snd/pcmC0D5p >> >> #change permissions for alsa nodes for HDMI >> chmod 777 /dev/snd/pcmC0D7p >> >> chown system system /sys/class/graphics/fb0/overlays >> chown system system /sys/class/graphics/fb0/fit_to_screen >> chown system system /sys/class/graphics/fb1/overlays >> >> on fs >> mount_all /fstab.arm-versatileexpress >> >> # setup IRQ affinity to the A7s >> service setirqaffinity /sbin/set_irq_affinity.sh 0xc07 >> class main >> user root >> oneshot >> >> service faketsd /system/bin/faketsd >> class main >> user bluetooth >> group bluetooth >> oneshot >> >> # hack to start networking early during boot, this will enable use of >> # ADB and gator without further manual intervention >> service netcfghack /system/bin/netcfg eth0 dhcp >> class main >> user root >> oneshot >> root@master:/tmp# grep fstab *.rc >> init.arm-versatileexpress.rc: mount_all /fstab.arm-versatileexpress >> init.v2p-aarch64.rc: mount_all /fstab.v2p-aarch64 >> root@master:/tmp# cat fstab.arm-versatileexpress >> # Android fstab file. >> #<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags> >> # The filesystem that contains the filesystem checker binary (typically /system) cannot >> # specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK >> >> >> /dev/block/mmcblk0p2 /system ext4 ro wait >> /dev/block/mmcblk0p3 /cache ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait >> /dev/block/mmcblk0p5 /data ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait >> root@master:/tmp# ls -la >> total 484 >> drwxrwxrwt 8 root root 4096 Feb 14 11:49 . >> drwxr-xr-x 23 root root 4096 Oct 12 08:30 .. >> drwxrwx--x 2 root root 4096 Feb 14 11:49 data >> -rw-r--r-- 1 root root 116 Feb 14 11:49 default.prop >> drwxr-xr-x 2 root root 4096 Feb 14 11:49 dev >> -rw-r----- 1 root root 688 Feb 14 11:49 fstab.arm-versatileexpress >> -rw-r----- 1 root root 688 Feb 14 11:49 fstab.v2p-aarch64 >> -rwxr-x--- 1 root root 129908 Feb 14 11:49 init >> -rwxr-x--- 1 root root 1744 Feb 14 11:49 init.arm-versatileexpress.rc >> -rwxr-x--- 1 root root 2487 Feb 14 11:49 init.goldfish.rc >> -rwxr-x--- 1 root root 21091 Feb 14 11:49 init.rc >> -rwxr-x--- 1 root root 1795 Feb 14 11:49 init.trace.rc >> -rwxr-x--- 1 root root 3915 Feb 14 11:49 init.usb.rc >> -rwxr-x--- 1 root root 1595 Feb 14 11:49 init.v2p-aarch64.rc >> -rwxr-x--- 1 root root 27288 Feb 14 11:49 initlogo.rle >> -rw-r--r-- 1 root root 226572 Feb 14 11:46 initrd.data >> drwxr-xr-x 2 root root 4096 Feb 14 11:49 proc >> drwxr-x--- 2 root root 4096 Feb 14 11:49 sbin >> drwxr-xr-x 2 root root 4096 Feb 14 11:49 sys >> drwxr-xr-x 2 root root 4096 Feb 14 11:49 system >> -rw-r--r-- 1 root root 45 Feb 14 11:49 ueventd.arm-versatileexpress.rc >> -rw-r--r-- 1 root root 272 Feb 14 11:49 ueventd.goldfish.rc >> -rw-r--r-- 1 root root 4024 Feb 14 11:49 ueventd.rc >> -rw-r--r-- 1 root root 45 Feb 14 11:49 ueventd.v2p-aarch64.rc >> root@master:/tmp# > > > > -- > ==================== > | I would like to | > | fix the world, | > | but they're not | > | giving me the | > \ source code! / > --------------- > ¯\_(ツ)_/¯ >

13 years

Is this failure on lava familiar?

by Basil Eljuse

Hello, We are trying to run tests on our 13.02 candidate builds at our end using lava and while booting the target image we are seeing the following problem [ 6.237167] EXT4-fs (mmcblk0p3): VFS: Can't find ext4 filesystem [ 6.257658] fs_mgr: Cannot mount filesystem on /dev/block/mmcblk0p3 at /cache [ 6.279098] init: fs_mgr_mount_all returned an error Has anyone seeing this problem at your end. If we run 13.01 image based tests we do not have any issues. Was wondering if any changes were done w.r.t initrd partitions as for booting up on the target i believe lava swaps around partitions as part of the setup sequence (not fully understood at our end though). Attaching the full log also. Any clue? 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.

13 years

Fwd: Android failing to mount properly

by Dave Pigott

Antonio - more on that lava failure from the ARM guys Dave Begin forwarded message: > From: Dean Arnold <Dean.Arnold(a)arm.com> > Subject: Android failing to mount properly > Date: 14 February 2013 12:28:30 GMT > To: Dave Pigott <dave.pigott(a)linaro.org>, Liviu Dudau <Liviu.Dudau(a)arm.com> > > Hi Dave, > > I have attached a log of our failing job alongside the tinkering Liviu was doing with the initrd on the board itself. > > We have used the boot.tar.bz2 file from this build: http://snapshots.linaro.org/android/~linaro-android/vexpress-linaro-mp/last… and replaced the kernel. We have not touched the initrd. > > Liviu, could you explain to Dave what you think is going wrong please? > > Cheers > Dean > > -- 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.

13 years

Second extension of LAVA server

by 黃俊毓

Hi all I want write second extension for my LAVA server, I don't know how the format of my configures, my custom.cfg: http://paste.ubuntu.com/1644511/ Got a error message wen upgrade http://paste.ubuntu.com/1644523/

13 years

Wait for homescreen for lava-test-shell

by Vishal Bhoj

Hi, Most of the Android tests related to GUI expect Android to have booted to homescreen. With the new lava-test-shell it appears that the tests begin to execute as soon as we reach to a shell prompt, this was not the case with lava-android-test where dispatcher waited till homescreen is reached. I have sent a patch to Senthil to add a test to wait till homescreen is reached, but not all test repositories will include this test. Is it possible to add wait for homescreen as a prerequisite in the lava-test-shell framework while running on android ? Regards, Vishal

13 years

Re: [Linaro-validation] Good if you could help me understand this lava-test-runner error...

by Dave Pigott

For future reference, e-mail the validation list (copied here) rather than just individual people. You get a much broader set of experience that way. Thanks Dave On 13 Feb 2013, at 15:28, Basil Eljuse <Basil.Eljuse(a)arm.com> wrote: > World is too small (: > > I had asked Senthil in parallel to yourself ! > > Thanks > Basil Eljuse... > > From: Dave Pigott [mailto:dave.pigott@linaro.org] > Sent: 13 February 2013 15:27 > To: Basil Eljuse; Senthil Kumaran > Cc: Dean Arnold > Subject: Re: Good if you could help me understand this lava-test-runner error... > > Hi Basil, > > I'm copying Senthil on this. It's more his area of expertise. > > Thanks > > Dave > > On 13 Feb 2013, at 15:21, Basil Eljuse <Basil.Eljuse(a)arm.com> wrote: > > > Hi Dave, > > I am using the following parse block in my test definition yaml file. > > parse: > pattern: "(?P<test_case_id>\\S+)\\s+(?P<result>(deprecated|failed|succeded)$ > fixupdict: > PASS: succeded > FAIL: failed > DEPRECATED: deprecated > > T he lines i am trying to parse from my results is > > FT001 succeded > FT002 failed > FT003 deprecated > > However i am getting the following error > > <LAVA_DISPATCHER>2013-02-13 08:20:13 AM ERROR: bad test result line: FT0002 succeded > <LAVA_DISPATCHER>2013-02-13 08:20:13 AM ERROR: bad test result line: FT0003 succeded > <LAVA_DISPATCHER>2013-02-13 08:20:13 AM ERROR: bad test result line: FT0004 succeded > <LAVA_DISPATCHER>2013-02-13 08:20:13 AM ERROR: bad test result line: FT0005 succeded > <LAVA_DISPATCHER>2013-02-13 08:20:13 AM ERROR: bad test result line: FT0006 succeded > <LAVA_DISPATCHER>2013-02-13 08:20:13 AM ERROR: bad test result line: FT0007 succeded > <LAVA_DISPATCHER>2013-02-13 08:20:13 AM ERROR: bad test result line: FT0008 succeded > <LAVA_DISPATCHER>2013-02-13 08:20:13 AM ERROR: bad test result line: FT0009 succeded > <LAVA_DISPATCHER>2013-02-13 08:20:13 AM ERROR: bad test result line: FT0010 succeded > <LAVA_DISPATCHER>2013-02-13 08:20:13 AM ERROR: bad test result line: FT0011 succeded > <LAVA_DISPATCHER>2013-02-13 08:20:13 AM ERROR: bad test result line: FT0012 succeded > <LAVA_DISPATCHER>2013-02-13 08:20:13 AM ERROR: bad test result line: FT0013 succeded > <LAVA_DISPATCHER>2013-02-13 08:20:13 AM ERROR: bad test result line: basiccheck failed > > > It is hard to guess what the issue is. I believed that using the fixupdict i am converting my own results to lava to show on the dashboard. > > Any help appreciated. > > 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. > > > -- 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.

13 years

Server extension update

by 黃俊毓

Hi all I write a a LAVA server extension, but how to update after modify?

13 years

The "job status keeps running even though the job finished" bug

by Michael Hudson-Doyle

Hi all, A week or two ago now, I made some changes that I _hoped_ would fix the bug alluded to in the subject (https://bugs.launchpad.net/lava-scheduler/+bug/1043059). I've tentatively marked it as Fix Released, but as it always was an intermittent thing I thought I should ask everyone here if they've seen it in the last few days, and to please let me know (by commenting on / reopening the bug I guess) if you see it again. Cheers, mwh

13 years

do as i say, not as i do

by Andy Doan

So I just rolled out an update to validation.linaro.org. This was interesting for a couple of reasons: 1) I did the whole thing with a single salt command: ./lava-upgrade production 2>&1 | tee /root/lava-upgrade-2013-02-08 2) I didn't do an changelog or tagging Both things might be semi-controversial: 1) I know there was an outstanding MP for lp:lava-lab where problems were identified. I think I've fixed those, and you can look at the recent changes to that branch to verify. Michael - the big thing I left out was to always run "lava-deployment-tool setup" before doing an install/upgrade with my new scripts. Here's my debatable logic: As you note this command is basically idempotent. My thinking is that since it is idempotent, we should just always call this function for actions in lava-deployment-tool like upgrade/install/upgradeworker/installworker. As I said - this logic might be debatable, but I made a "midnight decision" :) 2) changelog / tagging - we are at a point where we don't *have* to do this. Things are up in the air with versiontools. however, I think in the future updates will look like this and that the only things we tag are things at the end of the month

13 years

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation February 2013