This is an old revision of the document!
Table of Contents
Deprecated page. Please check Board at desk - single dev set up and configuration.
Board-at-Desk Single-Developer Standalone VM
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.
Prerequisites
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
vboxusersgroup. You can add it with:[user@host ~]$ sudo usermod -aG vboxusers user
- gpg v1.4.20 or better
- sha256sum v8.25 or better
Download the CIP B@D Virtual Machine and Run Example Tests
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.
Download the pre-provisioned CIP Virtual Machine
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$
Using SHA256sum and GPG to check integrity and signature of pre-provisioned box
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
Import the box into Vagrant and launch the Virtual Machine
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:~$
Testing the CIP Kernel on QEMU
12. On your host machine, open a web browser and enter the following in the address box:
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
Board-at-Desk Single-Developer Build VM from Scratch with Vagrant
Clone the CIP B@D Repo, Build the Virtual Machine and Run Example Tests
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$
Clone the CIP Vagrant Repo and launch the Virtual Machine
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.
Warnings and Errors during Vagrant Up Process
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.
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.
==> 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.==> 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
Create a LAVA Superuser Account
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.
Configure the LAVA Health Check Jobs
8. On your host machine, open a web browser and enter the following in the address box:
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
Create the Heath Check Job for both Devices
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
Building and Testing the CIP Kernel from source code using Kernel CI
Get the CIP Kernel using git
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
Compile CIP Kernel with Kernel CI
21. Set the environment variables. You can create a tree name that describes your project. Select the Architecture of the target device (e.g. 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 make -j4 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm modules make -j4 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm modules_install INFO: published artifacts ... cip-example/cip_v4.4.55/v4.4.55-cip3/arm/omap2plus_defconfig/dtbs/am335x-boneblack.dtb ... INFO: triggering build 202
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:
25. You will see the KernelCI Website home page from which, you can navigate to the different builds and Trees that you've created.
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 virtual 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 checkoutstep.) - 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.logshows the output of the build process to help track down any issues in compilation.
kernel.configholds the configuration of which features the kernel was built with.
system.mapis the kernel's symbol table that is used to debug kernel runtime errors.
zImageis the compressed kernel image to be installed on target device.
moduleshold all of the kernel modules needed for the kernel.
dtbsdirectory which holds all of the generated Device Tree Binaries.
Test the CIP Kernel on the Beaglebone Black in LAVA
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
Known Issues
