Why Won’t You Power Off?

                       

        "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!

How a Spy Pixel Crashed Into My Friend's Vacation

 

         So it goes.

 

A friend of mine, a freelancer, recently went on a much-deserved vacation. Like most of us in today's always-on culture, she left an automated "I'm away" response on her email.

One day, she received a message from a client. Curious whether it might be urgent, she opened the email — but chose not to reply. A few hours later, she received another email from the same client:

"I know you opened our email. Can you please answer to our job offer?" 

Creepy material right there.

How in two hecks did the client know that she had opened their email and read their message, without her replying? The answer is tiny, technically invisible, and fascinating — a spy pixel!

 

                 There's totally a Spy Pixel there, trust me bro.

 

---

But what are they?

 

A spy pixel is a tiny, invisible image that gets embedded in emails. Usually just a 1x1 pixel, fully transparent, and basically impossible to spot by just looking at the email.

The moment your email app loads it — boom — it sends a signal back to whoever embedded it.

What's in that signal? Well, I'm glad you asked. It can include, at the very least:

- Your IP address (which can give away your rough location),

- The exact time when you opened the email,

- Your device type, OS, maybe even your browser,

- Whether you opened it multiple times or forwarded it to someone else.

 Here's her little spy:

<img src=3D"https://app.frontapp.com/api/1/noau= th/companies/5faa110782efdfc2d885/seen/msg_uugvds6/0/0a5b6123.gif" alt=3D"S= ent from Front" aria-hidden=3D"true" style=3D"width: 1px; height: 1px">

That image isn't there to show anything. It's there to quietly send metadata back to the pixel's creator.

---

Where and when are these buggers used?

 

You might be surprised — they're everywhere in digital communications. Here are some common uses:

• Email newsletters and marketing campaigns, to track open rates,

• Sales outreach tools, for engagement tracking,

• Transactional emails, just to confirm delivery.
  

But also in more questionable cases:

- Stalking or surveillance by controlling or manipulative individuals,

- Aggressive sales tactics, that cross boundaries (case in point: my friend),

- Phishing campaigns, to confirm which addresses are active.

And, for the most part — barring some exceptions — this stuff is completely legal.

---

Fear-mongering

 

I love some areas of cybersecurity, but I'm definitely not a fan of the constant fear-mongering I see everywhere.

This stuff is genuinely cool! And interesting. And did I say cool? But it has its downsides. Serious ones, especially when you are on the receiving end of it. Most people don't know these pixels exist, let alone how to block them.

 

                         I B Nautghy!

 

---

Action.

 

Are we allowed to lie to protect our privacy or avoid annoying people? I think we are. But that becomes hard when someone throws back:

• "We know you were at your computer yesterday."
•  "You say you didn't see our message, but we know you did."
• Or you try to browse anonymously, and the pixel exposes your location

This little guy can enable social engineering attacks by confirming your device type, when you were online, even whether you forwarded the email.

And, all that advice about "not clicking suspicious links"?

You didn't! You just opened the email. And that's all it takes

---

You gotta fight, for your right. (to party)

 

Thankfully, we've got defenses. Here are some of the basics:

• Block remote images in your email client (Thunderbird, ProtonMail, and others do this by default),

• Use privacy-focused email services that prevent images from auto-loading,

• Browser plugins like uBlock Origin can help if you're using webmail,

• Use a VPN to mask your IP and location,

• Or go hardcore and view emails in plain text only.

Just a heads-up: many mobile apps load images by default unless you manually turn that off. And in some cases, you can’t.

 

         Oops...

---

DIY Spy Pixel.

 

Want to try one for fun? Here’s a simple experiment:

1. Host a transparent 1x1 GIF or PNG on your own server.

2. Log image requests using your server (e.g., Apache, nginx, or a basic Flask script).

3. Add this to an HTML email:

<img src="https://yourdomain.com/tracker.gif" width="1" height="1" />

1. Send it to yourself.

2. Open it and check your logs — you'll probably see something like:

   • IP address

   • User-Agent string (your OS, browser, etc.)

   • Timestamp

Research how to do this stuff if it’s new to you. It’s a great little exercise and can be done in an afternoon.

---

Beyond the Pixel

 

Our tiny spy pal isn’t alone.

There’s a whole army of sneaky tools out there:

• Link shorteners with tracking redirects,

• Invisible iframes embedded in webmail,

• Email fingerprinting, using subtle code to track opens,

• Read receipts in platforms like Slack, Notion, and LinkedIn.

Once you notice this stuff, it’s everywhere.

---

A final dot.

Have fun exploring. Even if this isn't your favorite cybersec topic, it's a fun rabbit hole and might lead you to some unexpected discoveries.

 

And as always — enjoy the ride.