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.
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
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.
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
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.
This tutorial needs the same list of prerequisites as those listed on the features page.
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
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