Didn't try yet... will let you know tomorrow! It's past midnight here....
Yeah... me too...
See, I will probably do all this bios messing around a couple of months later. I have a couple of major conferences coming up, and two journal articles due soon, and I don't want to mess up my fMRI image files, or the processed data I have! Sure, I can take a backup, and it will preserve the data. But I need a functioning UNIX shell environment to work with them, and if something fucks up massively it will set me back a good few days to get everything back up and running again.
Plus, I am obsessive-compulsive about having a functioning computer around. Since the laptop is my only haven for the time being, I would lose my sleep (and peace of mind) if things get complicated at this point.
So... much as this backlight thing is bugging me... I think having to deal with a "system shock" (pun intended) will bug me a hell of a lot more!!!
Anything patched with intel-microcode is irreversible AFAIK. Because yes, those are patches to the CPU's micro-code. If that is what caused your issue there may be nothing you can do.
I can fully understand it - despite not depending on it for my income - I rather stay up all night before going into a 12h shift at work before having my Laptop not functioning
Fixed the headache by reinstalling the whole damn thing from a scratch! @Th3Z0ne Live boot showed that the controls work, so I figured reinstalling would work! And it did! Except I haven't the heart to use 'prelink' anymore... I'm pretty sure prelinking screwed shit up!
Anyone here using prelink? I know Fedora enables prelink out of the box, and there's been arguments over whether it is worth doing so?
@CaptainChaos Just FYI, while I was reinstalling it occured to me to check your theory. So, after I reinstalled Mint 18.1, which comes with kernel 4.4.x, I checked that Killer 1535 was "unavailable". So, then I updated the highest version of Kernel visible from Mint's update manager, which is 4.10.0.20. Reboot, and guess what? Killer 1535 was still unavailable!
I had to get the firmwire on my own, then modprob to activate the wireless card! But at least it works!!! The lesson that was hard learned, however, is that taking the risk of doing a kernel update from the version the distro comes with to the latest edition of kernel it allows access to, in this respect, does nothing to solve the problem.
You are right! The microcode updates are meant to fix vulnerabilities in the CPU firmware during early boot. They are the exact opposite of irreversible. The microcode updates are stored in a file (/boot/intel-ucode.img), and are not applied to the BIOS or CPU. When GNU/Linux boots up, it loads the contents of the firmware file to the CPU. When your computer powers off, the CPU is cleared and the update will need to be applied again. The reason firmware updates work like this (instead if being permanently applied) is because it can brick the CPU if there is a problem flashing the updates.They are applied every time the computer boots, and if you simply remove the updates (by selecting the "do not use this" option in driver manager) the CPU will revert back to using the original firmware.