Bug#1031561: v4l2loopback-dkms: Fails to build on cloud kernel image

[Witold Baryluk]

Package: v4l2loopback-dkms
Version: 0.12.7-2
Severity: normal
X-Debbugs-Cc: witold....@gmail.com

root@debian:~# sudo apt install linux-headers-6.1.0-5-cloud-amd64
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
castxml catch2 dh-dkms fonts-ebgaramond libc++1-14 libc++abi1-14 libcoq-stdlib libcppunit-dev libfmt-dev libgsm1-dev libjs-jquery-ui-theme-trontastic libopenblas-dev libpython3-all-dev libspdlog-dev
libthrift-dev libunwind-14 libxsimd-dev libzarith-ocaml pyqt5-dev-tools python3-all-dev python3-beniget python3-click-plugins python3-contextlib2 python3-gast python3-gitlab python3-pygccxml
python3-pyqt5.qwt python3-schema python3-thrift python3-xlwt qt6-base-dev-tools unattended-upgrades xfce4-datetime-plugin
Use 'sudo apt autoremove' to remove them.
The following NEW packages will be installed:
linux-headers-6.1.0-5-cloud-amd64
0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded.
1 not fully installed or removed.
Need to get 869 kB of archives.
After this operation, 2,125 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian sid/main amd64 linux-headers-6.1.0-5-cloud-amd64 amd64 6.1.12-1 [869 kB]
Fetched 869 kB in 0s (9,081 kB/s)
Selecting previously unselected package linux-headers-6.1.0-5-cloud-amd64.
(Reading database ... 1407668 files and directories currently installed.)
Preparing to unpack .../linux-headers-6.1.0-5-cloud-amd64_6.1.12-1_amd64.deb ...
Unpacking linux-headers-6.1.0-5-cloud-amd64 (6.1.12-1) ...
Setting up linux-image-6.1.0-5-cloud-amd64-unsigned (6.1.12-1) ...
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 6.1.0-5-cloud-amd64:Sign command: /usr/lib/linux-kbuild-6.1/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub
Error! The /var/lib/dkms/v4l2loopback/0.12.7/6.1.0-5-cloud-amd64/x86_64/dkms.conf for module v4l2loopback includes a BUILD_EXCLUSIVE directive which does not match this kernel/arch/config.
This indicates that it should not be built.
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
failed!
run-parts: /etc/kernel/postinst.d/dkms exited with return code 11
dpkg: error processing package linux-image-6.1.0-5-cloud-amd64-unsigned (--configure):
installed linux-image-6.1.0-5-cloud-amd64-unsigned package post-installation script subprocess returned error exit status 1
Setting up linux-headers-6.1.0-5-cloud-amd64 (6.1.12-1) ...
/etc/kernel/header_postinst.d/dkms:
dkms: running auto installation service for kernel 6.1.0-5-cloud-amd64:Sign command: /usr/lib/linux-kbuild-6.1/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub
Error! The /var/lib/dkms/v4l2loopback/0.12.7/6.1.0-5-cloud-amd64/x86_64/dkms.conf for module v4l2loopback includes a BUILD_EXCLUSIVE directive which does not match this kernel/arch/config.
This indicates that it should not be built.
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
failed!
run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 11
Failed to process /etc/kernel/header_postinst.d at /var/lib/dpkg/info/linux-headers-6.1.0-5-cloud-amd64.postinst line 11.
dpkg: error processing package linux-headers-6.1.0-5-cloud-amd64 (--configure):
installed linux-headers-6.1.0-5-cloud-amd64 package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
linux-image-6.1.0-5-cloud-amd64-unsigned
linux-headers-6.1.0-5-cloud-amd64
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)



While using v4l2loopback on a cloud kernel is not be a likely scenario,
and cloud kernel image has multiple subsystems of kernel disabled /
removed, including sound and v4l to save a bit on image size, it would
probably nice if v4l2loopback do not just stright fail to build. One can
for example have both cloud kernel and other kernels installed, and it is
perfectly ok to build then dkms only for a subset of kernels.




-- System Information:
Debian Release: bookworm/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.2.0-rc5 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages v4l2loopback-dkms depends on:
ii dkms 3.0.10-6

v4l2loopback-dkms recommends no packages.

