^G Help ^O Write Out ^W Where Is ^K Cut ^T Execute ^C Location
^X Exit ^R Read File ^\ Replace ^U Paste ^J Justify ^/ Go To Line
@ computersavvy I suppose there has to be a bunch of code lines, am I right, oh?
Using a default F36 KDE live (the relevant data is equal to F36 Workstation) with 5.19.6, the 5.19.6 file could be opened with
sudo nano /boot/loader/entries/d239886fa9ec440db73734aeb26fa5a6-5.19.6-200.fc36.x86_64.conf → be aware that the exact file names are different in each case, only the ending is constant.
The content of the file is by default
title Fedora Linux (5.19.6-200.fc36.x86_64) 36 (KDE Plasma)
options root=live:CDLABEL=Fedora-KDE-Live-36-1-5 rd.live.image quiet rhgb
You have to work in the options line, which is line 5.
Don’t adjust your file to my example! Just focus on the instructions I made above, or on the proposed common issue workaround.
In nano, this would look like this:
With your preferred search engine, you can find many HowTo’s, tutorials and guides for
nano or other editors (
mc, …). Also, you can check
man nano (or generally,
man <editor> if it is installed)
I think it is due to oems use some software to make better battery life you should ask your oem to provide some of there code and optimizations to the kernel so that we all can have that better experience usually most brand do not provide there optimization ported to linux.
<lacklist=simpledrm_platform_driver_init rhgb quiet rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 initcall_blacklist=simpledrm_platform_driver>
Is that ok if I just add your suggested
rdblacklist=asus_ec_sensors right at the end of this options line ?
I see, but the problem is I have to wait for the next kernel up to see if the change is made and I do not even know when is the release. Anyway, thank you so much for your support!
@ py0xc3 I mean this line in my case does not end with
rhgb quiet as it is in your example. So that is ok if I just add that code at the end of the line ?
Yes, just add it to the end of your options line. Your file seems to be already modified for nvidia drivers or such.
Absolutely! I just meant that you should keep it in your mind until you see that the kernel has been updated (if you do your updates manually, you can see it directly, or if you boot and you see in grub that a new kernel is listed & booted from). When you see that an update has been done to the kernel, then try to remove the two blacklistings and check out if it works without blacklisting in the new kernel.
However, 5.19.7 is already in testing (I’m already using it : ) and should be there in a few days. You can keep the blacklisting with 5.19.7 as it has not yet a fix for the problem. But I expect the one after 5.19.7 will have.
(base) [Ali@ali ~]$ sudo echo "blacklist asus_ec_sensors" > /etc/modprobe.d/asus_ec_sensors.conf
bash: /etc/modprobe.d/asus_ec_sensors.conf: Permission denied
Should I remove quotes and try again?
First, please use preformatted text brackets for output → mark the text and use the </> button.
Second, correction: this is a special behavior of sudo in conjunction with stdin/stdout (I wasn’t aware of it as I don’t use sudo myself).
I have not much time today, but this can help you to adjust the command yourself for now:
Supplement: The solution above is adjusted. I forwarded it to the workaround. We designed and discussed the workaround to fit all types and configurations of Fedora. So I assume this will avoid issues among different configurations and such.
Thanks. I did with
echo blacklist asus_ec_sensors | sudo tee /etc/modprobe.d/asus_ec_sensors.conf
maybe they will release update with fix
that would be good
cause of beginners
The fix will come with a kernel update. So, yes, it will come automatically with your Fedora updates.
Now, as 5.19.8 kernel has come out do you think that I should try removing blacklistings?
Yes. It is worth a try. Although as far as I read it, it seems that 5.19.8 has still the problematic autoloading of asus_ec_sensors. But it is worth a try because we know there had been other kernels in the past that had no issues despite asus_ec_sensors’ autoloading.
Make the update to 5.19.8, remove both blacklistings, reboot, check out & let us know! Good luck! If it works after the reboot, check
lsmod to see the status of the module. Otherwise, unfortunately, add the blacklisting again. (Thanks for providing us testing information!)
As far as I remember, I added
rdblacklist=asus_ec_sensors only. So what was the second blacklisting you are referring to?
I removed this blacklisting from the file as you taught, but regarding the second one
I ran just like a simple line of code, how can I remove that? By saying the second one do you mean this part specifically? And if yes how can do that?:
I am so sorry to disturb you all the time endlessly. Thanks)
I don’t have much time to spare this week, but the file you created can just be deleted the usual way →
sudo rm /etc/modprobe.d/asus_ec_sensors.conf
However, we have discussed and created an official workaround since the issue appeared on your system. If the new kernel does not solve the problem so that you have to add the blacklisting again, I suggest to use the official workaround for the blacklisting in future: Battery charge indicator broken on certain ASUS motherboards, automatic suspend doesn't work
The workaround also contains a description how to remove it afterwards.
@ali-guest01 @kquote03 @burakdede
Kernel 5.19.9 contains multiple fixes for the autoload of
asus_ec_sensors. The problem you have been experiencing should be fixed after the update to 5.19.9, which will be the next kernel update. This update will come soon; the testing of this kernel for Fedora has already begun.
Therefore, once you update to 5.19.9, you can remove both blacklistings. We would appreciate any feedback if everything works again (or not) on 5.19.9 without blacklisting. I would prefer to have a “real world test case” on Fedora before changing the workaround.
I have tested it. It is fixed now. Thanks for your interest.
Thanks for updating the bugzilla report and letting us know! I will update the workaround once the new kernel is pushed to stable