# Debug This information explains how to customize the Yocto-based workspace, and resolve general problems and issues. ## Debug tools `packagegroup-core-tools-debug` defined in the `/layers/poky/meta` directory adds debug tools as part of `rootfs`. The `/layers/meta-qcom-hwe/recipes-devtools` directory contains the appended package group recipe as `packagegroup-core-tools-debug.bbappend`. This append file adds `ltrace`, `perf`, `sysstat`, and `valgrind` tools to this package group. For more information, see [Debug Linux user space issues](https://docs.qualcomm.com/bundle/publicresource/topics/80-70029-12/using_open_source_debug_tools.html). ## Create a build for debugging To generate a debug build to export `DEBUG_BUILD=1` before issuing Yocto BitBake build instructions, run the following command: DEBUG_BUILD=1 bitbake qcom-multimedia-image Copy to clipboard To understand which kernel defconfig and config fragments are used when `DEBUG_BUILD` is set to **1**, see Kernel configuration, under [Kernel recipes](https://docs.qualcomm.com/doc/80-70029-27/topic/meta_qcom_realtime.html#kernel-recipes-section). ## Verify QDL and ModemManager If you are using a Linux distribution with `systemd`, use the `systemctl` command to stop `ModemManager`. The following is an example from Ubuntu 22.04: 1. To verify the `ModemManager` status, run the following command: systemctl status ModemManager Copy to clipboard ModemManager.service - Modem Manager Loaded: loaded (/lib/systemd/system/ModemManager.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2023-11-28 16:28:15 IST; 3 months 4 days ago Main PID: 1338 (ModemManager) Tasks: 3 (limit: 4915) CGroup: /system.slice/ModemManager.service └─1338 /usr/sbin/ModemManager --filter-policy=strict Copy to clipboard ps aux | grep -i modemmanager Copy to clipboard root 1338 0.0 0.0 434332 9544 ? Ssl 2023 10:39 /usr/sbin/ModemManager --filter-policy=strict Copy to clipboard 2. To stop `ModemManager`, run the following command: systemctl stop ModemManager systemctl status ModemManager Copy to clipboard ModemManager.service - Modem Manager Loaded: loaded (/lib/systemd/system/ModemManager.service; enabled; vendor preset: enabled) Active: inactive (dead) since Sun 2024-03-03 20:08:32 IST; 4s ago Process: 1338 ExecStart=/usr/sbin/ModemManager --filter-policy=strict (code=exited, status=0/SUCCESS) Main PID: 1338 (code=exited, status=0/SUCCESS) Copy to clipboard 3. The `ps aux` command doesn’t show any entry for `/usr/sbin/ModemManager`. If you need `ModemManager`, you must restart it after the flashing is complete and verify if it has started: systemctl start ModemManager systemctl status ModemManager Copy to clipboard ModemManager.service - Modem Manager Loaded: loaded (/lib/systemd/system/ModemManager.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2024-03-03 20:11:46 IST; 43s ago Main PID: 14785 (ModemManager) Tasks: 3 (limit: 4915) CGroup: /system.slice/ModemManager.service └─14785 /usr/sbin/ModemManager --filter-policy=strict Copy to clipboard ps aux | grep -i modemmanager Copy to clipboard root 14785 4.6 0.0 434332 9160 ? Ssl 20:11 0:00 /usr/sbin/ModemManager --filter-policy=strict Copy to clipboard ## Verify newly added layer excluded from build If BitBake didn’t parse a newly added layer, the recipes from that layer aren’t included in the image. 1. Run the following command, and verify that you see the layer in the output: > > > bitbake -e | grep ^BBLAYERS= > Copy to clipboard 2. If you can’t find the layer, confirm the contents of the `conf/bblayers.conf` file to ensure that the layer is included here: > > > # These layers hold recipe metadata not found in OE-core, but lack any machine or distro content > BASELAYERS ?= " \ > ${WORKSPACE}/layers/meta-openembedded/meta-oe \ > ${WORKSPACE}/layers/meta-openembedded/meta-filesystems \ > ${WORKSPACE}/layers/meta-openembedded/meta-networking \ > ${WORKSPACE}/layers/meta-openembedded/meta-perl \ > ${WORKSPACE}/layers/meta-openembedded/meta-python \ > ${WORKSPACE}/layers/meta-openembedded/meta-gnome \ > ${WORKSPACE}/layers/poky/meta \ > ${WORKSPACE}/layers/poky/meta-poky \ > ${WORKSPACE}/layers/meta-security \ > ${WORKSPACE}/layers/meta-selinux \ > ${WORKSPACE}/layers/meta-virtualization \ > " > > # These layers hold machine specific content, aka Board Support Packages > BSPLAYERS ?= " \ > ${WORKSPACE}/layers/meta-qcom-hwe \ > ${WORKSPACE}/layers/meta-qcom \ > " > > # Add your overlay location to EXTRALAYERS > # Make sure to have a conf/layers.conf in there > EXTRALAYERS ?= "${WORKSPACE}/layers/meta-qcom-extras" > > BBLAYERS = " \ > ${WORKSPACE}/layers/meta-qcom-distro \ > ${EXTRALAYERS} \ > ${BASELAYERS} \ > ${BSPLAYERS} \ > " > Copy to clipboard ## Verify QA issue: Version going backwards When using the same workspace for `base` and `custom` builds, you can observe the following signatures: ERROR: - do_packagedata_setscene: QA Issue: Package version for package wpa-supplicant-src went backwards which would break package feeds (from 0:2.10.qcom-r0 to 0:2.10-r0) [version-going-backwards] Copy to clipboard For example: ERROR: wpa-supplicant-2.10-r0 do_packagedata_setscene: QA Issue: Package version for package wpa-supplicant-src went backwards which would break package feeds (from 0:2.10.qcom-r0 to 0:2.10-r0) [version-going-backwards] Copy to clipboard This quality assurance (QA) issue occurs with the `custom` variant of recipes in the `meta-qcom-hwe` layer. For example, the `wpa_supplicant` recipe has its version set as `2.10.qcom`. The `.qcom` in the version indicates that the recipes build a different source tree compared to the recipe in `poky/meta/recipes-connectivity`. When you build the `base` variant after building the `custom` variant, the BitBake build system detects that the version is regressing from `wpa-supplicant_2.10` to `wpa-supplicant-2.10.qcom`. BitBake warns that this regression could cause problems if you use it for creating package feeds. To avoid this QA issue or to set up package feeds without problems, do any of the following: - Create different workspaces for `base` and `custom` build variants. - In the same workspace, create separate build directories as follows: | For build variant | Command to create a build directory | Created build directory | | --- | --- | --- | | `base` | MACHINE=qcs9100-ride-sx DISTRO=qcom-wayland QCOM_SELECTED_BSP=base \
source setup-environment build-qcom-wayland-base
Copy to clipboard | `//Qualcomm_Linux/build-qcom-wayland-base/` | | `custom` | MACHINE=qcs9100-ride-sx DISTRO=qcom-wayland QCOM_SELECTED_BSP=custom \
source setup-environment build-qcom-wayland-custom
Copy to clipboard | `//Qualcomm_Linux/build-qcom-wayland-custom/` | Last Published: Mar 16, 2026 [Previous Topic Create a build to optimize the boot KPI](https://docs.qualcomm.com/bundle/publicresource/80-70029-27/topics/creating_a_build_to_optimize_the_boot_kpi.md) [Next Topic References](https://docs.qualcomm.com/bundle/publicresource/80-70029-27/topics/references.md)