Versions of packages v4l2loopback-dkms suggests:
ii v4l2loopback-utils 0.12.7-2

-- no debconf information

[Andreas Beckmann]

Control: forwarded -1 https://github.com/dell/dkms/issues/302

On Sun, 19 Feb 2023 17:43:50 +0100
=?UTF-8?Q?IOhannes_m_zm=c3=b6lnig_=28Debian/GNU=29?=
<umla...@debian.org> wrote:
> i strongly believe that this is not a problem with v4l2loopback-dkms,
> but instead an issue with dkms itself. (i have therefore re-assigned the
> bug to 'dkms').

Correct.

I've set this forwarded to a related bug ("dkms autoinstall fails on
modules not built due to BUILD_EXCLUSIVE_*")

> esp. what is the use of the BUILD_EXCLUSIVE_KERNEL directive, if it
> triggers a hard failure? why should i ever set the directive, if I could
> just rely on the build process to fail?

IMHO, this error logic in dkms is seriously flawed. But at least we are
now at a better state than before where sometimes (always?) errors (real
errors like failing to build a module that really should be built) did
not propagate to the exit status, but only showed up as a line of text
somewhere in the middle of the (dist-)upgrade log ...
We have (had?) a piuparts report if these show up in a passing test ...

> i would therefore ask the dkms maintainers to consider making
> 'BUILD_EXCLUSE_KERNEL' a soft-failure (that is ignored in the automatic
> case).

Not trivial.

Somehow this should be treated as a tristate "OK/SKIP/FAIL".

Or two booleans
Should-be-built? "OK/SKIP"
Did_build? "OK/FAIL"

And maybe a --try-building-excluded-modules flag for those that really
want these as errors.


Andreas

[IOhannes m zmoelnig]

On Sun, 19 Feb 2023 21:36:56 +0100 Andreas Beckmann <an...@debian.org> wrote:
> > i would therefore ask the dkms maintainers to consider making
> > 'BUILD_EXCLUSE_KERNEL' a soft-failure (that is ignored in the automatic
> > case).
>
> Not trivial.
>

ah, my naive assumption was that i could do something like this

```
diff --git a/etc/kernel/postinst.d/dkms b/etc/kernel/postinst.d/dkms
index c0b9cda..b1fc2ff 100755
--- a/etc/kernel/postinst.d/dkms
+++ b/etc/kernel/postinst.d/dkms
@@ -35,7 +35,17 @@ case "${uname_s}" in
esac

if [ -x
/usr/lib/etc/kernel/postinst.d/dkms/etc/kernel/postinst.d/dkms_autoinstaller
]; then
- exec
/usr/lib/etc/kernel/postinst.d/dkms/etc/kernel/postinst.d/dkms_autoinstaller
start "$inst_kern"
+
/usr/lib/etc/kernel/postinst.d/dkms/etc/kernel/postinst.d/dkms_autoinstaller
start "$inst_kern"
+ ret=$?
+ case $ret in
+ 9)
+ # ignore failures due to BUILD_EXCLUDE_...
+ ret=0
+ ;;
+ *)
+ ;;
+ esac
+ exit $ret
fi

if ! _check_kernel_dir "$inst_kern" ; then
```

(or something simpler).
which looks trivial enough.
i haven't tested it though.


and on second thought i see that the error-codes are used inconsistently
in dkms, and what's worse they are re-used.
"9" is used for:
- BUILD_EXCLUSIVE
- missing write permissions on tarball
- unable to install ... using rpm
- missing dkms.conf file

of course, according to errno.h, '9' is EBADF, aka "Bad file number",
which makes no sense in any of the cases.

sigh.

so i guess a good start would be to convince upstream to issue unique
(and hopefully meaningful) status-codes for the various errors...

gdmasr
IOhannes

[Andreas Beckmann]

On 20/02/2023 10.33, IOhannes m zmoelnig wrote:
> +    case $ret in
> +        9)
> +            # ignore failures due to BUILD_EXCLUDE_...
> +            ret=0

> which looks trivial enough.
> i haven't tested it though.

Even if you catch the error this way, if there are multiple modules to
be built dkms autoinstall will return early...

> so i guess a good start would be to convince upstream to issue unique
> (and hopefully meaningful) status-codes for the various errors...

77 sounds like a sensible return code for "SKIP".


Andreas