I’m running Ubuntu 24.04 on an ASUS Zenbook and started experiencing several issues after upgrading to kernel 6.17.0-29-generic.
The symptoms were:
Wi-Fi disappeared completely.
Brightness controls were no longer available.
The touchpad stopped working.
The built-in keyboard behaved strangely after logging in.
Everything seemed normal on the login screen, but problems appeared once the system booted into the desktop environment.
After some troubleshooting, I booted into an older kernel from the GRUB menu and found that kernel 6.17.0-22-generic works perfectly. As soon as I boot into 6.17.0-22, all functionality returns Wi-Fi, brightness control, touchpad, and keyboard.
I think the issue is related to a regression or compatibility problem introduced in kernel 6.17.0-29 rather than a hardware failure, For now I’m using 6.17.0-22 as the default kernel and have temporarily prevented automatic kernel upgrades until a fix becomes available.
How will you know that a fix is available if you prevent kernel upgrades?
I reckon that you need to prevent automatic removal of the working kernel.
I wrote a Tip & Trick about this here - hopefully it will help you navigate your kernel regression.
Approx a year ago, I lost Bluetooth with a kernel regression and I had to allow 4 or 5 new kernels to arrive until the regression was repaired.
I just noticed that you are using Ubuntu 24.04 LTS, it may be worthwhile to try a live session with Ubuntu 26.04 LTS (recently released with kernel 7.0.0-14)
After further digging, the issue appears to have been related to the NVIDIA graphics driver rather than the kernel itself, upgrading from NVIDIA driver 535 to 580 resolved the issue and the system is now running normally on newer kernels.
Great! I think you should report a bug against ubuntu-drivers-common then:
ubuntu-bug ubuntu-drivers-common
IMHO this should not have happened and reporting the issue could save some other folks from being hit by it. That command above also collects relevant system information and attaches it to the report, so it’s best to run it on the system that exhibited the issue.