Compile a Linux kernel module

[RoGeorge]

The goal is to make a very small change in a .c file about the driver of a soundcard (CA0132), then to compile and make the current kernel to load the modified module.

I've googled already but I don't have a bird-eye view of the whole process, so I can not make sense of the details I found online about how to recompile the kernel (or just a single loadable module).  I could try one of the many recipes out there, and eventually one will work, but I would like to also understand what I'm doing.

I'm confused about
- where from to get the sources+headers, and what versions
- what differences are between using dkms-get sources vs. apt install
- also about using git vs downloading an archive with the sources

The OS is Ubuntu 20.04 LTS, AMD64, and I want to compile the module for the stable kernel version that is already installed, not for the nightly builds or for beta versions of kernels.

I would prefer to use git, so to be able to make a pull request in case the changes will be successful.

So far my plan is to add a new quirk definition for the ID of my card, which is "1102 0011", and by looking inside the Windows drivers, it's name seems to be "Sound Blaster Recon3Di", the chip is ca0132 Creative Sound Core3D.  It's the onboard sound for the motherboard AsRock model "Fatal1ty Z97 Professional".  I could see a Quirk in the sources for another Recon3Di card with the ID 1102 0010, and want to try the same quirk (a quirk here = custom settings) for my card ID with the ID 1102 0011.  If I could only flip that bit 

Also, I don't really know what I'm doing, so any other advice (except buy a new soundcard) is welcome.

Code: [Select]

~$ sudo apt update
~$ uname -a
Linux zub 5.15.0-41-generic #44~20.04.1-Ubuntu SMP Fri Jun 24 13:27:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

~$ find / -path "*/wd8TB/*" -prune -o -iname "*ca0132*.ko" -print 2>/dev/null
/usr/lib/modules/5.13.0-52-generic/kernel/sound/pci/hda/snd-hda-codec-ca0132.ko
/usr/lib/modules/5.15.0-41-generic/kernel/sound/pci/hda/snd-hda-codec-ca0132.ko

~$ apt list linux-source*
Listing... Done
linux-source-5.4.0/focal-updates,focal-updates,focal-security,focal-security,now 5.4.0-122.138 all [installed,automatic]
linux-source/focal-updates,focal-updates,focal-security,focal-security,now 5.4.0.122.123 all [installed]

~$ uname -r
5.15.0-41-generic

The file I want to modify is related with this bug that was fixed by Connor McAdams https://bugzilla.kernel.org/show_bug.cgi?id=109191#c66 and his fix is already in the kernel, except that my card has a slightly different ID which I need to add.

To be more precise, the file I plan to change corresponds to this one (but for my Unbuntu kernel/version):
https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_ca0132.c


My understanding so far is that Ubuntu kernel has particular patches and configs that are specific to Ubuntu, so I can not just use any 5.15.0-41-generic Linux, it has to be from Ubuntu, but I'm not sure.

What sources do I need, from where, and with what command(s) do I get them please?

[ve7xen]

Ubuntu does apply their own patch sets, but these shouldn't change the kernel ABI, so a module built against the official source tree should (I think) still load in the corresponding Ubuntu kernel.

The process to build a single in-tree module is pretty straightforward. You will need the kernel source tree (e.g. from apt source) and your running kernel configuration file (in Ubuntu I believe this should be available as /boot/config-<version>). Place the config file as .config in the root of the source tree. Then you can simply do (from the root of the kernel source tree):

Code: [Select]

make prepare
make modules_prepare
make M=sound/pci/hda/

And you will find the .ko files in sound/pci/hda, which you can load or install manually. I believe you can also do

Code: [Select]

make M=sound/pci/hda/ modules_install to install just that module, but I'm not totally sure about that.

[magic]

If I could only flip that bit 

You can, with a hex editor, which may be the fastest option. Note that you are on a little-endian machine, so byte order in those numbers may be reversed.

Obtaining the source corresponding to your installed package, kernel or otherwise, is a Ubuntu-specific question which you need to solve somehow.

Configuration of the running kernel may be available in /proc/config.gz; if not, see if it's included in the Ubuntu kernel source package/tarball/repository; or install linux-headers (make sure it's same version as your kernel) and then look for /lib/modules/`uname -r`/build/.config .

If you have the full kernel source unpacked somewhere, I think it should be as simple as putting the .config there and

Code: [Select]

make sound/pci/hda/snd-hda-codec-ca0132.ko
I wouldn't try to install the modified module, just reload. If it refuses to unload, close processes using it.

I'm not 100% if the instructions above are corrrect, it seems ve7xen tries to build a module inside the kernel source directory as an out-of-tree module, I have never tried such things. Not sure if modules_install will put it under /extra/ or overwrite the distribution's module in /kernel/ (both are subdirectories of /lib/modules/`uname -r`/). Did I say I would just reload it without installing?

[langwadt]

https://smallbusiness.chron.com/compile-modules-ubuntu-52622.html ?

[RoGeorge]

Not sure if poking bits inside binaries would still work.  I suspect the modules nowadays are cryptographically signed, but I digress.

Back to Ubuntu  sources, got them like this:

Code: [Select]

        # https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide
       
        mkdir kernel
        cd kernel

        # Ubuntu 20.04 LTS is named Focal Fossa, so the /focal at the end
        git clone git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal
        # !!! git downloaded 1.95 GiB of sources       
        cd focal
       
        uname -r
            5.15.0-41-generic
        # each version has a tag, to list all available versions
        git tag -l *5.15.0-41*
            Ubuntu-hwe-5.15-5.15.0-41.44_20.04.1
       
        # make a new branch 'temp' with the desired version
        git checkout -b temp Ubuntu-hwe-5.15-5.15.0-41.44_20.04.1
       
        # search for the patch to be modified
        find ./ -iname *ca0132*
            ./sound/pci/hda/patch_ca0132.c
            ./sound/pci/hda/ca0132_regs.h


[Nominal Animal]

Quick guide for fixing a module in the currently running kernel in Debian derivatives:

In a directory where you want to do your kernel stuff, run
    apt source linux-kernel-`uname -r`
    apt source linux-modules-`uname -r`
to obtain the sources for the current kernel and its modules, and
    cd linux-[0-9]*/
    cp /boot/config-`uname -r` .config
to enter the kernel tree and copy the configuration used to build the running kernel.  Run
    sudo apt install build-essential fakeroot
    sudo apt build-dep linux-kernel-`uname -r`
    sudo apt build-dep linux-modules-`uname -r`
