Repository navigation
Replies: 4 comments 19 replies
|
I own a Crosshair 16 HX AI D2XWGKG and the firmware is 15P4EMS1.107. The Debian kernel 6.19.10 doesn't support it but with a little workaround made by Gemini, it forced the CONF_G2_1 on my firmware and the battery control works perfectly. |
|
It was added there, so you probably installed module incorrectly first time. Please make clean install |
|
Which installation method you used? |
|
I edited directly the orginal module without test the official one. I follow the guide: "make-dkms install". |
|
Okay, error you got was caused by old version of module, built in to kernel |
Your module works perfectly, just tested. |
|
Was helping a friend with the install on a gf66 11ug, worked-ish for the first day, but after the first restart every single driver on the laptop stopped working (bluetooth, wifi, land etc) with errors about not finding msi-ec being found kernel side. Moving to kernel 6.17.0-14 worked as a temporary fix to this (with dkms status saying there was a diff between built and installed modules). I genuinely could not figure out exactly what had occurred, but I feel like the install instructions 100% need some warnings / common issues written down somewhere. Not asking for support (we are just holding at .14 until we can do a fresh install) but I feel we must have stumbled somewhere dumb along the way, hence the suggestion for "common issues" as part of the install instructions. |
|
I will not push on this, but I will note that this is the feedback page for specifically the install process... I know utilizing kernel-level things are risky, but I want you to propose that it is not unreasonable to take a step back and consider your audience in the current times. Quite a few people are moving over from Windows to Linux, and the owners of MSI laptops are not exactly the most "hardcore-linux user" demographic. I do not think it is unreasonable to give support / guidence as to the inherent risks of DKMS / kernel modules in general as part of the instructions. The fact that your advice about initramfs is not in the install instructions is, at least in my opinion, evidence of the point I am making. As for the "Skill Issue" part, I do actually agree with you on principle. However, as an educator myself, I do uphold a certain opinion that, if something can result in a "skill issue" and, due to its nature socially (e.g: Drivers for MSI-Gaming Laptops as part of a way to replace Afterburner) can lead to more novice individuals utilizing it, then warnings should be put into the installation documentation to warn new users of the potential danger of messing around with things like DKMS. Something similar to "DKMS, if not handled properly, can lead to significant issues on your PC. As such, it is advised you familiarize yourself with DKMS before proceeding with installing msi-ec" would be ideal. I hope you take this as the good feedback it intends to be, as I do agree this was very much a skill issue, but I also believe there is a certain duty of care to ensure users are aware of the level of "this is advanced / potentially easy to mess up stuff" that a project is before they install it. Just my two cents, apologies if I have crossed over a line. Hope you have a pleasant day. |
|
Okay, sorry, but I can't know how to fix problem I have no debug info about. I think only LLMs can guide users which have no exact arguments to response |
|
Well, universal guide can be "don't use debian based distros on bleeding edge hardware", but even in this case is possible to find workaround. I can't ask about software stack each time, and seems that feedback section needs to have standard questions as on "new hw", "bug" issues |
|
I'm not seeing skill issues as problem, but a regular thing, which some people are afraid to admit. Making docs is complex, because it's easy to skip some steps which looks familiar to me or anyone else, but will turn into day long problem for crowd. Plus messages with massive feedback ended few years ago |
Okay, so, Instead of saying skill issues, I will try to provide some support here. Is your problem fixed ? As for the new comers, the packages have been made supposing you did not install the module before. However, it may be fixable if this is where the problem comes from. As for your feedback, it is appreciated, but I agree that maybe providing some dmesg logs and dkms logs would be really helping in your case. If you cannot provide them, then there may be little we can do. As for you dkms warning, I did not put them into the readme because, after 10 years of using it, even as a beginner, I never had problems with it and I did not know it could behave that way. Concerning the fact it does not work properly, we apologize on that. Can we count on your help to improve the module by detailing your feedback? |
|
I previously had the .deb version of Mcontrolcenter working on my Debian 13 installation from July 2025 using the shift-mode-fix option. (Thanks to all contributor!) Then uninstalled and installed from a fresh git clone. Again no errors but module is not loading. |
|
SOLVED my issue. |
|
Hello, I am happy you figured a solution. However, I never had the secure boot re enabling itself during an update. So that is strange. However, if you wish to keep the secure boot on, I think we have a tutorial on how to sign the module for secure boot. |
|
Well, it's possible that BIOS update reset all settings |
|
It was the BIOS firmware update that caused the Secure Boot setting change. |
Uh oh!
There was an error while loading. Please reload this page.
Write here your feedback on the install process and the issues encountered or the improvements suggestions.
All reactions