Fix Kernel Headers version mismatch

[LaserBread]

I'm pretty inexperienced with how this low-level kernel stuff works, so I'm asking for help with an issue in Fedora using a fork.

I'm currently running kernel 6.4.11-200.fc38-x86_64. This causes a massive issue with the script as there are no headers for this specific release:

Running on Fedora
Building for kernel version 6.4.11-200.fc38.x86_64
Sign command: /lib/modules/6.4.11-200.fc38.x86_64/build/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Running the pre_build script:
Running on Fedora
Building for kernel version 6.4.11-200.fc38.x86_64
Last metadata expiration check: 1:23:08 ago on Mon 21 Aug 2023 12:13:45 PM PDT.
Dependencies resolved.
Nothing to do.
Complete!
Last metadata expiration check: 1:23:09 ago on Mon 21 Aug 2023 12:13:45 PM PDT.
No match for argument: kernel-headers-6.4.11-200.fc38.x86_64
Error: Unable to find a match: kernel-headers-6.4.11-200.fc38.x86_64
Could not install kernel-headers-6.4.11-200.fc38.x86_64. Try installing it manually.

Building module:
Cleaning build area...(bad exit status: 2)
make -j12 KERNELRELEASE=6.4.11-200.fc38.x86_64 -C /lib/modules/6.4.11-200.fc38.x86_64/build M=/var/lib/dkms/snd-hda-scodec-cs35l41/0.1/build...(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.4.11-200.fc38.x86_64 (x86_64)
Consult /var/lib/dkms/snd-hda-scodec-cs35l41/0.1/build/make.log for more information.

From the log /var/lib/dkms/snd-hda-scodec-sc35l410/0.1/build/make.log:

make: Entering directory '/usr/src/kernels/6.4.11-200.fc38.x86_64'
scripts/Makefile.build:41: /var/lib/dkms/snd-hda-scodec-cs35l41/0.1/build/Makefile: No such file or directory
make[1]: *** No rule to make target '/var/lib/dkms/snd-hda-scodec-cs35l41/0.1/build/Makefile'.  Stop.
make: *** [Makefile:2050: /var/lib/dkms/snd-hda-scodec-cs35l41/0.1/build] Error 2
make: Leaving directory '/usr/src/kernels/6.4.11-200.fc38.x86_64'

It appears 6.4.4 is the header version, and apparently that doesn't matter because kernel headers are only released every once in a while and cover multiple releases. I searched around the internet for an answer on how to get DKMS to be okay with using an older version. Do you recommend I figure out a workaround or just downgrade the kernel?

Also, how will DKMS handle future kernel updates that may not have a corresponding kernel-headers?

[Osc100]

I did get this to work with no problem on the kernel version mismatch (also on Fedora) modifying this script, and I can confirm that the script works on the 2023 Envy 16. (16-h1xxx)

I tried to use the code on the following repo https://github.com/Arkanus72/hp-15-ew0xxx-snd-fix but I also got the same error and I couldn't downgrade the kernel since the nvidia drivers stopped working when I did.

Thus i modified the script on this repo (since I found it easier to read)

The problem is, that I did it really fast, and because I don't know much about bash scripting or how to get the script to differentiate that is on Fedora, I deleted the if statements for other distros so I couldn't make a PR.

Here are the Fedora specific changes (I would love for someone to help for this to be in the main script with the required if statements):

On kernel-version_get.sh:

KERNEL_VERSION=$(uname -r)

makefile="/usr/src/kernels/${KERNEL_VERSION}/Makefile"
SOURCE_SUB_VERSION=$(uname -r | cut -d '.' -f 3 | cut -d '-' -f 1) # same as arch

To regenerate the initramfs on fedora on dkms-module_build.sh:

sudo dracut --regenerate-all --force

on the file dkms-module_create.sh it would be necessary to install the necessary dependencies on Fedora and get the required kernel header version to avoid mismatch, but I don't know how to get the specific version (close enough to the current kernel since on fedora they usually are not the same version).

edit: I just discovered that the -q in grep stands for quiet, no wonder it wouldn't show anything on my terminal when I tried the command 😭

 elif grep -q "^ID=fedora" /etc/os-release; then

should work for fedora.

[LaserBread]

Would you mind sharing all modified scripts in their entirety? I'm not sure where things are supposed to be put, and my attempt led to the exact same error.

Thank you. This problem has been a thorn in my side for over a year.

[Osc100]

Sorry for the late response! I just pushed a fork https://github.com/Osc100/hp-15-ew0xxx-snd-fix It has other unnecessary changes and the if statements removed so it only works on Fedora, but it should work

I hope it helps!

Edit: Now that I'm comparing the changes on github side by side, I just remembered this line:

https://github.com/Osc100/hp-15-ew0xxx-snd-fix/blob/bb3f95d6df5c197d5fd9e30f86ad893676a73650/dkms-module_create.sh#L56

And I don't remember why I changed it but it wouldn't work without it for some reason. Also line 64.

You should check the entire commit just in case there's another important difference I'm missing.

[LaserBread]

One more issue I encountered: when I go to run setup_snd-hda-codec-realtek.sh, the program dkms-module_create.sh fails at chmod u+x "/usr/src/${KERNEL_MODULE_NAME}-${DKMS_MODULE_VERSION}/dkms-patchmodule.sh" because the file its trying to chmod doesn't exist. I'm looking into it, but help would be nice.

[Osc100]

I'm a little confused with that line too, it was in the original script, but I don't really where on when the file was created, looking in my local /usr/src/snd-hda-codec-realtek-0.1 directory I found that in my computer it contains the original version of the kernel-module_patch.sh file, it probably was a leftover file when I was modifying the script and trying the other fedora fork.

Try removing that line, as I changed the PRE_BUILD script to the kernel-module_patch.sh in the line I pointed out in my previous comment.

Now, thinking about it, there's no place where the dkms-patchmodule.sh is created in the script in this repo, just kernel-module_patch.sh, and having in the consideration that I have leftover files from previous runs, maybe it's possible that the script is broken on all distros because of this?

[Osc100]

I created and tested a new branch, that adds support for fedora without deleting the code for other distros, and fixing the dkms-patchmodule.sh reference (since that file isn't created anymore, replaced for kernel-module_patch.sh instead)

You can see it here: https://github.com/Osc100/hp-15-ew0xxx-snd-fix/tree/multidistro.

would be great if you also tested it.

Also created a PR with that branch here:

https://github.com/xoocoon/hp-15-ew0xxx-snd-fix/pull/14

[LaserBread]

The new script didn't work. But I got your old one working (just having to do some weird jank)

So, from a fresh install of Fedora, I tried running your script. Right off the bat, it complained that all the other scripts had insufficent privileges.

setup_snd-hda-scodec-cs35l41.sh: line 20: /home/LaserBread/Downloads/hp-15-ew0xxx-snd-fix-multidistro/dkms-module_create.sh: Permission denied

No biggie. I gave all the scripts owner-execution permissions, and everything worked fine. It created the module, and told me to reboot.

However, when I rebooted the computer and run sudo dmesg | grep cs35l41, I get:

[    7.072512] snd_hda_scodec_cs35l41: loading out-of-tree module taints kernel.
[    7.072518] snd_hda_scodec_cs35l41: module verification failed: signature and/or required key missing - tainting kernel
[    7.076424] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Error: ACPI _DSD Properties are missing for HID CSC3551.
[    7.076426] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: error -EINVAL: Platform not supported
[    7.076447] cs35l41-hda: probe of i2c-CSC3551:00-cs35l41-hda.0 failed with error -22
[    7.077731] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Error: ACPI _DSD Properties are missing for HID CSC3551.
[    7.077735] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: error -EINVAL: Platform not supported
[    7.077760] cs35l41-hda: probe of i2c-CSC3551:00-cs35l41-hda.1 failed with error -22

The module didn't work. I downloaded your older script and tried it for a laugh. I set permissions and ran it, and... chmod: cannot access '/usr/src/snd-hda-scodec-cs35l41-0.1/dkms-patchmodule.sh': No such file or directory

I then tried downloading the Fedora version by Arkanus72 and tried running it. It seems that the aforementioned dkms-patchmodule.sh doesn't get properly created by the script. I ran it, got an error that lsb_release doesn't exist, which I had to download the package redhat-lsb-core. Once that issue was in the past, I ran Arkanus72's script again, and it obviously whined about the version mismatch. We were talking about that earlier, but the PRE_BUILD="dkms-patchmodule.sh sound/pci/hda" file was probably important, something it created.

Still no luck with your new script, but your old one did not throw an error, and in fact, worked perfectly. sudo dmesg | grep cs35l41 got me this:

[    5.315804] snd_hda_scodec_cs35l41: loading out-of-tree module taints kernel.
[    5.315810] snd_hda_scodec_cs35l41: module verification failed: signature and/or required key missing - tainting kernel
[    5.444610] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Cirrus Logic CS35L41 (35a40), Revision: B2
[    5.445026] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Reset line busy, assuming shared reset
[    5.505682] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Cirrus Logic CS35L41 (35a40), Revision: B2

(Don't worry about the tainted kernel thing. It just means that a custom module was loaded and is probably very relevant if you're debugging).

I then tried the setup_snd-hda-codec-realtek script in your new program. I rebooted and there was no audio.

So... I did the same thing I did with the your other setup script. I ran Arkanus72's version, watched it have a die, had your old script grave-rob its dkms-patchmodule.sh file, rebooted and...

After 1 year of having to use headphones and bluetooth speaker alarm clock, I can finally make the laptop work. It seems that your old script did everything better. I don't quite know why, or what the scripts were precisely doing that made this work or not (or more importantly, what the patch is doing), but it's working now.

I'm currently messing around with an equalizer to make the speakers sound okay.

[Osc100]

I'm glad that it helped you :D

It seems that I'm missing something, maybe a file or something that Arkanus72's script does. So I wouldn't say that this is ready for a PR.

I don't know where to look though haha.

Also, could you share your equalizing software? My speakers sounds pretty bad too, but I think that has to do with the kernel driver, since my old hp laptop had the same problem (low volume, bad sound) despite working out of the box.

[LaserBread]

The equalizer I'm using is EasyEffects. It works with Pipewire. Also, from my experimentation, don't go crazy with the bass. The laptop has a subwoofer (for some ungodly reason), which will gleefully overpower any other sound.

[LaserBread]

I'm going to go ahead and close this, since we're working on a fix. Hopefully it can be merged with this repo (I think that's how git works. I'm studying CS in college so I will probably learn more about it lmao)