On Tue, Dec 10, 2024 at 8:08 PM Mihai Limbășan <mihai@xxxxxxxxxxx> wrote:
>
> 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.
This is a problem only when users replace the distro kernel
with the upstream one.
Distributions do not use scripts/package/install-extmod-build.
> 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
The linux-headers package is intended to provide the necessary tools
for building external modules.
The .config file is not required for building external modules,
so it was removed.
This is an issue with DKMS.
Furthermore, I do not understand why they decided to allow the process
to proceed successfully when the file DKMS requires is missing:
https://github.com/dell/dkms/blob/93bf2bd79704c0a8a39b240a52b001610cdc419b/dkms.in#L1026
They need to fix the issue in DKMS.
--
Best Regards
Masahiro Yamada
