These instructions download a pre-provisioned and pre-configured Virtual Machine that contains Kernel CI and LAVA. Kernel CI is used to build, boot and report results whereas LAVA is used to offer a robust automated testing language, a testing engine and reporting results.

This tutorial assumes that you have the following installed on the host machine:

• git v2.7.4 or better

• Vagrant v1.8.1 or better

• VirtualBox v4.3 or better

• Your username must be a member of the vboxusers group. You can add it with:
  • [user@host ~]$ sudo usermod -aG vboxusers user

• gpg v1.4.20 or better

• sha256sum v8.25 or better

1. Create a clean directory to hold the files for the Virtual Machine (VM). We will use the /home/user/cip directory in these instructions, but you can replace it with whatever works for you.

2. Download the latest version of the pre-provisioned box using the command line as shown or by simply clicking the given link below.

user@host:~$ wget https://s3-us-west-2.amazonaws.com/download.cip-project.org/ciptesting/b%40d/b%40dv0_9/box/cip_board_at_desk_v0.9.0.box

3. Download the latest version of the VM's sha256sum so we can compare that what we received was not modified.

user@host:~$ wget https://s3-us-west-2.amazonaws.com/download.cip-project.org/ciptesting/b%40d/b%40dv0_9/box/cip_board_at_desk_v0.9.0.box

Note: You may need to install the sha256sum program using your distro's package manager.

4. Download the VM's signature so we can verify the VM signature matches.

user@host:~$ wget https://s3-us-west-2.amazonaws.com/download.cip-project.org/ciptesting/b%40d/b%40dv0_9/box/cip_board_at_desk_v0.9.0.box.sig

5. In a terminal, change to the ~/cip directory

user@host:~$ cd ~/cip

user@host:cip$

6. Calculate the SHA256 sum of the Virtual Machine box file

user@host:cip$ sha256sum –check cip_board_at_desk_v0.9.0.sha256sum cip_board_at_desk_v0.9.0.box

cip_board_at_desk_v0.9.0.box: OK

We are looking for the line that says OK. This tells us that the sha256sum's are the same.

Note: If you receive a message stating: “sha256sum: cip_board_at_desk_v0.9.0.box: no properly formatted SHA256 checksum lines found.” You can ignore this message. The sha256sum is very picky about the file format of the .sh256sum file. A relatively recent change to the command generates a warning message if the format is off by a space.

7. Verify the signature of the CIP VM

user@host:cip$ gpg –verify cip_board_at_desk_v0.9.0.box.sig cip_board_at_desk_v0.9.0.box

gpg: Signature made Tue 16 May 2017 09:04:08 AM EDT using RSA key ID 73715D37

8. Clone the board-at-desk-single-dev GitLab Project

user@host:cip$ git clone https://gitlab.com/cip-project/board-at-desk-single-dev

 Cloning into 'board-at-desk-single-dev'...
 remote: Counting objects: 451, done.
 remote: Compressing objects: 100% (185/185), done.
 remote: Total 451 (delta 275), reused 436 (delta 262)
 Receiving objects: 100% (451/451), 15.07 MiB | 14.75 MiB/s, done.
 Resolving deltas: 100% (275/275), done.
 Checking connectivity... done.

9. Change to the newly created board-at-desk-single-dev directory.

user@host:cip$ cd board-at-desk-single-dev

user@host:board-at-desk-single-dev$

10. Import the Virtual Machine into Vagrant and launch the VM

user@host:board-at-desk-single-dev$ ./importbox.sh ../cip_board_at_desk_v0.9.0.box cip-bad-sd0_9

 ==> box: Box file was not detected as metadata. Adding it directly...
 ==> box: Adding box 'cip-bad-sd0_9' (v0) for provider: 
     box: Unpacking necessary files from: file:///home/user/cip/board_at_desk-single-dev
 ==> box: Successfully added box 'cip-bad-sd0_9' (v0) for 'virtualbox'! 
 etc...