to install all development packages you might need when building the kernel and/or modules.  (There's a lot of stuff, including Java Runtime, probably due to OpenJade used in some documentation generation options.)

(Instead of actual package names, you can also just use the name 'linux', but I never remember such details.)

Next, use your favourite editor to edit the sources, apply patches, et cetera.

Then, in the same kernel root directory as you cd'd to above, run
    make sound/pci/hda/
    make sound/pci/hda/snd-hda-codec-ca0132.ko
You can remove its debug symbols via e.g.
    strip --strip-debug sound/pci/hda/snd-hda-codec-ca0132.ko
to make it smaller, or leave it be.

You can now try the new module:
    sudo rmmod snd-hda-codec-ca0132
    sudo insmod sound/pci/hda/snd-hda-codec-ca0132.ko
If you are satisfied by it, just replace original with the new modified one,
    sudo install sound/pci/hda/snd-hda-codec-ca0132.ko /lib/modules/`uname -r`/kernel/sound/pci/hda/
At this point, you can just remove the entire kernel tree, about 1.3 GiB as of 5.4.0.  I would still keep this guide, and the patch/changes you make to the files, in a text file so you can redo them for every new kernel you switch to, until the changes are included upstream.

(I did verify this works in Mint 20.04.  Do let me know if there are any typos, or forgot to mention a step, though.)

You can also build a complete set of "fixed" packages, but for that, I'd switch to using upstream sources and going by the Debian Linux Kernel Handbook.

[magic]

Not sure if poking bits inside binaries would still work.  I suspect the modules nowadays are cryptographically signed, but I digress.

If it's signed, your custom compiled module won't load either.
If you have the private key, re-sign the edited version. But I guess, at that point, it may be similar effort to compiling using the official build system. Or, at any rate, I don't know how to do it manually yet.

In a directory where you want to do your kernel stuff, run
    apt source linux-kernel-`uname -r`
    apt source linux-modules-`uname -r`

Not sure if I want to know the difference between these two

install all development packages you might need when building the kernel and/or modules.  (There's a lot of stuff, including Java Runtime, probably due to OpenJade used in some documentation generation options.)

LOL.
Alternatively, just run make and if it fails, install the missing program or two. Realistically, you need make, gcc and maybe a few basic Linux utilities that are likely already installed on your system, or should be anyway if they aren't yet.

Then, in the same kernel root directory as you cd'd to above, run
    make sound/pci/hda/
    make sound/pci/hda/snd-hda-codec-ca0132.ko

IIRC, the first line will just build everything in the HDA driver directory. I don't think it's necessary or useful.

If you are satisfied by it, just replace original with the new modified one,
    sudo install sound/pci/hda/snd-hda-codec-ca0132.ko /lib/modules/`uname -r`/kernel/sound/pci/hda/

IIRC, you can install modules in some special subdirectories other than /kernel/ and in some cases your module may even shadow the one in /kernel/, without deleting it.

[Nominal Animal]

In a directory where you want to do your kernel stuff, run
    apt source linux-kernel-`uname -r`
    apt source linux-modules-`uname -r`

Not sure if I want to know the difference between these two

Typo.  First one was supposed to be linux-image-`uname -r`, containing the stuff needed (later on) if you want to sign the kernel.  The latter obtains the Linux source tree.

Note that I was not writing about "how you can fix your ca0132 hda codec kernel module", I'm writing about how to go about it in general.
Even if you switch from the kernel to some application or service, there's very little one needs to change.

I'm sure you prefer simple recipes that are unique to each package that do nothing extra, but I just don't care to memorize such crap.
And yes, I do do Linux kernel development myself.  It's just that each Linux distribution varies a bit on exactly how to duplicate already installed kernels; although all Debian variants share the basic procedure.

You know, magic, you come across as quite the asshole.  No matter how good work you might do (which, well, based on your attitude, is unlikely –– I'm sure you're capable; I just don't think you actually ever really bother), I for sure would not like to work with you, ever.  You somehow manage to be very annoying, even when you try to help.  Are you a teenager?  That would explain a lot.

install all development packages you might need when building the kernel and/or modules.  (There's a lot of stuff, including Java Runtime, probably due to OpenJade used in some documentation generation options.)

LOL.
Alternatively, just run make and if it fails, install the missing program or two. Realistically, you need make, gcc and maybe a few basic Linux utilities that are likely already installed on your system, or should be anyway if they aren't yet.

That depends.  If you feel comfortable walking blind in the dark and hope that fixing whatever errors you get will get you there, be my guest.  I do not.

And in general, I'm not the type that tells people to install packages until something works, I prefer to tell them how to install the set that the distribution maintainers have deemed relevant.

Then, in the same kernel root directory as you cd'd to above, run
    make sound/pci/hda/
    make sound/pci/hda/snd-hda-codec-ca0132.ko

IIRC, the first line will just build everything in the HDA driver directory. I don't think it's necessary or useful.

It is intentional, and useful.  Although kernel configuration is tested by compile farms in random configurations, it is quite possible for a specific kernel module that depends on other kernel modules to not compile solo cleanly, unless those others are compiled first.  (Because the Makefiles are written by humans who often make rather funny assumptions.)  In this case, snd-hda-codec-ca0132.ko does compile cleanly alone.

IIRC, you can install modules in some special subdirectories other than /kernel/ and in some cases your module may even shadow the one in /kernel/, without deleting it.

Yes, and no.  Yes, you can do that by modifying modprobe config (see man 5 modprobe.d) but it won't affect things like initrd creation (if you happen to do your own configuration and have the driver loaded there, say if you need the machine to make (yuk!) startup noise).

You can trivially make rmmod snd-hda-codec-ca0132 ; insmod /path/to/snd-hda-codec-ca0132.ko into a systemd init module, so it's run at boot time, too.

Just replacing the existing one (assuming a typical unsigned kernel module) is easier.  If you want to revert it, all you need to do is run
    apt reinstall $(dpkg-query -S /lib/modules/`uname -r`/kernel/sound/pci/hda/snd-hda-codec-ca0132.ko | cut -d ':' -f 1)
where the dpkg-query -S path-to-file | cut -d ':' -f 1 provides the package name that "owns" the specified file.  In this case, it will be linux-modules-extra-`uname -r`.  So, it's not like overwriting the existing module file is somehow irreversible.


If one wanted to (re)build the entire (unsigned) kernel and modules, there are three options.  One is to run
    fakeroot debian/rules binary
in the kernel directory (that my short guide cd'd into).  This can be used to build .deb packages whenever the project does contain the Debian tooling in debian/.  The second is to use debuild from the Debian devscripts package,
    debuild -b -uc -us
to build only the binary packages, unsigned, for the package corresponding to the current directory.  It basically runs the former as one step, but also does stuff like change the package info to match the build user and so on.  This is the command I normally reach for in Debian derivatives.  The third is to run
    make deb-pkg
since the kernel Makefile contains the deb-pkg target needed.

In any case, one should do a small modification when copying over the current configuration:
    cp /boot/config-`uname -r` .config
    sed -e 's|^\(CONFIG_MODULE_SIG[_A-Z0-9]*\)=y$|\1=n|' -e 's|^\(CONFIG_MODULE_SIG[_A-Z0-9]*\)=".*$|\1=""|' -i .config
to disable module signing, and
    sed -e '/debian/ s|^\(CONFIG_SYSTEM_[A-Z]*_KEYS\)=.*$|\1=""|' -i .config
to remove the canonical certificate list (debian/canonical-certs.pem) and revoked certificates list (debian/canonical-revoked-certs.pem) from being embedded in the kernel, since they are not included in the kernel sources, and the build will fail in one of the certs/ targets otherwise.
You can run e.g. diff -U 0 /boot/config-`uname -r` .config to see exactly what changes the above does.

The packages will appear in the parent directory.  (These commands are always run in the topmost directory belonging to the sources, the topmost one extracted when the sources are downloaded and patches applied; i.e. in linux-5.4.0/ for example.)

[magic]

If you feel comfortable walking blind in the dark and hope that fixing whatever errors you get will get you there, be my guest.

Yes, I feel comfortable compiling C software with make and fixing problems like make: /usr/bin/perl: no such file or directory, which is about the worst you could encounter while building a stupid kernel module

Then, in the same kernel root directory as you cd'd to above, run
    make sound/pci/hda/
    make sound/pci/hda/snd-hda-codec-ca0132.ko

IIRC, the first line will just build everything in the HDA driver directory. I don't think it's necessary or useful.

It is intentional, and useful.  Although kernel configuration is tested by compile farms in random configurations, it is quite possible for a specific kernel module that depends on other kernel modules to not compile solo cleanly, unless those others are compiled first.  (Because the Makefiles are written by humans who often make rather funny assumptions.)  In this case, snd-hda-codec-ca0132.ko does compile cleanly alone.

Okay, so it's your defense against Makefile bugs that you have encountered at some point in the past. In such case, I would clearly state that it's the second line which does the business and that the first may help in case of particular problems, or it may not, because perhaps make sound/ would be necessary or whatever. You made it look like this is the right process, but it is not.

I'm sure you prefer simple recipes that are unique to each package that do nothing extra, but I just don't care to memorize such crap.

I just happen to know how to build kernel modules. THB, I would grab the C file from relevant repository's web interface and build the module out of tree. It's a job that's distribution-agnostic (save for locating the source and installing linux-headers) and takes five minutes. Add another five for figuring out signing, if it's in use on given distribution, which should be well documented somewhere because building OoT modules is a common use case.

BTW, if your distribution enforces package signatures and doesn't publish its private key, you are screwed anyway without rebuilding the whole kernel and rebooting. I'm not up to date with all that signing drama (I run my own kernel builds) but I know how crypto works.

[Nominal Animal]

I just happen to know how to build kernel modules.

I doubt it.  I believe you get paid to compile out of tree kernel modules for someones private fork, but that's it.

I know how crypto works.

Extremely unlikely, based on the content of your posts thus far.

[magic]

I haven't been paid for anything involving Linux in over a decade and you are welcome to keep doubting whatever you want. It's you guys who will spend a week on this project.

edit
BTW, I'm not blaming the OP. You guys are fucked, being Linux beginners in the era of Ubuntu, with layers upon layers of "abstraction" and the all-prevailing culture of "tutorials" (written by people who have just learned something, barely enough to cover their narrow need) and askubuntu.com answers to OPs who don't even know what to ask, and hardly any competent documentation, particularly one detailed enough to described the overall architecture of the system and the rationale (if there was any) for the design decisions. Back in the day at least there was TLDP.

This is what I really hate Ubuntu for, basically for a decade of being forced to append -ubuntu to all my Google queries about anything to do with Linux.

[Nominal Animal]

Perhaps you should take a minute and consider what might be the reason why most members tend to completely disregard your posts.
I'll give you a hint: the "Ignore list" facility this forum provides is most definitely involved.

[magic]

You aren't going to use it because you will want to meticulously read all my posts and ensure I'm not recommending anything wrong or dangerous

[DiTBho]

Life seems easier to me with Vanilla sources
(most likely not, but today I want to think so)

[RoGeorge]

Thank you all for the replies, having more examples helped a lot to understand what has to be done.

However, tried yesterday to modify the module until early hours, and failed.
Eventually the module compiled, but the kernel requires signed modules, couldn't load it, so I gave up!

The rest is ranting.


Most of the frustration was from fighting against Ubuntu, not from the sound module.  By the way, PPA repositories for sources are not enabled by default in Ubuntu, that's why apt was showing no kernel sources, but either by using repository sources, or by using manually cloned sources from git, it was not possible to build only the modules, without the whole kernel.

Another ugly thing (looks like a bug to me) was because of tex-common (needed by other tools that are required to make/build from sources) Tex was a nightmare and refused to install, only to find some obscure answer that it will install if I change the locale to en utf8.  It seemed to me that some perl scripts were failing to install tex when mixed locale settings are in use (I have US English utf8, but I was using some other locales for dates and numbers, so I can see english but with ISO format for datetime and non comma (custom) thousand separators for numbers.  Once I set all to En Us Utf8, I could finally install all the build tools:

Code: [Select]

sudo apt-get install libncurses-dev flex bison openssl libssl-dev dkms libelf-dev libudev-dev libpci-dev libiberty-dev autoconf
To enable the repository for sources, either edit the /etc/apt/sources.list, or from GUI (Updates & Software tool) check the "Sources" checkbox.  For my Ubuntu, this how the sources.list (filtered) looked like after enabled the sources from GUI:

Code: [Select]

        cat /etc/apt/sources.list | grep deb-src
            deb-src http://archive.ubuntu.com/ubuntu focal main restricted #Added by software-properties
            deb-src http://ubuntu.mirrors.linux.ro/archive/ focal restricted universe multiverse main #Added by software-properties
            # deb-src http://ro.archive.ubuntu.com/ubuntu/ focal main restricted
            deb-src http://ubuntu.mirrors.linux.ro/archive/ focal-updates restricted universe multiverse main #Added by software-properties
            # deb-src http://ro.archive.ubuntu.com/ubuntu/ focal-updates main restricted
            # deb-src http://ro.archive.ubuntu.com/ubuntu/ focal universe
            # deb-src http://ro.archive.ubuntu.com/ubuntu/ focal-updates universe
            # deb-src http://ro.archive.ubuntu.com/ubuntu/ focal multiverse
            # deb-src http://ro.archive.ubuntu.com/ubuntu/ focal-updates multiverse
            deb-src http://ubuntu.mirrors.linux.ro/archive/ focal-backports main restricted universe multiverse #Added by software-properties
            # deb-src http://ro.archive.ubuntu.com/ubuntu/ focal-backports main restricted universe multiverse
            # deb-src http://archive.canonical.com/ubuntu focal partner
            deb-src http://ubuntu.mirrors.linux.ro/archive/ focal-security restricted universe multiverse main #Added by software-properties
            # deb-src http://security.ubuntu.com/ubuntu focal-security main restricted
            # deb-src http://security.ubuntu.com/ubuntu focal-security universe
            # deb-src http://security.ubuntu.com/ubuntu focal-security multiverse
            # deb-src http://dl.winehq.org/wine-builds/ubuntu/ focal main
            # deb-src https://paulcarroty.gitlab.io/vscodium-deb-rpm-repo/debs/ vscodium main

The rest of the tries were done in two separate Ubuntu kernel sources (not vanilla Linux), one from git, one from Ubuntu repos.  First, all the kernel has to build, or else the modules will miss "Module.symvers", which is only build at a full make, which on my hardware and with -j8, a full kernel compile takes about 2 hours first time.  Subsequent compilations or only modules takes only minutes.  I've read some other distros (e.g. OpenSUSE) have a package that includes "Module.symvers", but couldn't find any such package for Ubuntu, so I had to compile the full kernel

Unfortunately, the kernel modules in my Ubuntu are signed.  I had to generate my own keys.

In the end my "snd-hda-codec-ca0132.ko" didn't load, even when manually copied in "/lib/modules/5.15.0-41-generic/kernel/sound/pci/hda/snd-hda-codec-ca0132.ko" then rebooting.  Secure boot is not enabled in the motherboard's BIOS, and by looking at the kernel config, it looks like the kernel should accept self-signed modules.

The module "snd-hda-codec-ca0132.ko" built from repository sources does not load at all (according to dmesg).
The one built from git has a differrent dmesg message about some missing symbol, and the alsamixer shows the same set of wrong sliders like in the case of no "snd-hda-codec-ca0132.ko" loaded.

I didn't experiment with replacing the full kernel because of two things:
- my install is with root on ZFS, which is experimental and all the docs I found were not considering this aspect
- with either sets of sources, neither of my builds have the exact same version "5.15.0-41-generic"
- I've tried installing a newer kernel (ready made debs from Ubuntu), and it didn't boot

Very frustrating afternoon, and it all felt like I was fighting against the OS.

Maybe I should give up Ubuntu.  Ubuntu works great if you don't touch anything, but as soon as you want something different, it's a pain bigger than Arch or Gentoo.  It is probably just me not knowing what I'm doing, but if I want to understand more, I guess I should start using something else, less obfuscated.


Though, I still have a generic question.  When I was building from sources, I didn't get the exact same version "5.15.0-41-generic".  I was seeing something like "5.15.0-38+" (from git sources) and something else for apt downloaded sources (I don't recall exactly), but neither was called "5.15.0-41-generic" as "uname -r" was telling for the kernel I was running and wanted to rebuild again from sources. 

Is this difference in version naming expected to show at a rebuild, or I was building wrong sources the whole time? 

[Nominal Animal]

Though, I still have a generic question.  When I was building from sources, I didn't get the exact same version "5.15.0-41-generic".  I was seeing something like "5.15.0-38+" (from git sources) and something else for apt downloaded sources (I don't recall exactly), but neither was called "5.15.0-41-generic" as "uname -r" was telling for the kernel I was running and wanted to rebuild again from sources. 

Is this difference in version naming expected to show at a rebuild, or I was building wrong sources the whole time? 

That seems very strange to me.  I did test the entire chain I suggested reply #5, but on Linux Mint 20.04.
It is more generic than just the kernel that roughly the same flow should work to reproduce any package.

(If you want, I can distill the recipe down to rebuilding the full set of current kernel packages, on Debian derivatives.
But it is so much effort I'd require you to exactly reproduce it on your system, and report any errors/issues/findings on each step.)

A core idea of packages is that they should be recompilable, and reproducible excluding timestamps (included in the object files) and compiler version differences.  Perhaps you are running a kernel from a PPA that does shenanigans with its source package?  I personally would not, I hate that kind of shenanigans.  Even running completely custom kernels with an optimised .config is far more preferable.  I used to do that for a long time, when I was using a motherboard with AMD integrated graphics with open-source drivers still in heavy development.

[magic]

Another ugly thing (looks like a bug to me) was because of tex-common (needed by other tools that are required to make/build from sources) Tex was a nightmare and refused to install, only to find some obscure answer that it will install if I change the locale to en utf8.

That's what I meant by "just run make and manually install missing programs, if any". Tex isn't needed to compile a few lines of C code, neither is Java

The rest of the tries were done in two separate Ubuntu kernel sources (not vanilla Linux), one from git, one from Ubuntu repos.  First, all the kernel has to build, or else the modules will miss "Module.symvers", which is only build at a full make, which on my hardware and with -j8, a full kernel compile takes about 2 hours first time.  Subsequent compilations or only modules takes only minutes.  I've read some other distros (e.g. OpenSUSE) have a package that includes "Module.symvers", but couldn't find any such package for Ubuntu, so I had to compile the full kernel

So you have compiled your module to work against your own build of the kernel. I am actually not 100% sure if your build is guaranteed to be similar enough for the module to load into the distribution kernel too. If it matches, it's still a waste of time.

The right (and fast) solution is to use your distribution's Module.symvers and this should be provided by linux-headers. Also .config and everything else needed to build modules for the distribution kernel should be in this package, because it's the whole point of this package to enable building of additional modules for the distribution kernel. It might even pull all dependencies required by kernel Makefiles so that you shouldn't need any of that build-dep stuff just to build a module.

You could steal required files from there to your source tree, or just build the module out-of-tree. The point of building OoT is not because it's the only way I know of or to make Nominal jealous because he doesn't know it, but simply because it works and it works fast and it's easy to set up and doesn't require a gigabyte download.

Unfortunately, the kernel modules in my Ubuntu are signed.  I had to generate my own keys.

I would look at how it's done by kernel modules provided by the distribution in source format, such as this one. As far as I see after unpacking the .DEB, they simply use DKMS, so maybe everything is somehow sorted out by DKMS.

Can you install this module and load it, or at least get it to the point where it says that you don't have such hardware and exists?
If so, there seems to be an obvious path forward: use DKMS to build your patched code out-of-tree and call it a day.
If not, what is even the officially supported way of installing this driver (or NVIDIA, etc) on Ubuntu? There has to be something, and it ought to be simple enough for a monkey to use.

edit
CAUTION, this package seems to blacklist some other Broadcom WiFi drivers. So maybe don't install it or be sure to have instructions how to uninstall it downloaded if you use such hardware

[RoGeorge]

I said I'll give up, but still itchy to make it work, sorry for not keeping my word.   

To answer in order, I'll try first the Reply#5, considering what I've learned meanwhile, but I'll ask where I see deviations.  To some commands I've pasted the stdout from the terminal, either to check, or to point at unexpected behavior.

Though, I still have a generic question.  When I was building from sources, I didn't get the exact same version "5.15.0-41-generic".  I was seeing something like "5.15.0-38+" (from git sources) and something else for apt downloaded sources (I don't recall exactly), but neither was called "5.15.0-41-generic" as "uname -r" was telling for the kernel I was running and wanted to rebuild again from sources. 

Is this difference in version naming expected to show at a rebuild, or I was building wrong sources the whole time? 

That seems very strange to me.  I did test the entire chain I suggested reply #5, but on Linux Mint 20.04.

I've looked at Mint https://linuxmint.com/download_all.php, and my understanding is the current Mint is based on Ubuntu 20.04 LTS Focal Fossa, the exact Ubuntu I am running.

About the sources, please note the "Picking 'linux-signed-hwe-5.15'" as source package instead of 'linux-image-5.15.0-41-generic'  , did Mint does that?

Next strange thing is that out of all the .sh scripts in the ./scripts directory, only 3 of them are not executables, the rest are executable.  Not sure if this is a bug.  I am tempted to chmod them to +x and continue, but I thought I might stop to ask before going on, given that it also picked some other sources than my "uname -r" requested.

Is it OK"-ish" so far, or I'm already on a wrong path?

Code: [Select]

        mkdir reply5
        cd reply5

        apt source linux-image-`uname -r`     
            Reading package lists... Done
            Picking 'linux-signed-hwe-5.15' as source package instead of 'linux-image-5.15.0-41-generic'
            Need to get 22,0 kB of source archives.
            Get:1 [url]http://ubuntu.mirrors.linux.ro/archive[/url] focal-updates/main linux-signed-hwe-5.15 5.15.0-41.44~20.04.1 (dsc) [1.949 B]
            Get:2 [url]http://ubuntu.mirrors.linux.ro/archive[/url] focal-updates/main linux-signed-hwe-5.15 5.15.0-41.44~20.04.1 (tar) [20,1 kB]
            Fetched 22,0 kB in 0s (337 kB/s)           
            dpkg-source: info: extracting linux-signed-hwe-5.15 in linux-signed-hwe-5.15-5.15.0
            dpkg-source: info: unpacking linux-signed-hwe-5.15_5.15.0-41.44~20.04.1.tar.xz
        apt source linux-modules-`uname -r`
            # huge list of source file
           
        # cd linux-[0-9]*/
        ls
            linux-hwe-5.15-5.15.0
            linux-hwe-5.15_5.15.0-41.44~20.04.1.diff.gz
            linux-hwe-5.15_5.15.0-41.44~20.04.1.dsc
            linux-hwe-5.15_5.15.0.orig.tar.gz
            linux-signed-hwe-5.15-5.15.0
            linux-signed-hwe-5.15_5.15.0-41.44~20.04.1.dsc
            linux-signed-hwe-5.15_5.15.0-41.44~20.04.1.tar.xz

        tree linux-signed-hwe-5.15-5.15.0
            linux-signed-hwe-5.15-5.15.0
            ├── debian
            │   ├── changelog
            │   ├── compat
            │   ├── control
            │   ├── control.stub
            │   ├── copyright
            │   ├── rules
            │   ├── scripts
            │   │   └── misc
            │   │       └── git-ubuntu-log
            │   ├── source
            │   │   ├── format
            │   │   └── options
            │   ├── templates
            │   │   ├── image.postinst.in
            │   │   ├── image.postrm.in
            │   │   ├── image.preinst.in
            │   │   └── image.prerm.in
            │   └── variants
            ├── download-signed
            ├── download-unsigned
            ├── generate-depends
            └── update-version

            5 directories, 18 files
           
        # seems the other one has the sources
        cd linux-hwe-5.15-5.15.0
       
        # insert a new line with vendor ID 1102 0011 for the soundchip ca0132 in the ASRock Fatal1ty Z97 Professional motherboard
        #   most probably a Recon3Di Creative Sound Blaster, by the folder names found inside the Windows sound drivers of this motherboard
        cp sound/pci/hda/patch_ca0132.c ./patch_ca0132.c_from_linux-hwe-5.15-5.15.0_sources
        sed -i '/SND_PCI_QUIRK(0x1458, 0xA026, "Gigabyte G1.Sniper Z97", QUIRK_R3DI),/a \\tSND_PCI_QUIRK(0x1102, 0x0011, "ASRock Fatal1ty Z97 Professional", QUIRK_R3DI),' sound/pci/hda/patch_ca0132.c
        diff -c ./patch_ca0132.c_from_linux-hwe-5.15-5.15.0_sources sound/pci/hda/patch_ca0132.c
            *** ./patch_ca0132.c_from_linux-hwe-5.15-5.15.0_sources 2022-07-27 16:10:06.582011362 +0300
            --- sound/pci/hda/patch_ca0132.c        2022-07-27 16:59:02.162469113 +0300
            ***************
            *** 1304,1309 ****
            --- 1304,1310 ----
                    SND_PCI_QUIRK(0x1102, 0x0033, "Sound Blaster ZxR", QUIRK_SBZ),
                    SND_PCI_QUIRK(0x1458, 0xA016, "Recon3Di", QUIRK_R3DI),
                    SND_PCI_QUIRK(0x1458, 0xA026, "Gigabyte G1.Sniper Z97", QUIRK_R3DI),
            +       SND_PCI_QUIRK(0x1102, 0x0011, "ASRock Fatal1ty Z97 Professional", QUIRK_R3DI),
                    SND_PCI_QUIRK(0x1458, 0xA036, "Gigabyte GA-Z170X-Gaming 7", QUIRK_R3DI),
                    SND_PCI_QUIRK(0x3842, 0x1038, "EVGA X99 Classified", QUIRK_R3DI),
                    SND_PCI_QUIRK(0x1102, 0x0013, "Recon3D", QUIRK_R3D),
       
        # build
        cp /boot/config-`uname -r` .config
        sudo apt install build-essential fakeroot
       
        sudo apt build-dep linux-image-`uname -r`
            Reading package lists... Done
            Picking 'linux-signed-hwe-5.15' as source package instead of 'linux-image-5.15.0-41-generic'
            Reading package lists... Done
            Building dependency tree       
            Reading state information... Done
            0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
           
        sudo apt build-dep linux-modules-`uname -r`
            Reading package lists... Done
            Picking 'linux-hwe-5.15' as source package instead of 'linux-modules-5.15.0-41-generic'
            Reading package lists... Done
            Building dependency tree       
            Reading state information... Done
            The following NEW packages will be installed:
            dvipng latexmk librsvg2-bin zstd
            0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
            Need to get 813 kB of archives.
            After this operation, 2.582 kB of additional disk space will be used.
            Do you want to continue? [Y/n]
            Get:1 [url]http://ubuntu.mirrors.linux.ro/archive[/url] focal/universe amd64 dvipng amd64 1.15-1.1 [78,9 kB]
            Get:2 [url]http://ubuntu.mirrors.linux.ro/archive[/url] focal/universe amd64 latexmk all 1:4.67-0.1 [376 kB]
            Get:3 [url]http://ubuntu.mirrors.linux.ro/archive[/url] focal-updates/universe amd64 librsvg2-bin amd64 2.48.9-1ubuntu0.20.04.1 [14,2 kB]
            Get:4 [url]http://ubuntu.mirrors.linux.ro/archive[/url] focal-updates/universe amd64 zstd amd64 1.4.4+dfsg-3ubuntu0.1 [343 kB]
            Fetched 813 kB in 0s (6.164 kB/s)
            Requesting to save current system state
            Successfully saved as "autozsys_wb5pqa"
            Selecting previously unselected package dvipng.
            (Reading database ... 417550 files and directories currently installed.)
            Preparing to unpack .../dvipng_1.15-1.1_amd64.deb ...
            Unpacking dvipng (1.15-1.1) ...
            Selecting previously unselected package latexmk.
            Preparing to unpack .../latexmk_1%3a4.67-0.1_all.deb ...
            Unpacking latexmk (1:4.67-0.1) ...
            Selecting previously unselected package librsvg2-bin.
            Preparing to unpack .../librsvg2-bin_2.48.9-1ubuntu0.20.04.1_amd64.deb ...
            Unpacking librsvg2-bin (2.48.9-1ubuntu0.20.04.1) ...
            Selecting previously unselected package zstd.
            Preparing to unpack .../zstd_1.4.4+dfsg-3ubuntu0.1_amd64.deb ...
            Unpacking zstd (1.4.4+dfsg-3ubuntu0.1) ...
            Setting up librsvg2-bin (2.48.9-1ubuntu0.20.04.1) ...
            Setting up dvipng (1.15-1.1) ...
            Setting up latexmk (1:4.67-0.1) ...
            Setting up zstd (1.4.4+dfsg-3ubuntu0.1) ...
            Processing triggers for install-info (6.7.0.dfsg.2-5) ...
            Processing triggers for man-db (2.9.1-1) ...
            ZSys is adding automatic system snapshot to GRUB menu
           
        make sound/pci/hda/
            /bin/sh: 1: ./scripts/pahole-flags.sh: Permission denied
            SYNC    include/config/auto.conf.cmd
            /bin/sh: 1: ./scripts/pahole-flags.sh: Permission denied
            HOSTCC  scripts/basic/fixdep
            /bin/sh: 1: ./scripts/pahole-flags.sh: Permission denied
            HOSTCC  scripts/kconfig/conf.o
            HOSTCC  scripts/kconfig/confdata.o
            HOSTCC  scripts/kconfig/expr.o
            LEX     scripts/kconfig/lexer.lex.c
            YACC    scripts/kconfig/parser.tab.[ch]
            HOSTCC  scripts/kconfig/lexer.lex.o
            HOSTCC  scripts/kconfig/menu.o
            HOSTCC  scripts/kconfig/parser.tab.o
            HOSTCC  scripts/kconfig/preprocess.o
            HOSTCC  scripts/kconfig/symbol.o
            HOSTCC  scripts/kconfig/util.o
            HOSTLD  scripts/kconfig/conf
            sh: 1: ./scripts/pahole-version.sh: Permission denied
            init/Kconfig:92: syntax error
            init/Kconfig:91: invalid statement
            make[2]: *** [scripts/kconfig/Makefile:77: syncconfig] Error 1
            make[1]: *** [Makefile:622: syncconfig] Error 2
            Makefile:712: include/config/auto.conf.cmd: No such file or directory
            make: *** [Makefile:735: include/config/auto.conf.cmd] Error 2
       
        find ./scripts -type f -iname *.sh ! -executable
            ./scripts/pahole-version.sh
            ./scripts/spdxcheck-test.sh
            ./scripts/pahole-flags.sh
           
        find ./scripts -type f -iname *.sh -executable
            ./scripts/cc-version.sh
            ./scripts/check_extable.sh
            ./scripts/modules-check.sh
            ./scripts/ld-version.sh
            ./scripts/selinux/install_policy.sh
            ./scripts/find-unused-docs.sh
            ./scripts/cc-can-link.sh
            ./scripts/atomic/gen-atomic-long.sh
            ./scripts/atomic/gen-atomics.sh
            ./scripts/atomic/check-atomics.sh
            ./scripts/atomic/gen-atomic-instrumented.sh
            ./scripts/atomic/atomic-tbl.sh
            ./scripts/atomic/gen-atomic-fallback.sh
            ./scripts/file-size.sh
            ./scripts/checksyscalls.sh
            ./scripts/syscalltbl.sh
            ./scripts/kconfig/merge_config.sh
            ./scripts/kconfig/mconf-cfg.sh
            ./scripts/kconfig/gconf-cfg.sh
            ./scripts/kconfig/qconf-cfg.sh
            ./scripts/kconfig/nconf-cfg.sh
            ./scripts/link-vmlinux.sh
            ./scripts/xz_wrap.sh
            ./scripts/gcc-plugins/gen-random-seed.sh
            ./scripts/syscallhdr.sh
            ./scripts/min-tool-version.sh
            ./scripts/tags.sh
            ./scripts/adjust_autoksyms.sh
            ./scripts/gen_ksymdeps.sh
            ./scripts/tools-support-relr.sh
            ./scripts/syscallnr.sh
            ./scripts/gcc-goto.sh
            ./scripts/tracing/ftrace-bisect.sh
            ./scripts/dtc/update-dtc-source.sh
            ./scripts/dev-needs.sh
            ./scripts/as-version.sh
            ./scripts/gcc-x86_32-has-stack-protector.sh
            ./scripts/depmod.sh
            ./scripts/xen-hypercalls.sh
            ./scripts/mkuboot.sh
            ./scripts/headers_install.sh
            ./scripts/decode_stacktrace.sh
            ./scripts/gcc-x86_64-has-stack-protector.sh
            ./scripts/gen_autoksyms.sh


Please ignore the "ZSys is adding automatic system snapshot to GRUB menu".  Ubuntu with ZFS on root autosaves a ZFS snapshot after any install/uninstall, and it has to change the Grub menus, too, since Canonical added a feature to boot from a ZFS snapshot at Grub screen, just like normal OSs are able to select, for example, a different version of kernel from the Grub screen at boot.

Same for messages like this, it's the Ubuntu's "Zsys" layer, a bunch of scripts on top of normal ZFS:
    Requesting to save current system state
    Successfully saved as "autozsys_blabla_ID"

[DiTBho]

I said I'll give up, but

Install a decent Linux rootfs, e.g. Debian, Fedora, ...

[Nominal Animal]

About the sources, please note the "Picking 'linux-signed-hwe-5.15'" as source package instead of 'linux-image-5.15.0-41-generic'  , did Mint does that?

No, and linux-signed-* do not exist in the standard repositories.  That stuff is Ubuntu/Canonical-specific.

Next strange thing is that out of all the .sh scripts in the ./scripts directory, only 3 of them are not executables, the rest are executable.

On 5.4.0-122-generic, scripts/spdxcheck-test.sh and scripts/xen-hypercalls.sh are not executable, and I do believe this is normal.

Is it OK"-ish" so far, or I'm already on a wrong path?

Unless you belong to Canonical Kernel Team, you cannot sign that kernel, and its build machinery will fail.
Even if you do succeed, the compiled modules and kernel will not be compatible with the Canonical-signed kernel you're currently running.

What I would do, is switch to an unsigned kernel first, by installing an unsigned kernel, and then rebooting and in Grub, picking the new unsigned kernel.
Do some testing to verify all the features you need from a kernel are available.  (Might be just ZFS support, so if it boots and you can log in and your full filesystem is visible, you're go.)

[RoGeorge]

Decided to make those 3 scripts executable and continue:

Code: [Select]

        # decided to make them executable
        find ./scripts -type f -iname *.sh ! -executable -exec chmod +x {} \+
           
        make sound/pci/hda/
        # went all OK, no errors and no .ko yet
       
        make sound/pci/hda/snd-hda-codec-ca0132.ko
            CALL    scripts/checksyscalls.sh
            CALL    scripts/atomic/check-atomics.sh
            DESCEND objtool
            DESCEND bpf/resolve_btfids
            LDS     scripts/module.lds
            WARNING: Symbol version dump "vmlinux.symvers" is missing.
                    Modules may not have dependencies or modversions.
                    You may get many unresolved symbol warnings.
            MODPOST modules-only.symvers
            WARNING: modpost: "module_layout" [sound/pci/hda/snd-hda-codec-ca0132.ko] undefined!
            WARNING: modpost: "snd_hdac_power_up" [sound/pci/hda/snd-hda-codec-ca0132.ko] undefined!
            WARNING: modpost: "system_wq" [sound/pci/hda/snd-hda-codec-ca0132.ko] undefined!
            WARNING: modpost: "kmalloc_caches" [sound/pci/hda/snd-hda-codec-ca0132.ko] undefined!
            WARNING: modpost: "msleep" [sound/pci/hda/snd-hda-codec-ca0132.ko] undefined!
            WARNING: modpost: "snd_hda_codec_load_dsp_prepare" [sound/pci/hda/snd-hda-codec-ca0132.ko] undefined!
            WARNING: modpost: "snd_hda_multi_out_dig_prepare" [sound/pci/hda/snd-hda-codec-ca0132.ko] undefined!
            WARNING: modpost: "snd_hda_mixer_amp_volume_put" [sound/pci/hda/snd-hda-codec-ca0132.ko] undefined!
            WARNING: modpost: "snd_hdac_codec_read" [sound/pci/hda/snd-hda-codec-ca0132.ko] undefined!
            WARNING: modpost: "strlen" [sound/pci/hda/snd-hda-codec-ca0132.ko] undefined!
            WARNING: modpost: suppressed 76 unresolved symbol warnings because there were too many)
            CC [M]  sound/pci/hda/snd-hda-codec-ca0132.mod.o
            make[2]: *** No rule to make target 'vmlinux', needed by 'sound/pci/hda/snd-hda-codec-ca0132.ko'.  Stop.
            make[1]: *** [scripts/Makefile.modpost:140: __modpost] Error 2
            make: *** [Makefile:1851: single_modpost] Error 2
From last night (other sources than these) I remember a README file telling to either "make pdfdocs" (which didn't work) or go visit the online docs at https://www.kernel.org/doc/html/latest/ and there I read something containing the word "symvers", which I'm not sure is the same thing in the last command error:

NOTE: “modules_prepare” will not build Module.symvers even if CONFIG_MODVERSIONS is set; therefore, a full kernel build needs to be executed to make module versioning work.

From https://www.kernel.org/doc/html/latest/kbuild/modules.html

I'm temped to build the whole kernel, like I did last night when I was following the steps given by ve7xen in Reply#2, but then I'll probably fail just like yesterday.

Any directions/ideas for how to get rid of the error posted in this reply, please?

[RoGeorge]

...
Unless you belong to Canonical Kernel Team, you cannot sign that kernel, and its build machinery will fail.
Even if you do succeed, the compiled modules and kernel will not be compatible with the Canonical-signed kernel you're currently running.

What I would do, is switch to an unsigned kernel first, by installing an unsigned kernel, and then rebooting and in Grub, picking the new unsigned kernel.
Do some testing to verify all the features you need from a kernel are available.  (Might be just ZFS support, so if it boots and you can log in and your full filesystem is visible, you're go.)

That's exactly what I was afraid the most.  I'm not sure how to manually change the kernel to unsigned, I've tried a couple of days ago to install a newer kernel binaries from Canonical, and it didn't boot in my setup.

Another thing is that the Ubuntu I am running now is installed on a ZFS root, and when Canonical added this feature (still experimental even today, after a couple of years already), it added some layers and some wrappers and some hooks anywhere from GRUB to systemd, and it is not documented yet.

It would be much easier for me to just take another HDD and install a normal Debian, and boot and experiment there.  After all, I don't even need all the bells and whistles from that ca0132 chipset, I only use it as it is now, as a stereo soundcard.

Yet another thing would be that even if I make the ca0132 to work properly, I've just read that the HDA standard is only 192kSa/s and 96k rec? (don't recall the exact numbers), but anyway, the HDA standard allows less data rates and less resolution than the ca0132 hardware can do, so the only way to get 384k/24bits is probably to use the chip from Windows.

Though the goal to modify the ko driver failed so far, it was a lot of interesting learning for me. 

[DiTBho]

lot of interesting learning for me. 

You learnt how depressing and annoying Linux can go.

A Linux kernel should be compiled with a simple "make", but you're reporting tons of shit involved in the process because someone at Canonical wanted to make things worse.

Holy crap, the whole computer is really falling apart. I'm here with an Allwinner SBC ... and ... well it's even worse than Canonical for the same reason + they also violated the GPL so there are a lot of binary blobs.

[Nominal Animal]

I'm not sure how to manually change the kernel, I've tried a couple of days ago to install a newer kernel binaries from Canonical, and it didn't boot in my setup.

Another option would be to convert the signed running kernel to unsigned one.  Make sure you have the pesign package installed.

Assuming your current kernel is /boot/vmlinuz-5.15.0-41-generic, run
    sudo pesign -i /boot/vmlinuz-5.15.0-41-generic -o /boot/vmlinuz-5.15.0-41-unsigned -r -u 0
    sudo update-grub
and reboot.  You should now have the kernel that does not enforce signing installed as "Ubuntu, with Linux 5.15.0-41-unsigned" as a boot option.

(If that boot does work, make sure your uname -r still reports 5.15.0-41-generic.
If not, then you need to rename the -generic to -signed, and then -unsigned to -generic, and run update-grub again.)

You also forgot to apply the two sed commands to modify .config to disable signing, as I showed at the end of reply #7.

Here's the log after downloading the kernel sources, and changing to the kernel directory (containing MAINTAINERS, README, COPYING, CREDITS, and so on), for me:

Code: [Select]

$ cp /boot/config-`uname -r` .config
$ sed -e 's|^\(CONFIG_MODULE_SIG[_A-Z0-9]*\)=y$|\1=n|' -e 's|^\(CONFIG_MODULE_SIG[_A-Z0-9]*\)=".*$|\1=""|' -i .config
$ sed -e '/debian/ s|^\(CONFIG_SYSTEM_[A-Z]*_KEYS\)=.*$|\1=""|' -i .config
$ make sound/pci/hda/snd-hda-codec-ca0132.ko
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/confdata.o
  HOSTCC  scripts/kconfig/expr.o
  LEX     scripts/kconfig/lexer.lex.c
  YACC    scripts/kconfig/parser.tab.[ch]
  HOSTCC  scripts/kconfig/lexer.lex.o
  HOSTCC  scripts/kconfig/parser.tab.o
  HOSTCC  scripts/kconfig/preprocess.o
  HOSTCC  scripts/kconfig/symbol.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf  --syncconfig Kconfig
  SYSTBL  arch/x86/include/generated/asm/syscalls_32.h
  SYSHDR  arch/x86/include/generated/asm/unistd_32_ia32.h
  SYSHDR  arch/x86/include/generated/asm/unistd_64_x32.h
  SYSTBL  arch/x86/include/generated/asm/syscalls_64.h
  HYPERCALLS arch/x86/include/generated/asm/xen-hypercalls.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_32.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_64.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_x32.h
  HOSTCC  arch/x86/tools/relocs_32.o
  HOSTCC  arch/x86/tools/relocs_64.o
  HOSTCC  arch/x86/tools/relocs_common.o
  HOSTLD  arch/x86/tools/relocs
  HOSTCC  scripts/genksyms/genksyms.o
  YACC    scripts/genksyms/parse.tab.[ch]
  HOSTCC  scripts/genksyms/parse.tab.o
  LEX     scripts/genksyms/lex.lex.c
  HOSTCC  scripts/genksyms/lex.lex.o
  HOSTLD  scripts/genksyms/genksyms
  HOSTCC  scripts/selinux/genheaders/genheaders
  HOSTCC  scripts/selinux/mdp/mdp
  HOSTCC  scripts/bin2c
  HOSTCC  scripts/kallsyms
  HOSTCC  scripts/conmakehash
  HOSTCC  scripts/recordmcount
  HOSTCC  scripts/sortextable
  HOSTCC  scripts/asn1_compiler
  HOSTCC  scripts/sign-file
  HOSTCC  scripts/extract-cert
  HOSTCC  scripts/insert-sys-cert
  WRAP    arch/x86/include/generated/uapi/asm/bpf_perf_event.h
  WRAP    arch/x86/include/generated/uapi/asm/errno.h
  WRAP    arch/x86/include/generated/uapi/asm/fcntl.h
  WRAP    arch/x86/include/generated/uapi/asm/ioctl.h
  WRAP    arch/x86/include/generated/uapi/asm/ioctls.h
  WRAP    arch/x86/include/generated/uapi/asm/ipcbuf.h
  WRAP    arch/x86/include/generated/uapi/asm/param.h
  WRAP    arch/x86/include/generated/uapi/asm/poll.h
  WRAP    arch/x86/include/generated/uapi/asm/resource.h
  WRAP    arch/x86/include/generated/uapi/asm/socket.h
  WRAP    arch/x86/include/generated/uapi/asm/sockios.h
  WRAP    arch/x86/include/generated/uapi/asm/termbits.h
  WRAP    arch/x86/include/generated/uapi/asm/termios.h
  WRAP    arch/x86/include/generated/uapi/asm/types.h
  WRAP    arch/x86/include/generated/asm/dma-contiguous.h
  WRAP    arch/x86/include/generated/asm/early_ioremap.h
  WRAP    arch/x86/include/generated/asm/export.h
  WRAP    arch/x86/include/generated/asm/mcs_spinlock.h
  WRAP    arch/x86/include/generated/asm/mm-arch-hooks.h
  WRAP    arch/x86/include/generated/asm/mmiowb.h
  UPD     include/config/kernel.release
  UPD     include/generated/uapi/linux/version.h
  UPD     include/generated/utsrelease.h
  CC      scripts/mod/empty.o
  HOSTCC  scripts/mod/mk_elfconfig
  MKELF   scripts/mod/elfconfig.h
  HOSTCC  scripts/mod/modpost.o
  CC      scripts/mod/devicetable-offsets.s
  UPD     scripts/mod/devicetable-offsets.h
  HOSTCC  scripts/mod/file2alias.o
  HOSTCC  scripts/mod/sumversion.o
  HOSTLD  scripts/mod/modpost
  CC      kernel/bounds.s
  UPD     include/generated/bounds.h
  UPD     include/generated/timeconst.h
  CC      arch/x86/kernel/asm-offsets.s
  UPD     include/generated/asm-offsets.h
  CALL    scripts/checksyscalls.sh
  CALL    scripts/atomic/check-atomics.sh
  DESCEND  objtool
  HOSTCC   /home/.../linux-5.4.0/tools/objtool/fixdep.o
  HOSTLD   /home/.../linux-5.4.0/tools/objtool/fixdep-in.o
  LINK     /home/.../linux-5.4.0/tools/objtool/fixdep
  CC       /home/.../linux-5.4.0/tools/objtool/exec-cmd.o
  CC       /home/.../linux-5.4.0/tools/objtool/help.o
  CC       /home/.../linux-5.4.0/tools/objtool/pager.o
  CC       /home/.../linux-5.4.0/tools/objtool/parse-options.o
  CC       /home/.../linux-5.4.0/tools/objtool/run-command.o
  CC       /home/.../linux-5.4.0/tools/objtool/sigchain.o
  CC       /home/.../linux-5.4.0/tools/objtool/subcmd-config.o
  LD       /home/.../linux-5.4.0/tools/objtool/libsubcmd-in.o
  AR       /home/.../linux-5.4.0/tools/objtool/libsubcmd.a
  MKDIR    /home/.../linux-5.4.0/tools/objtool/arch/x86/lib/
  GEN      /home/.../linux-5.4.0/tools/objtool/arch/x86/lib/inat-tables.c
  CC       /home/.../linux-5.4.0/tools/objtool/arch/x86/decode.o
  LD       /home/.../linux-5.4.0/tools/objtool/arch/x86/objtool-in.o
  CC       /home/.../linux-5.4.0/tools/objtool/builtin-check.o
  CC       /home/.../linux-5.4.0/tools/objtool/builtin-orc.o
  CC       /home/.../linux-5.4.0/tools/objtool/check.o
  CC       /home/.../linux-5.4.0/tools/objtool/orc_gen.o
  CC       /home/.../linux-5.4.0/tools/objtool/orc_dump.o
  CC       /home/.../linux-5.4.0/tools/objtool/elf.o
  CC       /home/.../linux-5.4.0/tools/objtool/special.o
  CC       /home/.../linux-5.4.0/tools/objtool/objtool.o
  CC       /home/.../linux-5.4.0/tools/objtool/libstring.o
  CC       /home/.../linux-5.4.0/tools/objtool/libctype.o
  CC       /home/.../linux-5.4.0/tools/objtool/str_error_r.o
  LD       /home/.../linux-5.4.0/tools/objtool/objtool-in.o
  LINK     /home/.../linux-5.4.0/tools/objtool/objtool
  CC [M]  sound/pci/hda/patch_ca0132.o
  LD [M]  sound/pci/hda/snd-hda-codec-ca0132.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC [M]  sound/pci/hda/snd-hda-codec-ca0132.mod.o
  LD [M]  sound/pci/hda/snd-hda-codec-ca0132.ko
$ strip --strip-debug sound/pci/hda/snd-hda-codec-ca0132.ko

where ... is just a path snippet to where I was doing this.  Took maybe half a minute.

I would definitely run the above once before applying the patch, in case the timestamp changes the patch applies confuse the kernel build machinery.  This way, the kernel does the prep work (including symversions) before the patch is applied, and should do the right thing afterwards too (as the files now exist, and just need to be redone depending on the timestamps).

[RoGeorge]

    sudo pesign -i /boot/vmlinuz-5.15.0-41-generic -o /boot/vmlinuz-5.15.0-41-unsigned -r -u 0
    sudo update-grub

I have a bad feeling about this (won't boot any more), but I'll try. 
Posting this before trying, just to be sure.

If it were to be that simple to disable the signature checking, than what would stop a malware to do the same?  I've read the whole key signature circus is to prevent rootkits and alike malware.  So if all I need to disable it is to be root, and no Canonical private keys, then why even bother having cryptographic keys?