====== B@D Known Issues, Workarounds and Troubleshooting Guide ====== This page details the known issues and any workarounds when working with the B@D VM. The issues are tracked in the CIP [[https://gitlab.com/cip-project/cip-testing/testing/boards/322796?&label_name[]=bug|bugtracker]] on gitlab.com. Links to the issues are given when possible. Additionally, the CIP testing team has started compiling a troubleshooting guide for some common problems we've seen that are not bugs. ===== B@D Virtual Machine Known Issues and their Workarounds ===== Known issues of the VM created within the CIP project including LAVAv2 and KernelCI. === Issue #53: U Boot Prompt Detection === LAVA looks for the U-Boot prompt but due to differing forms of this prompt may not find it, see https://gitlab.com/cip-project/cip-testing/testing/issues/53 for background and a manual fix for the beaglebone. ---- === Issue #87: Test times may be shown incorrectly === If you suspend your host with Vagrant still running, when you awaken it the VM still has the time when suspended and it does not get updated to the time now. See https://gitlab.com/cip-project/cip-testing/testing/issues/87 for the associated issue. With Vagrant 2.1.2 this issue no longer occurs so upgrading your vagrant installation is a workaround - and therefore that issue has been closed. ---- === Issue #121 The QEMU health check may timeout === If the QEMU Health check times out, try adjusting the values in the script along the lines of those values mentioned in https://gitlab.com/cip-project/cip-testing/testing/issues/121 ---- ===== B@D Virtual Machine Troubleshooting Guide ===== === 1. Dealing With Stalled Bring-up of Vagrant Devices === If during "vagrant up" the VM becomes unresponsive at the "Configuring and enabling network interfaces" step. Press Ctrl-C twice to force a shutdown of the VM and restart it by issuing the ''vagrant up'' command again. Normal vagrant control should be possible after the restart. // Note: You can also force a shutdown using the Virtualbox GUI. // ---- === 2. 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. It does 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. It does 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.'' ---- === 3. Adding extra resources to the Virtual Machine === The Vagrant instance by default is configured with 2GB of memory, if you require more memory, and have sufficient local resources on your machine, edit line 26 of the Vagrantfile so that '' vbox.customize ["modifyvm", :id, "--memory", "2048"]'' is given a larger value. Similarly, if you need a larger disk storage capacity, there are several ways you can accomplish that. The preferred method is shown below. 1. To Add a new hard drive to the B@D Virtual Machine, shutdown the VM using ''vagrant halt'' [[http://www.techrepublic.com/article/how-to-add-new-drives-to-a-virtualbox-virtual-machine/]] 2. Using the GUI, add a hard drive to the VM (/dev/sda) 3. Boot the VM using ''vagrant up'' 4. Create a new partition table on the new disk using ''fdisk'' [[https://askubuntu.com/questions/384062/how-do-i-create-and-tune-an-ext4-partition-from-the-command-line]] 5. Create a new primary partition (/dev/sda1) 6. Write your changes to disk 7. Make a directory where you want to mount the new disk to (/storage) 8. Mount /dev/sdb1 to /storage 9. Consider moving the /var directory to the new drive since that is where the build artifacts are stored. [[https://linuxconfig.org/how-to-move-var-directory-to-another-partition]]. As the /home directory is likely to be larger than /var unless you do a lot of builds of different versions of the CIP kernel you may also wish to move /home onto its own partition. (If wanting to expand primary vmdk disk sda, resizing via vdi & gparted: https://computingforgeeks.com/step-by-step-guide-on-how-to-extend-vdi-and-vmdk-hard-disks-on-virtualbox/) ---- === 4. Logging in on the LAVA web interface fails silently === If you have not rebooted the virtual machine after the initial provision, logging in as administrator will return you to the home page but with the login still available. You need: \\ vagrant halt vagrant up in order to have the LAVA installation running cleanly so that login works. ---- === 5. Debian stretch provides vagrant and virtual box which do not work together === In order to have versions of these packages which work together in Debian stretch, run the following (on the host!) see [[https://gitlab.com/cip-project/cip-testing/testing/issues/121|#121]]: sudo apt-add-repository 'deb http://download.virtualbox.org/virtualbox/debian stretch contrib' curl -O https://www.virtualbox.org/download/oracle_vbox_2016.asc sudo apt-key add oracle_vbox_2016.asc sudo apt-get update sudo apt-get install virtualbox-5.1 ---- === 6. Connecting to the Beaglebone using ssh === If you have problems connecting to the BBB using ssh - though the health check does not reuire this - use the following [[https://gitlab.com/cip-project/cip-testing/testing/issues/157|procedure]]: * The usb power cable must be connected to the host (as well as the ftdi cable but this isn't used here) the eth1 device will appear - but is not being assigned an IP address * Then sudo ifconfig eth1 192.168.7.1 (on the host) ssh root@192.168.7.2 should then work. * Note that the BBB will reboot during the health test and the above setting will be lost so an edit to /etc/network/interfaces will be necessary to set this address ---- === 7. Extending the kernelci timeout date === Builds in kernelci become invisible to the web interface after 14 days - though the builds are still accessible from LAVA tests, if you wish to increase that timeout edit the DATE_RANGE setting in /etc/linaro/kernelci-frontend.cfg. See the discussion in [[https://gitlab.com/cip-project/cip-testing/testing/issues/164|#164]] - now closed. ---- === 8. Provisioning B@D from behind a web proxy === You may have errors when trying to provision B@D when operating behind some web proxies, see [[https://gitlab.com/cip-project/cip-testing/testing/issues/195|#195]] for a discussion and hints. [[civilinfrastructureplatform:ciptestingboardatdesksingledevfeaturepage | Back to the B@D Features page]]