This page needs urgent updating! It can lead to serious frustration and problems.

[BooniChan]

To whom it may concern,

There needs to be some included information in this page as to avoid errors and lots of frustration.

1 - It needs to state what can't be removed whilst configuring the kernel as not to break the build.
For example: In my journey to compile the kernel, I disabled debugging as I don't need it. Only to get an error after over 1hour compiling about BTF. I figured out that this has to do with debugging being disabled(even though it used to be acceptable, even in older guides) but I couldn't find any documentation anywhere how to make debain/rules binary skip the debugging. I read the scripts, read the whatever docs I Could find in the kernel, but there is barely any information on how to switch variables on/off and stuff like this, in the end, I had to re-enable debugging.
Solution: Either state that debugging is mandatory for debian/rules binary or state the proper way to disable it. (and of course any other mandatory options, since people are configuring their own kernel in this guide)

2 - Lack of documentation on options for your programs/scripts which ties with 1. For example, nowhere in this page is mentioned the options available for debian/scripts other than editconfigs and binary. No mention of binary-generic binary-perarch binary-headers etc etc, but more importantly:

3- doing debian/rules printenv shows a bunch of options, which reading some of the scripts I figured what they do, but no where is again explained how to change the variables and at which point(I figured some of them can be changed from debian.master). This could most probably solve the disabling debug issue too.

The debian/rules way of building the a custom kernel is great and from the looks of it it has quite a lot of customization options, and once it works it gives you ready made packages to install without issues, but that is pointless if there is no documentation showing these options and how to use them at all. Or if these docs exist, something should point to them on this page on how to build your own custom kernel.
I scoured the internet for hours trying to gather pieces of information from here and there, and still don't have the knowledge of all the options.

P.S: I wanted to edit the page myself to add some of the things I discovered for other users, but it's not a simple wiki page and it's more time consuming for someone who's not an editor on here.
P.S This is not my first time building a kernel, just my first time doing it with the debian/rules method described on this page. I'm coming from arch linux and had to use ubuntu for some time to test some things so I wanted to help in sharing this info of problems/suggestions.

Regards,

---

Reported from: https://canonical-kernel-docs.readthedocs-hosted.com/latest/how-to/develop-customise/build-kernel/

[AnneCYH]

hey @BooniChan ,

Thank you for reaching out to us and we appreciate that you took the time to let us know about your experience with our documentation.

I don't have any immediate answers to any of your issues / suggestions but I have reached out to the rest of the kernel team to take a look at the feedback you've provided here. We'll get back to you as soon as we can!

In the meantime, please do know that you are free to contribute. Yes this is not a Wiki but we definitely appreciate it if you'd like to contribute to the docs. You could start with a small edit -- for example, a disclaimer added to the docs that debugging is mandatory ( i don't know if this is the case but just using your feedback as an example -- and do so through a PR. Let me know if you need any help getting started there but definitely don't be shy if you want to suggest edits :)

Thanks again and do stay tuned.

[BooniChan]

Hi Anne, Hope this email finds you well and thank you for reaching out. My suggestions are basically the ones I've sent in my original email, my intention was to suggest a few things that could be done, but to summarise : - Make a list of kernel config options that are mandatory for the kernel to compile and package with debian/rules script. - Make a list of the options/switches/settings the debian/rules script can take during compilation and packaging other than 'debian/rules binary' -IF these things are already written somewhere, just make them accessible/point to them on the official kernel doc page so anyone who follows that doc has access to them. As an example: Point out to debian.master/rules.d/<arch> files where some options can set and to using the command 'debian/rules printenv' to see some of the variables currently set. I know there's the option to compile the kernel the traditional way with 'make' but since the official guide offers a way to do it the ubuntu way in .deb packages why not offer all the options available? In regards to editing, unfortunately it requires too much work just to contribute a single edit that's why I shared my contribution by email, it's not a simple 'edit page' - and I still don't know all the options available so I'm sure someone on the team could do wayy of a better job since all I've discovered till now I've discovered it by trial and error. Thanks and regards,

…

On Tue, Jul 15, 2025 at 10:05 AM AnneCYH ***@***.***> wrote: *AnneCYH* left a comment (canonical/kernel-docs#74) <#74 (comment)> hey @BooniChan <https://github.com/BooniChan> , Thank you for reaching out to us and we appreciate that you took the time to let us know about your experience with our documentation. I don't have any immediate answers to any of your issues / suggestions but I have reached out to the rest of the kernel team to take a look at the feedback you've provided here. We'll get back to you as soon as we can! In the meantime, please do know that you are free to contribute. Yes this is not a Wiki but we definitely appreciate it if you'd like to contribute to the docs. You could start with a small edit -- for example, a disclaimer added to the docs that debugging is mandatory ( i don't know if this is the case but just using your feedback as an example -- and do so through a PR. Let me know if you need any help getting started there but definitely don't be shy if you want to suggest edits :) Thanks again and do stay tuned. — Reply to this email directly, view it on GitHub <#74 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL2JNNIMJNUGIHRZXV4A5Y33ISY4LAVCNFSM6AAAAACBHYYFYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZSGU3DCNRUGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>