I’m trying Linux on my HP Omen laptop and to use it correctly I need to access the ec_sys module to allow the fan on my laptop to just work as they should.
The problem I have is that logically ec_sys is a signed module like every one else but for some reason it can’t launch when the secure boot is enabled.
Now, because I’m just trying Linux I still need the secure boot for my windows partition.
Because of this, I need help understanding if I forgot something or if it’s just a module that can’t be activated under secure boot.
Thanks in advance.
Ubuntu Version:
Kubuntu 25.04
Desktop Environment (if applicable):
KDE Plasma
Problem Description:
I want to load the ec_sys module with modprobe via sudo modprobe ec_sys but I get the following error :
modprobe: ERROR: could not insert 'ec_sys': Operation not permitted
Edit : this error is partially solved.
Now the module does not trigger a lockdown ( the Operation not permitted from before ) and load but the ec_sys can’t be activated in write_support which I need :
A permissions issue when using modprobe might not always mean a lack of privileges and can sometimes stem from an internal lockdown, which we can still overcome.
Well apart from having the secure boot activated on my end nothing.
I installed this Linux 2 days ago and only added the nvidia drivers, heroic launcher and steam to test some games, that are on a ntfs drive that I mount later after the boot of the os.
Nothing should affect to way the system load the kernel modules ( well apart from nvidia but that was through the official tool that comes with kubuntu )
The only strange thing I could notice is a total freeze of the system completely random where even the “Magic System Request Key” can’t help.
I don’t have the time to reinstall today but I will try to reinstall again this week-end and come back to post the result.
So, my old installation was somehow both working and corrupted…
For that I suspect my usb drive on which I booted the installer.
Now, on this new installation, there is still a consistent strange behavior which is that if I load the module on boot via a config file like /etc/modprobe.d/ec_sys.conf.
Then the load doesn’t work and I get the same errors as yesterday when trying to load it manually.
But, if this config file is not here then I can only load it in read-only :
thomas@thomas-omen:~$ sudo modprobe ec_sys write_support=1
modprobe: ERROR: could not insert 'ec_sys': Operation not permitted
thomas@thomas-omen:~$ sudo modprobe ec_sys
thomas@thomas-omen:~$ sudo modprobe ec_sys write_support=1
thomas@thomas-omen:~$ sudo cat /sys/module/ec_sys/parameters/write_support
N
That’s a really strange behavior, why does the second modprobe to enable write_support doesn’t return an error but do nothing at the end ?
If you have an idea I will gladly take it as it start to get a little complicated for me and the research I’ve done doesn’t have this specific problem.
PS : For now I did not have a freeze on this new system, I will try to use it a little more to see if it come back.
I can’t use it for a long period of time as without the fan control working my CPU will spike at 100°C easily.
Edit : Two things
I just got a freeze so that’s something else than my broken install from yesterday.
I hope that this will be fixed by october when the support of Win 10 end.
That would be my sort of end of testing date to switch to linux if I can fix all of my problems
I just tested adding the ec_sys.write_support=1 line on the grub default boot parameters but I got the same result as the config file
Looks like your kernel runs in lockdown mode. Disable it by removing it from the kernel cmdline. In Grub select the entry of the system, press e, remove from the cmdline “lockdown=XYZ” if it exists, boot the system and try loading your module. If it is working remove the lockdown mode from the grub.cfg and update grub.
I just checked and I have not the lockdown parameter in the grub.cfg file.
If you look at my last message you can see that this lockdown is only triggered if I add an option to load the module ec_sys on write_support be it via /etc/modprobe.d/ec_sys.conf or by adding ec_sys.write_support=1 in grub.cfg.
I do not know why I can only load this module via the command sudo modprobe ec_sys.
And more than that, the sudo modprobe ec_sys write_support=1 do nothing but also does not trigger a lockdown in the logs.
ogra@acheron:~$ modinfo ec_sys|grep write
parm: write_support:Dangerous, reboot and removal of battery may be needed. (bool)
Did you remove your battery yet ? Looks like the built in ec_sys module might require it … (also, are you sure you really want this at all given it might potentially damage your hardware when used with wrong parameters)
The battery removal part doesn’t concern my laptop as the ec reset every 2 min if no write has been done to it.
And yes, I do need to have write support because without them the fan on my laptop are controlled by the uefi and are locked at like 70% speed or so.
So when I need to use the cpu at more than 40% it quickly heat up and thermal throttle…
For the safety measures don’t worry as even the hp official driver on windows control everything by writing to it.
On my side, I’ve already tested to read and write on the registers on windows and I now know which one I should use.
If you want to look more into it, I based my tests on this project that already identified a lot of registers for the ec on the omen laptops : OmenMon ec-registers identifiers
And I know exactly what the script I want to execute will do.
In fact I already tried it with secure boot off and it worked exactly like on windows.
So I found this project acpi_ec that does what I didn’t test which is self signing the module.
He does it by adding ec_sys under a different name, making it independent of acpi.h and always accepting write_support.
And that works !!
I still don’t believe this solution to be the normal one, now that modprobe allow the ec_sys module to load.
But until modprobe actually allow this module to be loaded in write_support, I will be forced to use this new module with my own signature.
I hope that in the future something is done to make this module work correctly under secure boot.