User Tools

Site Tools


civilinfrastructureplatform:testinglavav2vmsetup

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
civilinfrastructureplatform:testinglavav2vmsetup [2017/05/17 03:23]
sesa126914
civilinfrastructureplatform:testinglavav2vmsetup [2017/05/18 00:20] (current)
sesa126914
Line 1: Line 1:
 Deprecated page. Please check [[ciptestingboardatdesksingledevsetup|Board at desk - single dev set up]] and configuration. Deprecated page. Please check [[ciptestingboardatdesksingledevsetup|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 ''​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 
- 
-==== 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: 
- 
-''​[[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]] ​ 
- 
-===== 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. 
- 
-   - ''<​nowiki>​ GetPassWarning:​ Can not control echo on the terminal." ​ 
-   - "​Warning:​ Password input may be echoed."</​nowiki>''​ 
- 
-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. 
- 
-   - ''<​nowiki>​==>​ 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.</​nowiki>''​ 
-   - ''<​nowiki>​==>​ default: HINT: Use CharField(validators=[validate_comma_separated_integer_list]) instead.</​nowiki>''​ 
- 
-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:​~$ **<​nowiki>​sudo lava-server manage createsuperuser --username lavauser --email=lavauser@lava.co.uk</​nowiki>​**''​ 
- 
-''​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: 
- 
-''​[[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** 
- 
- 
-==== 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 (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 
-   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: 
- 
-''​**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. 
- 
-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 
- 
- 
-==== 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** 
- 
-[[https://​pastebin.com/​LsNDyW86]] ​ 
- 
- 
-==== Known Issues ====  
- 
  
civilinfrastructureplatform/testinglavav2vmsetup.1494991402.txt.gz · Last modified: 2017/05/17 03:23 by sesa126914