"Beneath this mask there is more than flesh. Beneath this mask there is an idea, Mr. Creedy."
I recently purchased an old-school Lenovo ThinkPad x260 - a beautiful little tank of a machine. It was in tip top shape: clean chassis, no keyboard shine, and great battery health. So, first things first: wipe Windows off the face of the earth and install Linux (not Arch, btw).
Everything was great ... except for this teeny tiny issue:
Even after shutdown, the laptop stayed warm.
This typically means the system isn’t reaching a full ACPI S5 (soft off) or G3 (mechanical off) state.
...I didn't expect it to have any temperature issues, but I decided to play it safe, and installed lm-sensors, just to be sure. No worries there! The temperature was low, even after running some tests and forcing the CPU to do some work. So, the issue wasn't that it was overheating... perhaps it just wasn't shutting down properly?
After some testing, I confirmed that hypothesis: USB ports were still feeding power. The fan wasn't spinning, and there was no noise or visible lights, but something was still alive in there and refusing to go to sleep.
I tried to issue clean shutdown commands, with shutdown -P now, oldschool init 0, the desktop shutdown button, etc. You name it. Nothing forced the computer to turn off and the battery was still sipping away slowly. Plugging a phone to the USB would charge the phone. You get the picture.
Step 1: Blame the BIOS
I quickly checked the BIOS setup (on this ThinkPad F1 does the trick) and went through the tabs:
- Disabled "Wake on LAN"
- Checked "Intel SpeedStep" and thermal profiles
- Ensured USB always-on charging was off
Note: this did not stop phone charging through USB.
- Even poked at virtualization, secure boot, and power-on behaviors
No luck. I all looked fine an dandy. And yet, the x260 continued to undead itself.
There was a slight mystery in that the power button worked 'strangely'. And by strangely I mean that the computer didn't connect directly when pressing the power button. But the reason was quite obvious. Since the computer was not properly shut down, I couldn't turn it on by just pressing the power button. I had to first keep the power button pressed for long enough to force a hard shut down. Only then did the computer shut down and allowed me to turn it on by pressing the power button.
Step 2: Linux Kernel Parameters, ACPI... huh, no?
So, I guessed I might as well go up a couple of layers and check the OS itself. Maybe the Kernel wasn't handling ACPI (Advanced Configuration and Power Interface) properly.
This led me to go and modify GRUB entries:
# In /etc/default/grub, change the following line:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi=force reboot=pci"
# Then update GRUB (Debian/Ubuntu):
sudo update-grub
...And reboot=hard, reboot=efi
( `acpi=force` forces the kernel to enable ACPI even if it thinks the BIOS doesn’t support it, and `reboot=pci`, `reboot=efi`, ... tell the kernel which reboot/shutdown method to try — in some buggy firmware cases, different paths behave differently
Also, please please and pretty please make sure to back up your current GRUB configuration before modifying it. Bad kernel parameters can sometimes prevent boot. You have been warned)
I also tested power off sequences with systemctl poweroff, shutdown -h now, and halt.
Same result every time: "Bye bye, mate. I'm going into zombie mode."
I found the emergency reset button in the back of the x260, which cleared the battery state - cute. But not the fix either.
Step 3: It's elementary TPM, my dear Watson Reader.
Eventually, buried in a forum post, someone suggested disabling the security chip - also known as TPM (Trusted Platform Module) - in the BIOS.
Interesting. Why would a security chip interfere with system shutdown?
But hey! Let's try it. And try I did. BIOS > Security > Security Chip, and I set it to disabled.
There was the option to switch between intel PTT (Intel's firmware-based implementation of TPM) and discrete TPM.
Boom! Disabling both solved the problem.
No... really. No more zombies in my machine.
So, erm. What was all that about?
Step 4: Read up
TPM and ACPI can be tightly coupled, especially on systems originally designed to work with Windows.
Firmware behavior is often not standardized across vendors, and ACPI implementations are notoriously inconsistent.
When Windows is installed, in this case, it plays nicely with proprietary firmware handling of secure state transitions (shutdowns/hibernation). But Linux? That OS expects firmware to follow spec, not to have it silently ignore part of the validation process.
By disabling the TPM, we cut off whatever interaction was confusing the firmware - and Linux finally does get a say in controlling the power sequence.
Anecdote du jour: did you know that Torvalds once said something nice about ACPI?
"ACPI is a complete design disaster in every way. But we're kind of stuck with it. If any Intel people are listening to this and you had anything to do with ACPI, shoot yourself now, before you reproduce."
It must have been a Monday.
Should you, dear reader, disable TPM on your old machine?
Well, if you don't use full-disk encryption tied to TPM, yes I guess.
If you're using Linux and notice a behavior such as this, then certainly try it.
But if you do rely on TPM for encryption (why do you need to do that nowadays is beyond me) then be careful. TPM often stores or seals encryption keys. Disabling it can make your system unable to decrypt the disk unless you’ve backed up your recovery keys elsewhere.
If you’re still facing power-off issues after all this, check if your BIOS firmware is outdated (I admit that this was my F plan, after all else didn't work... but I can be lazy like that). Lenovo occasionally issues updates that patch quirky ACPI or EC bugs, especially for Linux users.
Alright, that's it for today! I finally am getting my life-work-zen states figured out and aligned, so I'm getting a bit more time to do research and to document my work, which is totally awesome. So I hope to start posting a bit more frequently.
As always, enjoy the ride!
