 |
In 0009879:0022032 you got already told that your bug report is not actionable to them (Kali team) so why create exactly the same again? Kali team doesn't maintain Kernel / driver, you would need to talk to the Kernel devs instead. |
 |
Thank you for the clarification. I understand that the Kali team does not maintain the ASUS hardware support itself, and that the relevant component is the Linux kernel and its ASUS Armoury driver. I am not claiming that this is necessarily a Kali-specific bug. I reported it because I am running the Kali kernel and the problem is reproducible there. The important observations are:
Therefore, I would like to clarify where the missing support belongs. Could you please confirm whether the Kali kernel currently contains the necessary ASUS Armoury kernel support for the G533QS power limits? If the required support is not present in the kernel itself, I understand that this would need to be addressed at the kernel level rather than in a Kali-specific package. I can provide additional kernel logs, sysfs output, or hardware information if needed to determine exactly where the problem occurs. Thank you. |
|
|
I don't think this is a support forum. They are only tracking confirmed bugs or feature request for Kali specific packaging here. |
|
|
I understand that this is not a support forum, and I am not asking for general troubleshooting help. I submitted this as a reproducible Kali package/kernel bug, not as a support request. The report contains the exact hardware model, kernel and package versions, reproducible steps, and the exact failure reported by the kernel:
This is a reproducible failure of the power-limit functionality with the Kali kernel, rather than a question about how to configure or use the system. I understand that the root cause may ultimately be in the Linux kernel rather than in a Kali-specific package. I am therefore asking only whether this is considered a Kali kernel/package issue or an upstream kernel issue. If such kernel-level hardware issues are outside the scope of this tracker even when they are reproducible with the Kali kernel, please confirm that explicitly so I can understand the correct scope of this report. Thank you. |
|
|
From e.g. 0009839:0021954:
|
|
|
Thank you for the clarification. I understand that the fix needs to come from the upstream Linux kernel. For completeness, I want to document the concrete evidence showing that this is a kernel driver support issue and not a general support question. My system reports: At boot, the kernel reports: The power-limit sysfs attributes are present: However, I also inspected the actual but there is no This is consistent with the kernel driver's DMI-based power-limit matching: the driver cannot find a matching power-limit definition for the G533QS and therefore prints the exact warning shown above. So the issue is now clearly identified: the Kali kernel is loading the ASUS Armoury driver, but the driver does not contain a power-limit definition matching the G533QS board. I understand that Kali does not have the manpower to implement hardware support and that the required change must therefore come from the upstream Linux kernel. I am providing these details simply to document the exact kernel-level reason for the failure. |
|
|
Do we speak to an AI agent here btw.? |
|
|
Yes. I’m using an AI assistant to help me analyze the technical details and communicate them clearly, but the hardware, system information, logs, and test results are from my own G533QS system. I verify the commands and results myself before posting them here. |
 |
You said "Those problems need to be fixed in the upstream Linux kernel. We regularly import new kernel releases." But Kali still has linux kernel 7.1.5 from 2026-07-29. Looking at kernel.org the 7.1 branch has reached EOL (end of life) for a relative long time now. Linux kernel versions 7.2.1-7.2.9 have been released already which I don't understand why Kali don't get them automatically to fix bugs and security issues. I think I don't need to tell a pentesting company how important quick installation of updates is (especially with all the security issues that AI found lately). Are the people in the Kali team who did this before regularly, not working for Offensive Security anymore or what is the reason for this big delay in kernel updates from upstream which fix bugs and security issues? Since we as pentesting company are thinking about switching to another pentesting distro otherwise. And we have invested a lot of money into many Offensive Security trainings for our people which would be a pity. |
|
|
Thank you for the clarification. I understand that hardware support itself needs to be fixed in the upstream Linux kernel. However, this raises another concern about the kernel version currently shipped by Kali Rolling. My system is currently running: According to the upstream Linux kernel project, the 7.1.y series reached end-of-life with 7.1.13 on September 2, 2026, with users explicitly advised to move to the 7.2.y series. The upstream kernel has already reached 7.2.9, released on October 3, 2026. However, the Kali package tracker still shows linux 7.1.5-1kali1 as the current Kali kernel package. So could you please clarify why Kali Rolling is still shipping 7.1.5 more than a month after the 7.1.y branch reached EOL, while multiple newer 7.2.y stable releases are already available upstream? I understand that Kali cannot fix hardware support which is missing from the upstream kernel. But Kali's own statement says that new kernel releases are regularly imported. In this case, the delay is important for both hardware support and security maintenance. Could you please explain whether the 7.2 kernel is currently being prepared for Kali, and whether there is a specific technical reason preventing it from being imported into kali-rolling? For users relying on Kali Rolling as a security-focused distribution, remaining on an EOL upstream kernel for an extended period is understandably concerning. Thank you. |
|
|
I also checked the package state directly with APT on my fully updated system.
The version table contains only Therefore, this is not a case where the system simply has a pending kernel upgrade that I have failed to install. APT currently considers 7.1.5-1kali1 to be the newest available Kali kernel package. This is why I am asking whether the delay is due to the Kali repository/package build process or whether a newer kernel is already being prepared but has not yet reached kali-rolling. |
|
|
Good afternoon! Why close it when I haven't received any answers? |
|
|
"Dear Team, Please be advised that the email I received was blank. Kindly resend the response at your earliest convenience. Thank you." |
 |
@sokoritv We don't fix or troubleshot hardware related issues. New kernels land on a regular basis, just need to be patient, maybe a new kernel fixes your issue. If you need a workaround you have to find it on the Internet. @tired_of_signups There are new kernels released all the time. We wait for it to be packaged in Debian. Then we package it in Kali, when time allows. We are a small team with many things to do. You can expect a new kernel for every new Kali release, so every quarter, that's what usually happens, but no hard promise either. On that note, please leave this ticket closed. Thanks. |
- Anonymous
