I want to rebuild the kernel, adding a custom patch on top of the current kernel. As far as I understand, this is something the Kernel Manager should help with.
However, there are a couple of things I don’t understand using this tool, and hope somebody here can shed a little more light on my ignorance.
So I’m currently using the kernel 6.17.0-3, which is visible with uname and also shown as selected in the Kernel Manager. How can I rebuild that particular version with the Kernel Manager, with just my patch added?
When I select a kernel version (i.e. highlight one row in the manager), and click “configure”, the options shown in the “configure” dialog do not seem to correspond to the selected kernel, i.e. the button seems to be independent of the selected row, can you confirm? In my naive understanding I expected that the “configure” dialog would refer to the selected kernel version. So how can I make sure that I’m using the same options as the selected kernel or the currently running kernel? Is this done with the checkbox “use the current kernel’s configuration”?
Another question: When I build the kernel using that button, it builds 6.17.0-2 instead of the currently installed and selected 6.17.0-3 - why is that?
Thanks in advance for some explanations or pointers to a detailed documentation of the Kernel Manager if there is any.
Kernel manager just edits some options in the PKGBUILD. I think the easiest approach, instead of looking for options in the kernel manager, is just to edit the PKGBUILD. This is also future proof, since you can just automate the PKGBUILD editing to add the patches you want. All cachyos PKGBUILD are available here
you need to download the config as well (or provide your own). To build the kernel, you just edit the PKGBUILD, then run makepkg. makepkg supports various flag to skip integrity check if you need to edit the file, or to stop after various phases of the building process, if you need to manually edit something before you understand how completely automate the workflow with PKGBUILD. It is just bash .
Thank you @Ma_1900. So I would just add source+=/path/to/my/patch and makepkg? But I noticed i similar problem here, it also builds a package with a lower release number, why? I pulled the latest commits and even when I build using the main branch it’s lower than what is installed.
Basically yes, you may want to add the patch at the correct point.
I am not sure what version number you get. The main cachyos kernel PKGBUILD
is at 6.17.0 which the same version of the upstream kernel.org. I do not see how you can have a more recent version, there is not yet 6.18rc published upstream. I mean on cachyos you literally get the latest kernel tested and patched within one or two days from the kernel.org publication, including incremental builds. Maybe you can complain it is not the most stable and tested release, but certainly it is not an old version.
Right now even the pkgrel, namely the small number you see at the end of kernel version, e.g. 6.17.0-3, (this is an internal versioning, it is not assigned upstream) is the same as on the cachyos repo. In general you can ignore the pkgrel, it is exactly the same source code from the kernel, just there can be some very minor fix.
Yes, I was talking about the pkgrel (the release counter after the dash). When I build from the 3.17 branch, I get -1, when I build from main, I get -2, but installed is already -3. I just wonder why this is the case, since I expected to get the same release number as upstream and wanted to make sure I don’t miss something.
Right now on the repo I see -3 as well, and just two days ago the github repo was actually ahead of the cachyos official repo release. It is a matter of hours usually, the time they compile or push a commit to github.
As for the pkgrel, you should mostly ignore it unless some update breaks your system and then maybe some minor fix works for you. These are mostly minor bug fixes from cachyos, about their own code not the kernel. For all the good work the mantainers do, the kernel is likely the most advanced and complex piece of software in existence, and the main updates/changes/improvements/gains are done upstream, when kernel.org publishes a new version. The kernel has a solid and experimented release cycle, and updates of the kernel are released every week bound for problems. cachyos then updates their PKGBUILD, usually within hours or 1 or 2 days at worse. You need to leave un unstable kernels (a bad idea) to be more updated than that.