# Debug This information explains how to customize the Yocto-based workspace, and resolve general problems and issues. ## QDL and ModemManager If you are using a Linux distribution with `systemd`, `ModemManager` can be stopped by using `systemctl`. 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 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 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) 3. The `ps aux` command does not 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 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 ## Newly added layer excluded from build If you cannot include recipes from a newly added layer in the image, it is likely that the BitBake did not parse that layer. Run the following command, and verify that you see the layer in the output: bitbake -e | grep ^BBLAYERS= Copy to clipboard If you cannot 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 ## Quality assurance (QA) issue: version going backwards When using the same workspace for `custom` and `base` 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 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_1.2/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_1.2/build-qcom-wayland-custom/` | Last Published: Oct 14, 2024 [Previous Topic User customizations](https://docs.qualcomm.com/bundle/publicresource/80-70015-27/topics/user_customizations.md) [Next Topic References](https://docs.qualcomm.com/bundle/publicresource/80-70015-27/topics/references.md)