Battery information is not getting updated. Eg. If I plug in charger, it does not update charging information. If I disconnect battery it does not update disconnected information. The battery percentage is also stagnant and not getting updated. On reboot correct information is updated.
It was working fine in the begining, not sure when this stopped working.
Thanks for the information. I tested and confirmed the issue by re installing fedora and testing as I installed each application and update. It happened when I updated from kernel 5.17 to 5.19.
I will wait for the update to push through as advised in the article
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.
Is there any way to test it now to give you feedback before it gets pushed to everyone?
Otherwise I will give my Feedback here as soon as it gets released.
Well, theoretically yes, but be aware that the 5.19.9 kernel is not even in the testing repository yet. So integrating this kernel into Fedora has just started - and you have to be aware that unintended behavior cannot be excluded at the moment.
If you are aware of the risk, and still want to check it out, you can do so by dnf update https://kojipkgs.fedoraproject.org//packages/kernel/5.19.9/200.fc36/<arch>/kernel-5.19.9-200.fc36.<arch>.rpm https://kojipkgs.fedoraproject.org//packages/kernel/5.19.9/200.fc36/<arch>/kernel-core-5.19.9-200.fc36.<arch>.rpm https://kojipkgs.fedoraproject.org//packages/kernel/5.19.9/200.fc36/<arch>/kernel-modules-5.19.9-200.fc36.<arch>.rpm & reboot. This command is for F36.
Replace<arch>with your architecture! You can find out with uname -r → the last part (after the last “.”) of the output is your architecture. E.g., x86_64
If there are any issues, return to the last kernel. Only do this if you are sure to know what you are doing!
There is no problem with waiting for the release within Fedora. If we find out that the issue is not solved on all machines, I would leave the workaround for now as it is and let the developer know about it - although I do not expect that; I just use all means of verification if they are available anyway. If it passes all tests, 5.19.9 will be released in either way as it also contains other commits
Ok, thanks for all the Info. I just set up my Fedora 36 so I would not lose alot if something goes wrong (although I had my fights setting it up perfectly).
I have to check tommorow again and see if I’ll try it as I am not that techical yet and have to read things to solve problems and don’t just know solutions.
Just keep in mind that getting rpm’s from koji directly is only intended for people testing packages and who know about it. However, the risk that it will be necessary to reinstall Fedora is low in this one case → in case of issues, reboot and choose the previous kernel in the menu when booting. Nevertheless, at this stage there are no guarantees.
If you are interested in making experiences and getting deeper into Fedora over time, feel free. Otherwise, I see no reason to do that
If you want to see what is happening at this stage of getting this kernel into Fedora, check https://bodhi.fedoraproject.org/updates/FEDORA-2022-6127de5cb6 (as with koji, bodhi is nothing you need to know about if you “only want to use” Fedora)
This will never change. There will be always problems you can solve yourself, and problems you need to read At least if you keep developing your skills.
Happy to hear that I have changed your marked solution from my last post to the one before it in order to avoid that users keep installing a package from Bodhi directly. This is intended just for now. In future, they should just do the normal update as suggested in the other post → The problem is that at some point 5.19.9 will be old as well, and then we should ensure that users do not use a command that still sticks with 5.19.9
Thanks for contributing to evaluating the problem!