Avoid dummy0 interface being created

[redeexpressos]

Hi, my custom image built using meta-tegra is, for some reason, creating a dummy0 interface:

root@prof:~# journalctl | grep dummy0
Apr 28 17:42:26 p3768-0000-p3767-0001 dbus-daemon[414]: [system] Activating systemd to hand-off: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.1' (uid=0 pid=439 comm="resolvconf -d dummy0.link -f" label="kernel")
Apr 28 17:42:26 prof dbus-daemon[426]: [system] Activating systemd to hand-off: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.1' (uid=0 pid=477 comm="resolvconf -d dummy0.link -f" label="kernel")
Apr 28 17:42:26 prof dbus-daemon[425]: [system] Activating systemd to hand-off: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.1' (uid=0 pid=461 comm="resolvconf -d dummy0.link -f" label="kernel")
Apr 28 17:42:26 prof dbus-daemon[433]: [system] Activating systemd to hand-off: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.1' (uid=0 pid=488 comm="resolvconf -d dummy0.link -f" label="kernel")
Apr 28 17:42:26 p3768-0000-p3767-0001 systemd-networkd[495]: dummy0: found matching network '/lib/systemd/network/80-wired.network', based on potentially unpredictable interface name.
Apr 28 17:42:26 p3768-0000-p3767-0001 systemd-networkd[495]: dummy0: Link UP
Apr 28 17:42:26 p3768-0000-p3767-0001 systemd-networkd[495]: dummy0: Gained carrier
Apr 28 17:42:26 p3768-0000-p3767-0001 systemd-networkd[495]: dummy0: found matching network '/lib/systemd/network/80-wired.network', based on potentially unpredictable interface name.

Is this a meta-tegra feature? How can I avoid it in build time? (Runtime I can just do ip link delete dummy0)

[madisongh]

It's not a feature of the layer, it's a kernel feature that NVIDIA enables in their kernel config by default. I don't know why they do that, since I don't think there's anything in the system that depends on this feature, so you could add a kernel config fragment to turn it off.

[redeexpressos]

So in short, should I create a bitbake bbappend that adds a patch that changes tegra_defconfig and unsets CONFIG_DUMMY?

[redeexpressos]

Ive tried this but no success:
linux-tegra_5.10%.bbappend

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"

# KERNEL fragments
SRC_URI += "file://orin.cfg"
KBUILD_DEFCONFIG += "orin.cfg"

orin.cfg:

# CONFIG_DUMMY is not set
# CONFIG_CPU_ISOLATION is not set

[madisongh]

Don't mess with KBUILD_DEFCONFIG, just adding the config fragment to SRC_URI should be enough. Then check the generated .config file down in the kernel build tree to see if the change got made. If not, then examine the logs (including the logs from the config processing that get generated under .kernel-meta in the kernel source tree) to see what happened.

[redeexpressos]

/home/ubuntu/builder/build/tmp/work/p3768_0000_p3767_0001-poky-linux/linux-tegra/5.10.192+gitAUTOINC+db857ecdbe-r0/linux-p3768_0000_p3767_0001-standard-build/.config still has CONFIG_DUMMY=y set...

linux-tegra_5.10%.bbappend:

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"

SRC_URI += "file://unset-config-dummy.patch"

patch:

Date: Wed, 8 May 2024 15:51:12 +0100
Subject: [PATCH] unset config_dummy

---
 arch/arm/configs/tegra_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index fff5fae0db30..f4b616f68000 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -102,7 +102,7 @@ CONFIG_ATA=y
 CONFIG_SATA_AHCI=y
 CONFIG_AHCI_TEGRA=y
 CONFIG_NETDEVICES=y
-CONFIG_DUMMY=y
+# CONFIG_DUMMY is not set
 CONFIG_IGB=y
 CONFIG_R8169=y
 CONFIG_USB_PEGASUS=y
-- 
2.34.1

Where do I exactly find the logs?

[kekiefer]

Check log.do_kernel_configme, and other logs, in the same temp folder you identified above for more hints about what might be happening. Your original config fragment, if only you had just applied it to SRC_URI, looks like it should have worked.

[dchvs]

Besides the log files, you can directly check the resultant Kernel config file. The path is: tmp/work-shared/<machine>/kernel-build-artifacts/.config.

You can add a fragment in two steps:

1. Create the file files/dummy.cfg

# Config Dummy interface
CONFIG_DUMMY=n

Note: I think it's important to add a comment in the first line because the first line is not parsed as a config directive.

2. Add that fragment file as source code append to SRC_URI:

SRC_URI:append = "\
    file://files/dummy.cfg \
"

Then, rebuild your Kernel config:

bitbake virtual/kernel -f -c kernel_configme
bitbake virtual/kernel

And see the result in tmp/work-shared/<machine>/kernel-build-artifacts/.config.

Alternatively to the fragment approach, and in case you don't want to trim the Dummy functionality, you can add a Kernel argument.

# Set 0 dummies
KERNEL_ARGS:append = "\
     dummy.numdummies=0 \
"