Table of Contents

B@D Virtual Machine Deployment (1/5)

These instructions download a pre-provisioned and pre-configured Virtual Machine (VM) 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 is the page on which, you should start to create your own CIP B@D Virtual Machine.

Note: Please make sure your development machine has all of the prerequisites spelled out on the features page.

B@D Deployment Method #1 - Download The Standalone Virtual Machine Box

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. In a terminal, change to the ~/cip directory

user@host:~$ cd ~/cip

user@host:cip$

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

user@host:cip$ wget https://s3-us-west-2.amazonaws.com/download.cip-project.org/ciptesting/b%40d/b%40d_v1_0/box/cip_board_at_desk_v1.0.box

4. Download the 1.0 version of the VM's sha256sum so we can confirm that what we received was not modified.

user@host:cip$ wget https://s3-us-west-2.amazonaws.com/download.cip-project.org/ciptesting/b%40d/b%40d_v1_0/box/cip_board_at_desk_v1.0.sha256sum

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

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

user@host:cip$ wget https://s3-us-west-2.amazonaws.com/download.cip-project.org/ciptesting/b%40d/b%40d_v1_0/box/cip_board_at_desk_v1.0.box.sig

6. Download the CIP VM signer's public key

user@host:cip$ wget https://s3-us-west-2.amazonaws.com/download.cip-project.org/ciptesting/b%40d/b%40d_v1_0/sources/pubkey.txt

Using SHA256sum and GPG to check integrity and signature of pre-provisioned box

7. Import the public key into your keyring.

user@host:cip$ gpg --import pubkey.txt

gpg: key 33D89A0573715D37: public key "Robert Marshall (Codething) <robert.marshall@codethink.co.uk>" imported
gpg: Total number processed: 1
gpg:               imported: 1

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

user@host:cip$ sha256sum --check cip_board_at_desk_v1.0.sha256sum

cip_board_at_desk_v1.0.box: OK

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

9. Verify the signature of the CIP VM

user@host:cip$ gpg --verify cip_board_at_desk_v1.0.box.sig cip_board_at_desk_v1.0.box

 gpg --verify cip_board_at_desk_v1.0.box.sig cip_board_at_desk_v1.0.box
 gpg: Signature made Fri 13 Oct 2017 11:36:06 BST using RSA key ID 0647F909
 gpg: Good signature from "Robert Marshall (Codething) <robert.marshall@codethink.co.uk>"
 gpg: WARNING: This key is not certified with a trusted signature!
 gpg:          There is no indication that the signature belongs to the owner.
 Primary key fingerprint: 83B2 E0FD 9B33 61ED 2C0E  381C 318B 48B3 0647 F909

We are looking for the 2nd output line stating that this is a Good signature…

Note: The Warnings shown above are normal, as they depend on your setup and configuration. Here are explanations for the warnings you might encounter:

 gpg: no ultimately trusted keys found

This means that the specific key is not “ultimately trusted” by you or your web of trust, which is okay for the purposes of verifying file signatures.

 WARNING: This key is not certified with a trusted signature! 
 There is no indication that the signature belongs to the owner.

This refers to your level of trust in your belief that you possess our real public key. This is a personal decision. Ideally, a CIP developer would hand you the key in person, but more commonly, you downloaded it. Was the download tampered with? Probably not, but this decision is up to you. Setting up a web of trust is one method for trusting them. See the GPG documentation for more information on how to work with public keys: http://www.gnupg.org/gph/en/manual/x334.html

10. If you wish to use the snapshot release go to the Download page and use the links for the snapshot from there, continue from step 6 above.

Import the box into Vagrant and launch the Virtual Machine

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

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

 Cloning into 'board-at-desk-single-dev'...
 remote: Counting objects: 588, done.
 remote: Compressing objects: 100% (248/248), done.
 remote: Total 588 (delta 369), reused 548 (delta 338)
 Receiving objects: 100% (588/588), 15.09 MiB | 8.92 MiB/s, done.
 Resolving deltas: 100% (369/369), done.
 Checking connectivity... done. 

12. 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$

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

user@host:board-at-desk-single-dev$ ./importbox.sh ../cip_board_at_desk_v1.0.box cip-bad-sd1_0

 ==> box: Box file was not detected as metadata. Adding it directly...
 ==> box: Adding box 'cip-bad-sd1_0' (v0) for provider: 
     box: Unpacking necessary files from: file:///home/user/cip/cip_board_at_desk_v1.0.box
 ==> box: Successfully added box 'cip-bad-sd1_0' (v0) for 'virtualbox'! 
 ...
 the VM will begin to boot
 ...
 user@host:board-at-desk-single-dev$ 

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. e.g. change the config.vm.network line to
config.vm.network “public_network”, use_dhcp_assigned_default_route: true, :bridge ⇒ 'eth0'

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.

14. Next, you will move on to the B@D Setup and Configuration wiki page


B@D Deployment Method #2 - Building VM From Scratch Using Vagrant (1/5)

These instructions clone a set of scripts that build the Virtual Machine, that contains Kernel CI and LAVA, from scratch. 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 needs the same list of prerequisites as those listed on the features page.

Clone the CIP Vagrant Repo and launch the Virtual Machine

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 makes the most sense 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:v_cip$ git clone https://gitlab.com/cip-project/cip-testing/board-at-desk-single-dev

 Cloning into 'board-at-desk-single-dev'...
 remote: Counting objects: 588, done.
 remote: Compressing objects: 100% (248/248), done.
 remote: Total 588 (delta 369), reused 548 (delta 338)
 Receiving objects: 100% (588/588), 15.09 MiB | 8.92 MiB/s, done.
 Resolving deltas: 100% (369/369), 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

Example output from the launch is available in the CIP-kernel-test-logs repos.

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. e.g. change the config.vm.network line to
config.vm.network "public_network", use_dhcp_assigned_default_route: true, :bridge => 'eth0'

Note: The Vagrant instance uses a private network to communicate with an attached board connected via a host USB, this network uses the IP address 192.168.22.0 if this will clash with your network settings then you will need to edit the Vagrant file and also alter integration-scripts/configure_lava.sh before running `vagrant up`.

6. The provisioning now requires a network restart during that process, at this point the output is

 ==> default: Setting up net-tools (1.60+git20161116.90da8a0-1) ...
 ==> default: now run vagrant halt; vagrant up; vagrant provision; 
 ==> default: to complete b@d provisioning
 The SSH command responded with a non-zero exit status. Vagrant
 assumes that this means the command failed. The output for this command
 should be in the log above. Please read the output to determine what
 went wrong.

So as instructed:

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

7. Restart the Virtual Machine using Vagrant (this step is necessary in order for the LAVA configuration to take effect). See Troubleshooting Guide for a fuller description of the issue.

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

Warnings and Errors during Vagrant Up Process

Please see the B@D Known Issues, Workarounds and Troubleshooting Guide page for any errors or warnings you may encounter.

8. Next, you will move on to the B@D Setup and Configuration wiki page