Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #91966 > unrolled thread

generating linux-image-${VERSION}-amd64 locally

Back to article view | Back to linux.debian.kernel

Contents

  generating linux-image-${VERSION}-amd64 locally Piotr Morgwai Kotarbinski <foss@morgwai.pl> - 2026-04-09 01:00 +0200
    Re: generating linux-image-${VERSION}-amd64 locally Ben Hutchings <ben@decadent.org.uk> - 2026-04-10 15:00 +0200
      Re: generating linux-image-${VERSION}-amd64 locally Ben Hutchings <ben@decadent.org.uk> - 2026-04-10 17:40 +0200
        Re: generating linux-image-${VERSION}-amd64 locally Piotr Morgwai Kotarbinski <foss@morgwai.pl> - 2026-04-11 00:40 +0200

#91966 — generating linux-image-${VERSION}-amd64 locally

Hello Debian Kernel Team,

Recently I needed to build packages for the latest mainline kernel to post some logs to kernel.org bugzilla (https://bugzilla.kernel.org/show_bug.cgi?id=221319). I followed the kernel handbook (chapter 4 mainly) and it generally went pretty smoothly and I posted a mini-howTo on Debian Forums: https://forums.debian.net/viewtopic.php?t=166381

The only bit that I'm missing is generating `linux-image-${VERSION}-amd64`, so to work-around this, after installing the built packages, I manually call `linux-run-hooks image postinst`. From what I understand, `linux-signed` / `linux-image-${VERSION}-amd64` is generated by Debusine based on `linux-image-amd64-signed-template`, so I was wondering if:

a) ...I can fake this process somewhat and generate `linux-image-${VERSION}-amd64` locally using some scripts and ideally also sign the kernel for example with my dkms MOK, or...

b) ...if the above is over-complicated or not feasible, is it sufficient (for the purpose of setting-up / cleaning-up of kernel images) to create a dummy package that depends on `linux-binary` (and others) with maintainer-scripts generated from `debian/templates/image.p*` templates? If so, is there an easy to use script or a `make` rule to generate these maintainer-scripts from these templates?

Many thanks

  Morgwai

[toc] | [next] | [standalone]

#91967

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2026-04-09 at 00:12 +0200, Piotr Morgwai Kotarbinski wrote:
> Hello Debian Kernel Team,
> 
> Recently I needed to build packages for the latest mainline kernel to post some logs to kernel.org bugzilla (https://bugzilla.kernel.org/show_bug.cgi?id=221319). I followed the kernel handbook (chapter 4 mainly) and it generally went pretty smoothly and I posted a mini-howTo on Debian Forums: https://forums.debian.net/viewtopic.php?t=166381

It is much easier to use "make bindeb-pkg" for this, instead of the
Debian official packaging (section 4.2 in the handbook).

> The only bit that I'm missing is generating `linux-image-${VERSION}-amd64`, so to work-around this, after installing the built packages, I manually call `linux-run-hooks image postinst`. From what I understand, `linux-signed` / `linux-image-${VERSION}-amd64` is generated by Debusine based on `linux-image-amd64-signed-template`, so I was wondering if:
> 
> a) ...I can fake this process somewhat and generate `linux-image-${VERSION}-amd64` locally using some scripts and ideally also sign the kernel for example with my dkms MOK, or...
> 
> b) ...if the above is over-complicated or not feasible, is it sufficient (for the purpose of setting-up / cleaning-up of kernel images) to create a dummy package that depends on `linux-binary` (and others) with maintainer-scripts generated from `debian/templates/image.p*` templates? If so, is there an easy to use script or a `make` rule to generate these maintainer-scripts from these templates?

I have used this workaround myself recently, but this will likely stop
working in the near future.

If you actually want to sign the kernel images yourself, you can see how
to do that in done in debian/salsa-ci.yml.  Otherwise you should disable
signing of the image by editing debian/config/amd64/defines.toml and
regnerate debian/control before starting the build.

I will try to update the instructions in the kernel handbook soon.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.

[toc] | [prev] | [next] | [standalone]

#91972

[Multipart message — attachments visible in raw view] — view raw

On Fri, 2026-04-10 at 14:58 +0200, Ben Hutchings wrote:
[...]
> I will try to update the instructions in the kernel handbook soon.

I opened
<https://salsa.debian.org/kernel-team/kernel-handbook/-/merge_requests/11>
for this (and one other change).  Could you review the new text there?

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.

[toc] | [prev] | [next] | [standalone]

#91976

Thanks for your reply! :)
(almost missed it as you replied only to the list ;-) )

> On Thu, 2026-04-09 at 00:12 +0200, Piotr Morgwai Kotarbinski wrote:
>> Hello Debian Kernel Team,
>> 
>> Recently I needed to build packages for the latest mainline kernel to post some logs to kernel.org bugzilla (https://bugzilla.kernel.org/show_bug.cgi?id=221319). I followed the kernel handbook (chapter 4 mainly) and it generally went pretty smoothly and I posted a mini-howTo on Debian Forums: https://forums.debian.net/viewtopic.php?t=166381
> 
> It is much easier to use "make bindeb-pkg" for this, instead of the
> Debian official packaging (section 4.2 in the handbook).

For the latest mainline version I needed to go through combination of 4.6+4.7 anyway and then 4.5.4/4.5.5 way spared me messing with the config and personally I found it much simpler this way.



>> The only bit that I'm missing is generating `linux-image-${VERSION}-amd64`, so to work-around this, after installing the built packages, I manually call `linux-run-hooks image postinst`. From what I understand, `linux-signed` / `linux-image-${VERSION}-amd64` is generated by Debusine based on `linux-image-amd64-signed-template`, so I was wondering if:
>> 
>> a) ...I can fake this process somewhat and generate `linux-image-${VERSION}-amd64` locally using some scripts and ideally also sign the kernel for example with my dkms MOK, or...
>> 
>> b) ...if the above is over-complicated or not feasible, is it sufficient (for the purpose of setting-up / cleaning-up of kernel images) to create a dummy package that depends on `linux-binary` (and others) with maintainer-scripts generated from `debian/templates/image.p*` templates? If so, is there an easy to use script or a `make` rule to generate these maintainer-scripts from these templates?
> 
> I have used this workaround myself recently, but this will likely stop
> working in the near future.

In the mean time I've written a small script for this, but editing debian/config/amd64/defines.toml seems like a much better way.



> If you actually want to sign the kernel images yourself, you can see how
> to do that in done in debian/salsa-ci.yml.  Otherwise you should disable
> signing of the image by editing debian/config/amd64/defines.toml and
> regnerate debian/control before starting the build.

Editing debian/config/amd64/defines.toml works great: thanks! :)
I'll have a look at debian/salsa-ci.yml later, but signing is not critical for me.



> On Fri, 2026-04-10 at 14:58 +0200, Ben Hutchings wrote:
> [...]
>> I will try to update the instructions in the kernel handbook soon.
> 
> I opened
> <https://salsa.debian.org/kernel-team/kernel-handbook/-/merge_requests/11>
> for this (and one other change).  Could you review the new text there?

I've left a few minor comments.


Many thanks for explaining all this! :)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web