2391933_en-US

[#1]

LSDK 25.12 udev autoload race with /boot/modules layout

Hi NXP team,

We are using the following environment:

* Platform: i.MX8MP
* Distribution: Debian 13 / trixie
* LSDK release: LSDK-25.12_DEBIAN-13_LF-6.12.20
* Kernel: 6.12.20
* systemd / udev: 257.x
* kmod / libkmod: 34.x

We encountered an intermittent cold boot issue where some kernel modules are not automatically loaded by udev. In our case, the affected devices are mainly the audio codec/audio chain and WLAN module.

The symptoms include:

* `snd_soc_wm8962` is not loaded
* the audio codec and audio platform devices remain unbound
* `aplay -l` reports no sound cards
* the WLAN interface is missing
* manually running `modprobe` or `udevadm trigger --action=add` after boot can recover the devices

After debugging, we found that the issue seems related to the kernel module layout used by this flexbuild release.

In the `LSDK-25.12_DEBIAN-13_LF-6.12.20` flexbuild tag, `configs/debian/debian_post_config.sh` creates the following symlink:

```sh
ln -sf /boot/modules /lib/modules
```

Also, `tools/create_bootpartition` copies the kernel modules into the boot partition:

```sh
cp -rf $KERNEL_OUTPUT_PATH/$KERNEL_BRANCH/tmp/lib/modules $bootpartdir
```

Therefore, at runtime, `/lib/modules` depends on `/boot/modules`, and `/boot` is mounted later by `boot.mount`.

We also noticed that `src/system/boot.mount` contains:

```ini
[Unit]
Description=Boot Partition
Before=systemd-modules-load.service

[Mount]
What=UUID=PARTUUID
Where=/boot
Type=ext4
Options=defaults

[Install]
WantedBy=local-fs.target
```

This appears to ensure that `/boot` is mounted before the static module loading path handled by `systemd-modules-load.service`.

However, our issue is not from `systemd-modules-load.service`. The affected audio/WLAN modules are loaded dynamically by udev through device `MODALIAS` events.

In failing boots, we observed that the affected device events are processed by udev before `boot.mount` has completed. At that moment, `/lib/modules` points to `/boot/modules`, but `/boot` has not been mounted yet. As a result, libkmod cannot access the module alias/index files or the corresponding `.ko` files, so the udev module auto-loading path fails. Since the udev event has already been processed, the driver is not loaded later unless we manually retrigger udev or run `modprobe`.

Our understanding of the failing path is:

```text
kernel device add event
→ udev receives the MODALIAS event
→ udev/libkmod tries to access /lib/modules
→ /lib/modules points to /boot/modules
→ /boot is not mounted yet
→ module alias/index files or .ko files are not available
→ module auto-loading fails
```

We would like to confirm the following:

1. Is the `/lib/modules -> /boot/modules` layout expected for the LSDK 25.12 Debian 13 release?

2. Is the race between early udev `MODALIAS` handling and the later `boot.mount` a known issue or known limitation of this layout?

3. We noticed that the current upstream flexbuild main branch appears to have changed this architecture: kernel modules are no longer copied into the boot partition by `create_bootpartition`, and the `/lib/modules -> /boot/modules` symlink is no longer created in `debian_post_config.sh`.

Is this architecture change related to avoiding this kind of early boot module auto-loading race?

4. For LSDK 25.12 Debian 13, what is NXP’s recommended fix or workaround for this issue?

Please let us know whether our understanding is correct and whether there is an official patch or recommended update path for this release.

Thanks.

i.MX 8M | i.MX 8M Mini | i.MX 8M NanoRe: LSDK 25.12 udev autoload race with /boot/modules layout

Hi,

Q1: The original intention behind this was to place the kernel image and modules together on the boot partition, so that when upgrading the kernel, only the boot partition needs to be replaced, without having to modify the root filesystem. This layout is intentional and is not a bug.

Q2:Your line of reasoning is correct; this is an inherent limitation of this layout.

Q3: When building the image, you can make a one-time adjustment to move the contents of `/boot/modules` to `/lib/modules` in the root filesystem and remove the symbolic links:

rm -f /lib/modules
mkdir -p /lib/modules
cp -a /boot/modules/* /lib/modules/

At the same time,

1. modify `tools/create_bootpartition` in the build script and remove the line `cp -rf .../lib/modules $bootpartdir`; 

2. Modify `debian_post_config.sh` and remove the line `ln -sf /boot/modules /lib/modules`; 

3. Configure the `bld linux / modules_install` target to install modules into the root filesystem (see the implementation of the `linux-modules` target in the `main` branch).

Best Regards,
Zhiming