Note: One Ethernet port on the VM is Bridged, so it will ask you which one of the Ethernet Adapters on the host machine you wish to bridge. You can automate this by adding your desired Ethernet port to the Vagrantfile.

Note: If you see an error message stating: The SSH command responded with a non-zero exit status. You can safely ignore this error, we will be connecting to the VM using SSH in the next step.

11. Connect to the Virtual Machine

user@host:board-at-desk-single-dev$ vagrant ssh

 Linux jessie 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2 (2017-04-30) x86_64
 
 The programs included with the Debian GNU/Linux system are free software;
 the exact distribution terms for each program are described in the
 individual files in /usr/share/doc/*/copyright.
 
 Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
 permitted by applicable law.
 You have new mail.
 Last login: Tue May 16 08:21:43 2017 from 10.0.2.2
 vagrant@jessie:~$ 

12. On your host machine, open a web browser and enter the following in the address box:

http://<bridged_ip>:8080

13. The LAVA Home Page is displayed in your web browser. Log in to the web server as the superuser:

• Click the login link in the upper right-hand corner of the Lava Server website
• Enter the username: lavauser
• Enter the password: mylava1234

14. Click on Scheduler and then select All Devices.

15. Click on the qemu01 Hostname

16. Click the Force Health Check button.

17. The results are displayed in the web page as the test runs. When the test is done, the status of the Job will show as Complete at the top of the page.

This is what the start of the Health Check looks like:

 Root tmp directory created at /var/lib/lava/dispatcher/tmp/20
 start: 0 validate
 Validating that https://images.validation.linaro.org/kvm/standard/stretch-2.img.gz exists
 no device environment specified
 validate duration: 0.70
 start: 1 deployimages (max 720s)
 start: 1.1 download_retry (max 720s)
 start: 1.1.1 http_download (max 720s)
 Using gz decompression
 downloading https://images.validation.linaro.org/kvm/standard/stretch-2.img.gz as /var/lib/lava/dispatcher/tmp/20/deployimages-GRCaQT/stretch-2.img 
 <snip>

This is what the end of a successful test looks like:

 </snip>
 case: finalize
 definition: lava
 result: pass
 level: 4
 extra: ...
 Cleanup: removing /var/lib/lava/dispatcher/tmp/20 ''

18. You can see an example of a successful test log file at the following link titled QEMU_Test_Success_15-May-2017

https://pastebin.com/PTP41fzE

1. Create a clean directory to hold the Vagrant files needed to build the Virtual Machine (VM) from scratch. We will use the /home/user/v_cip directory in these instructions, but you can replace it with whatever works for you.

2. In a terminal, change to the ~/v_cip directory

user@host:~$ cd ~/v_cip

user@host:v_cip$

3. Clone the board-at-desk-single-dev GitLab Project

user@host:cip$ git clone https://gitlab.com/cip-project/board-at-desk-single-dev

 Cloning into 'board-at-desk-single-dev'...
 remote: Counting objects: 451, done.
 remote: Compressing objects: 100% (185/185), done.
 remote: Total 451 (delta 275), reused 436 (delta 262)
 Receiving objects: 100% (451/451), 15.07 MiB | 14.75 MiB/s, done.
 Resolving deltas: 100% (275/275), done.
 Checking connectivity... done.

4. Change to the newly created board-at-desk-single-dev directory.

user@host:v_cip$ cd board-at-desk-single-dev

user@host:board-at-desk-single-dev$

5. launch the Virtual Machine using Vagrant

user@host:board-at-desk-single-dev$ vagrant up

Note: One Ethernet port on the VM is Bridged, so it will ask you which one of the Ethernet Adapters on the host machine you wish to bridge. You can automate this by adding your desired Ethernet port in the Vagrantfile file.

Below are a list of errors you might see during the vagrant up process:

A. GetPassWarning: This warning is safe to ignore on our Board-at-Desk Single-Developer VM. These do not affect the operation of the KernelCI/LAVA VM.

1. GetPassWarning: Can not control echo on the terminal." - "Warning: Password input may be echoed."

B. CommaSeparatedIntegerField: This warning is safe to ignore on our Board-at-Desk Single-Developer VM. These do not affect the operation of the KernelCI/LAVA VM.

1. ==> default: lava_scheduler_app.Notification.job_status_trigger: (fields.W901) CommaSeparatedIntegerField has been deprecated. Support for it (except in historical migrations) will be removed in Django 2.0.
2. ==> default: HINT: Use CharField(validators=[validate_comma_separated_integer_list]) instead.

6. SSH into the Virtual Machine

user@host ~/board-at-desk-single-dev$ vagrant ssh

7. Set up a Superuser for Lava Job maintenance.

vagrant@jessie:~$ sudo lava-server manage createsuperuser --username lavauser --email=lavauser@lava.co.uk

Password: mylava1234

Password (again): mylava1234

Superuser created successfully.

Note: Replace <lavauser> with your desired username and replace lavauser@lava.co.uk with that user’s email address. Select a password and enter it twice.

8. On your host machine, open a web browser and enter the following in the address box:

http://localhost:8080

9. The LAVA Home Page is displayed in your web browser. Log in to the web server as the superuser:

• Click the login link in the upper right-hand corner of the Lava Server website

• Enter the username: lavauser

• Enter the password: mylava1234

10. From the LAVA homepage, click on your username in the upper right-hand corner of the page. This displays a menu of actions.

• Click on Administration

• Scroll down to section labelled “LAVA_SCHEDULER_APP” and click on “Device types”

11. Click on the qemu device type

12. Copy and paste the contents of the file /vagrant/tests/qemu-health-check.yaml into the Health check job textbox.

13. Click on the Save button in the lower right-hand corner of the page

Note: Once the health-check job is saved to the device type, the job is automatically started by LAVA.

14. Click on the bbb01 device type

15. Copy and paste the contents of the file /vagrant/tests/bbb_debian_ramdisk_test.yaml into the Health check job textbox.

16. Click on the Save button in the lower right-hand corner of the page

17. Change to the git-repos directory

vagrant@guest:~$ cd git-repos

18. Clone the CIP Linux Kernel

vagrant@guest:~/git-repos$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-cip.git

19. Find the branch of the kernel version you want (We will use '4.4.55-cip3' for this example)

vagrant@guest:~/git-repos$ cd linux-cip

vagrant@guest:~/git-repos/linux-cip$ git tag -l | grep cip

 v4.4.42-cip1
 v4.4.48-cip2
 v4.4.55-cip3

20. Create a new branch using the latest CIP tag.

vagrant@guest:~/git-repos/linux-cip$ git checkout -b cip_v4.4.55 v4.4.55-cip3

21. Set the environment variables. You can create a tree name that describes your project. Select the Architecture of the target device (i.e. arm, arm64, mips, i386, amd64, etc.). Choose the cross compiler you need for that architecture.

vagrant@guest:~/git-repos/linux-cip$ export TREE_NAME=cip-example

vagrant@guest:~/git-repos/linux-cip$ export ARCH=arm

vagrant@guest:~/git-repos/linux-cip$ export CROSS_COMPILE=arm-linux-gnueabihf-

Note: Don't forget the dash (-) at the end of the CROSS_COMPILE line!

22. Execute the build.py command, passing in the Beaglebone Black configuration.

vagrant@guest:~/git-repos/linux-cip$ ~/kernelci-build/build.py -c omap2plus_defconfig -p CIP-KernelCI

 make -j4 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm omap2plus_defconfig
 make -j4 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm
 ...

23. Start the Kernel CI web server

vagrant@guest:/vagrant/scripts/start_webserver.sh &

24. On your host machine, open a web browser and enter the following in the address box:

http://localhost:5000

25. You will see the KernelCI Website home page from which, you can navigate to the different builds and Trees that you've created (see the Example Builds section below).

26. Click on the Jobs button at the top of the page and you will see all of the available Trees

27. Click on the Tree name (cip-example) and you will see the list of available builds, or kernel versions for that tree.

28. Click on the v4.4.55 kernel and you will see the list of build configurations (omap2plus).

29. The files that resulted from the build are available in the KernelCI website by navigating to the Tree Name, Kernel version, and Configuration. They are stored on the hard drive at:

/var/www/images/kernel-ci/TREE_NAME/KERNEL_VERSION/BRANCH/ARCH/CONFIG

30. For instance, for the build with the following parameters:

• TREE_NAME: cip-example
• KERNEL_VERSION: v4.4.55-cip3
• BRANCH: cip_v4.4.55 (This comes from the name we chose when we performed the git checkout step.)
• ARCH: arm
• CONFIG: omap2plus

The files will be located at:

/var/www/images/kernel-ci/cip-example/v4.4.55-cip3/cip_v4.4.55/arm/omap2plus

31. Kernel CI generates the following files:

• build.log shows the output of the build process to help track down any issues in compilation.

• kernel.config holds the configuration of which features the kernel was built with.

• system.map is the kernel's symbol table that is used to debug kernel runtime errors

• zImage is the compressed kernel image to be installed on target device

• modules hold all of the kernel modules needed for the kernel

• dtbs directory which holds all of the generated Device Tree Binary's

32. From the LAVA homepage, click on your username in the upper right-hand corner of the page. This displays a menu of actions.

• Click on Administration

• Scroll down to section labelled “LAVA_SCHEDULER_APP” and click on “Device types”

33. Click on the Beaglebone-black device type

34. Modify the Health check job to include the paths to the files generated by Kernel CI

• Under the Actions Block:

• Modify the kernel url to point to the zImage file link

• Modify the ramdisk url to point to the CIP initramfs.cpio.gz file link

• Modify the modules url to point to the modules directory link

• Modify the dtb url to point to the dtb directory link

35. Click on the Save button in the lower right-hand corner of the page

36. Navigate to the Lava homepage and click on Scheduler and All Devices

37. Click on Scheduler and then select All Devices.

38. Click on the bbb01 Hostname

39. Click the Force Health Check button.

40. The results are displayed in the web page as the test runs. When the test is done, the status of the Job will show as Complete at the top of the page.

This is what the start of the Health Check looks like:

 Root tmp directory created at /var/lib/lava/dispatcher/tmp/11
 start: 0 validate
 Validating that http://snapshots.linaro.org/components/lava/standard/debian/jessie/armhf/4/initramfs.cpio.gz exists
 Using GET because HEAD is not supported properly
 Validating that http://localhost:8010/cip-releaseTest/cip_v4.4.55/v4.4.55-cip3/arm/omap2plus_defconfig/zImage exists
 Validating that http://localhost:8010/cip-releaseTest/cip_v4.4.55/v4.4.55-cip3/arm/omap2plus_defconfig/dtbs/am335x-boneblack.dtb exists
 Validating that http://localhost:8010/cip-releaseTest/cip_v4.4.55/v4.4.55-cip3/arm/omap2plus_defconfig/modules.tar.xz exists
 no device environment specified
 booti, bootm and bootz are being deprecated soon, please use 'image','uimage' or 'zimage'
 device may need manual intervention to reboot
 validate duration: 3.01
 start: 1 tftp-deploy (max 240s)
 start: 1.1 download_retry (max 240s)
 start: 1.1.1 http_download (max 240s)
 Not decompressing ramdisk as can be used compressed.
 No compression specified.
 downloading http://snapshots.linaro.org/components/lava/standard/debian/jessie/armhf/4/initramfs.cpio.gz as /var/lib/lava/dispatcher/tmp/11/tftp-deploy-Blt0p9/initramfs.cpio.gz 
 <snip>

This is what the end of a successful test looks like:

 </snip>
 case: finalize
 definition: lava
 result: pass
 level: 4
 duration: 0.105773925781
 extra: ...
 Cleanup: removing /var/lib/lava/dispatcher/tmp/11

41. You can see an example of a successful test log file at the following link titled BBB_Test_Success_15-May-2017

https://pastebin.com/LsNDyW86