the Chromium logo

The Chromium Projects
ChromiumOS > Training >

Basic ebuild troubleshooting

This is a brief explanation of how one might trouble shoot local emerge/ebuild failures. It is in no way comprehensive, and is only meant as an introduction to the topic:

Emerge errors during cros build-image

When following the ChromiumOS Developer Guide emerge errors can be encountered for missing ebuild. A error that can be encountered when running cros build-image is:

emerge: there are no ebuilds to satisfy XYZ

Where XYZ is a library or other missing package.

This can be resolved by running:

emerge-$BOARD XYZ

Then recalling cros build-image:

cros build-image --board=${BOARD} --no-enable-rootfs-verification dev
    • References: \[1\] Autotest ebuild documentation \[2\] Chromite documentation From within the chroot, try running the a new test through run_remote_tests, as described in the codelab on autotest client tests, without actually adding it to an ebuild. This might give you an error about not being able to find kernel_HdParmBasic’s control file. To resolve this, from within chroot: 1. Find the package with autotest tests: emerge --search autotest | grep tests 2. Dry emerge it and look for your test in the output: emerge-lumpy -pv chromeos-base/autotest-tests ==Two things to note:== a. The first line will say something like: “chromeos-base/autotest-tests-0.0.1-r3531“ This means it’s emerging the r3531 ebuild. Since we would like it to use our local bits, we need to cros_workon the package. b. You will not find kernel_HdParmBasic in the output. 3. cros_workon the appropriate package: cros_workon --board=<board name> start <package name> eg: cros_workon --board=lumpy start autotest-tests emerge the package: emerge-<board name> <package name> eg: emerge-lumpy -pv chromeos-base/autotest-tests ==Two things to note:== a. The first line will say something like: “chromeos-base/autotest-tests-9999” This is good, it means it’s pulling local bits. b. You still will not find kernel_HdParmBasic in the output. This is because your new test hasn’t been added to the ebuild yet. 4. Edit the ebuild to include your test: Find the ebuild file: find -iname “autotest-tests-9999.ebuild” from src/third_party/. a. It will most probably point you to: third_party/chromiumos-overlay/chromeos-base/autotest-tests/autotest-tests-9999.ebuild. b. open this file and add “+test_kernel_HdParmBasic” in the IUSE_TESTS section. 5. Emerge the new folder: a. Make sure you’re cros_working on the right packages: cros_workon --board=lumpy list should show autotest_tests b. Make sure the emerge will touch kernel_HdParmBasic: emerge-lumpy -pv chromeos-base/autotest-tests | grep kernel_HdParmBasic c. Actual emerge: emerge-lumpy chromeos-base/autotest-tests 6. Check the staging area for your new test: eg: ls /build/lumpy/usr/local/autotest/client/site_tests/kernel_HdParmBasic 7. Re-run the run_remote command and look for the results directory: you should see a line like: >>> Details stored under /tmp/run_remote_tests.KTQ4 Alternatively, you can specify your own results directory using ‘--results_dir_root’. Some common ebuilds to cros_workon and emerge: autotest-all (Meta ebuild for all packages providing tests), autotest-factory (Autotest Factory tests), autotest-chrome (Autotest tests that require chrome_test or pyauto deps), autotest-tests (Pure Autotest tests), autotest (Autotest scripts and tools). If you have come this far, you may also be interested in reading the autotest client tests codelab. Access Violation Errors when Emerging When you're attempting to include a file from another project, for example #include <shill/net/rtnl_handler.h> Your build may fail with access violations, e.g. ... arc-networkd-9999: \[0/3\] CXX obj/arc/network/arc-networkd.manager.o \* ACCESS DENIED: open_rd: /mnt/host/source/src/platform2/shill/net/rtnl_listener.h arc-networkd-9999: \* ACCESS DENIED: open_rd: /mnt/host/source/src/platform2/shill/net/shill_export.h arc-networkd-9999: \* ACCESS DENIED: open_rd: /mnt/host/source/src/platform2/shill/net/rtnl_listener.h arc-networkd-9999: \* ACCESS DENIED: open_rd: /mnt/host/source/src/platform2/shill/net/shill_export.h arc-networkd-9999: arc-networkd-9999: \[1/3\] CXX obj/arc/network/arc-networkd.manager.o arc-networkd-9999: FAILED: obj/arc/network/arc-networkd.manager.o The proper way to handle this is to make sure that the ebuild for the package you are including a file from (in this case, shill), is installing the necessary headers to /usr/include. This should look like: src_install() { # ... insinto /usr/include/\[package_name\] doins header_one.h doins header_two.h # ... } Notably, it is incorrect to add the package name you are depending on to your package's ebuild under CROS_WORKON_SUBTREE.