Hi!
On 2024-12-10 12:45, Masahiro Yamada wrote:
On Mon, Dec 9, 2024 at 5:31 PM Mihai Limbășan <mihai@xxxxxxxxxxx> wrote:
Hi!
Would like to report a DKMS build system impacting bug with kernel 6.12+
introduced in commit aaed5c7739be81ebdd6008aedc8befd98c88e67a . Hope I'm
addressing this following proper protocol by mailing linux-kbuild, tried
mailing the maintainer directly on 2024-11-20 but received no feedback;
my apologies otherwise, it's my first kernel bug report.
Sorry, I missed that.
Before you, another guy asked me the same question off-list.
Multiple people contacted me off-list for the same question.
Presumably, asking this in the ML is better because
other people may find the answer and avoid duplicated questions.
Oh my, not a problem. Initially approached directly to avoid potentially
bugging a lot of unrelated people, but you're absolutely right, easier
to find this way. Thank you!
Specifically, the commit changes scripts/package/install-extmod-build to
remove the shipped copy of the kernel configuration as .config in the
generated package. Unfortunately, this breaks DKMS when secure boot is
being used and any locally compiled the modules need to be signed. DKMS
needs it to extract various characteristics of the built kernel, among
which CONFIG_MODULE_SIG_HASH so that it can sign the .ko files it
creates. It's likely that it also uses various other symbols from the
kernel config, e.g. clang-related stuff, but I didn't test that.
The removal of the other formerly shipped files doesn't appear to cause
any problems, at least not in this scenario.
I do not think removal of the .config is a problem because
another copy, include/config/auto.conf exists in the package.
DKMS can parse "${kernel_source_dir}/include/config/auto.conf
for CONFIG options.
True. The problem I see with with that is that it unexpectedly breaks
the current behavior (even though admittedly there never was a formal
API contract in place) and requires an update to DKMS across *all*
distributions. I'll report a bug to upstream DKMS to this effect, but it
might take a long time to fix this, and many distros will likely not
backport a future DKMS fix to current or older-but-still-supported
versions, whereas re-including .config in the kernel headers package at
the cost of a 200-300kb .config copy would not let users of the mainline
kernel hanging, *and* would minimize the surprise factor.
From my testing, things seem to work perfectly well when creating a
relative symlink from "${kernel_source_dir}/.config" to
"include/config/auto.conf" -- maybe this could be a compromise solution?
It'd avoid shipping the extra noise from the full .config while at the
same time avoid breaking already-shipped DKMS versions.
Mind you, it's not like it's a big deal for me personally. It's just
that the behavior of the system as a whole with this issue in place is
thoroughly unintuitive: DKMS does *not* report an error nor does it fail
OOT module build. From an user point of view, what happens are problems
on the next system boot (potentially boot failure, depending on what
failure to load the OOT modules does), with module load failure messages
that initially give no clue as to the root cause. And since the use case
for DKMS here is *exactly* a set-and-forget approach to OOT module
building, it can take a *while* before people think to check the build
logs (if they even keep them) and somehow figure out that "Kernel config
${kernel_config} not found, modules won't be signed" means "upstream
changed the kernel headers package semantics".
Thanks,
Mihai
