tiny-container connectivity-profile: test failed
Affected images versions
- not relevant (explain why)
- see the table below (list the *architecture and build id of the tested images in the appropriate cells)
| Deployment | Type | v2023 | v2024 | v2025dev1 |
|---|---|---|---|---|
| apt | minimal/fixedfunction | |||
| ostree | minimal/fixedfunction | |||
| apt | target/hmi | |||
| ostree | target/hmi | |||
| apt | basesdk | |||
| apt | sdk | |||
| apt | nfs | |||
| apt | lxc | Yes | ||
| apt | image-builder | |||
| apt | package-source-builder |
Testcase
https://qa.apertis.org/testcases/v2025dev1/tiny-container-system-connectivity-profile.html
https://qa.apertis.org/testcases/v2025dev1/tiny-container-user-connectivity-profile.html
Expected result
Lava test should pass
Actual result
https://lava.collabora.dev/results/12345098/9_tiny-container-system-connectivity-profile
https://lava.collabora.dev/results/12345098/11_tiny-container-user-connectivity-profile
Root cause
Test is failing in below line https://gitlab.apertis.org/infrastructure/tiny-image-recipes/-/blob/apertis/v2025dev1/lavatests/test-connectivity-profile?ref_type=heads#L140
I feel the intension of expecting the command modprobe btusb to fail inside container is just to ensure that the container doesn't have permission to load any kernel modules. The test cases are passing on armhf and arm64 but not in amd64. After further analyzing, it is clear that btusb module is loaded already and if we execute modprobe btusb , despite the lack of permission the command will not throw any error as the module is already loaded.
Lava job with lsmod output being printed in amd64 - https://lava.collabora.dev/scheduler/job/12335066
Lava job in arm64 -> https://lava.collabora.dev/scheduler/job/12326231#L8282
Outcomes
TBD
Management data
This section is for management only, it should be the last one in the description.
/cc @andrunko @em @Balasubramanian @sudarshan @wlozano
Phabricator link: https://phabricator.apertis.org/T10246