#1070986 linux-source-6.7: Signing error building 6.7 custom kernel

#1070986#5
Date:
2024-05-12 14:53:00 UTC
From:
To:
Dear Maintainer,

I'm following the directions at the Kernel Handbook, "4.2. Building a custom kernel from Debian kernel source".

I apt-get installed: linux-source libncurses-dev pahole

I configured with:
$ make localmodconfig

and took defaults to any prompts.

I then ran:
$ make menuconfig

and turned on:
Kernel hacking->Generic Kernel Debugging Instruments->KGDB: kernel debugger (KGDB=y)

And finally, ran:
$ make bindeb-pkg

The kernel compiled, but then failed with:
  ...
  HDRINST usr/include/asm/types.h
  INSTALL debian/linux-libc-dev/usr/include
  SIGN    debian/linux-image/lib/modules/6.7.12/kernel/arch/x86/crypto/aesni-intel.ko
At main.c:298:
- SSL error:FFFFFFFF80000002:system library::No such file or directory: ../crypto/bio/bss_file.c:67
- SSL error:10000080:BIO routines::no such file: ../crypto/bio/bss_file.c:75
sign-file: debian/linux-image/lib/modules/6.7.12/kernel/arch/x86/crypto/aesni-intel.ko
make[6]: *** [scripts/Makefile.modinst:137: debian/linux-image/lib/modules/6.7.12/kernel/arch/x86/crypto/aesni-intel.ko] Error 1
make[5]: *** [Makefile:1844: modules_install] Error 2
make[4]: *** [Makefile:2059: run-command] Error 2
make[3]: *** [debian/rules:17: binary-arch] Error 2
ESC[1mdpkg-buildpackage: ESC[0mESC[1;31merrorESC[0m: make -f debian/rules binary subprocess returned exit status 2
make[2]: *** [scripts/Makefile.package:144: bindeb-pkg] Error 2
make[1]: *** [/home/virt/linux-source-6.7/Makefile:1560: bindeb-pkg] Error 2
make: *** [Makefile:246: __sub-make] Error 2

I did some digging, and it looks like it's trying to double-sign the .ko files. For example, earlier in the make output, it says:

run-command KBUILD_RUN_COMMAND=+./scripts/package/builddeb
  SYMLINK debian/linux-image/lib/modules/6.7.12/build
  INSTALL debian/linux-image/lib/modules/6.7.12/modules.order
  INSTALL debian/linux-image/lib/modules/6.7.12/modules.builtin
  INSTALL debian/linux-image/lib/modules/6.7.12/modules.builtin.modinfo
  INSTALL debian/linux-image/lib/modules/6.7.12/kernel/arch/x86/crypto/aesni-intel.ko
  SIGN    debian/linux-image/lib/modules/6.7.12/kernel/arch/x86/crypto/aesni-intel.ko
  XZ      debian/linux-image/lib/modules/6.7.12/kernel/arch/x86/crypto/aesni-intel.ko.xz

And ls shows the .xz file is there:
$ ls debian/linux-image/lib/modules/6.7.12/kernel/arch/x86/crypto/aesni-intel*
debian/linux-image/lib/modules/6.7.12/kernel/arch/x86/crypto/aesni-intel.ko.xz

So then when it tries to sign the .ko file again, it can't find it, because it's been compressed to .xz.

#1070986#10
Date:
2024-05-13 15:37:29 UTC
From:
To:
It has been a month and nobody did care on 6.6. I bet I may be identical
for 6.7.

NB : I reported other bugs as the localmodconfig options do not include
many rather basic options (ISO 9660, usb disks, ...).

This one can be fixed by adding the relevant config options...

#1070986#15
Date:
2024-05-13 22:16:49 UTC
From:
To:
This works in the 6.8.9 upstream kernel. So I guess the good news is it wil be fixed in Debian eventually.
#1070986#20
Date:
2024-05-14 08:08:58 UTC
From:
To:
As title says, this is a bug in debian additionnal scripts to build the
packages, not upstream.

Using upstream code works but does not produce package and knowing
exacltly the minimal kernel setup for debian is not obvious.

Once you have a working .deb you can probably reuse the .config.

#1070986#25
Date:
2024-05-14 21:39:49 UTC
From:
To:
It's actually upstream. I ran the same:

  $ make bindeb-pkg

on the upstream source as I did on the Debian source, and yes, it gave me .deb packages.

Here's the repo for the upstream script that was part of the problem:

https://github.com/torvalds/linux/commits/master/scripts/package/builddeb

Note the recent changes.

I may be wrong, and it's a Debian patch that is causing the problem, but from what I've seen of the code it's
probably upstream. I suppose I could download an upstream version of 6.7, and verify it has the same problem,
but since nobody on the Debian maintainer side seems to care, I won't bother.

#1070986#30
Date:
2024-05-15 09:15:51 UTC
From:
To:

Okay. A workorange is explained there. If you do not need debug info for
example. You can also look at the new script to see if it changed
something for removing debug information for stripped modules.