Bench Notes

A plain sheet for the four survivors on this bench. For each one: what it runs, and one test you can run yourself. No special tools, no bench required. If a test disagrees with me, trust the test.

1. Note 3 — 2013 (SM-N900, codename ha3g)

What it runs: an unofficial LineageOS 22.2 (Android 15) community port. Official LineageOS stopped this chip at Android 7.1, so somebody outside Samsung keeps it alive.

Where its clock actually is: the battery, not the ROM.

Test (cell, no root): charge to 100%, turn on airplane mode, lock the screen, leave it one hour. Check the number. A few percent is normal. A double-digit fall at idle means the cell is your limit, not the software. The cells still sell new, so this is a part you replace, not a death sentence.

2. Xperia Z5 Compact — 2015 (E5803, suzuran)

What it runs: two builds. LineageOS 23 (Android 16) and an older Nougat. The daily spot goes to the older one by choice, not because 16 failed.

Where its clock actually is: nothing broke. Preferring a build is not a fault.

Test (camera dead?): open the camera app on both builds. Fails the same way on both, it is the hardware. Works on one, it is software.

3. The survivor — Samsung NP300E5A, 2011

What it runs: still unconfirmed. What I have seen: alive with hinge and keyboard damage, so it survived being opened. That itself breaks the pattern of the machines that did not.

Where its clock actually is: the display cable, worn worse by a hinge that creases it at the same fold every close. The cable is the symptom; the hinge is the cause.

Test (dark, flickering, or blank screen): watch the screen while you slowly open and close the lid. – Flicker or blanking that tracks the lid –> the cable through the hinge. – Static lines that ignore the lid –> the panel itself. – Image only visible when a flashlight hits it at an angle –> backlight or fuse.

4. Oldest — LG X130 netbook, 2009

What it runs: a 32-bit x86 Linux, if anything. The Atom N270 is 32-bit only; it cannot run a modern 64-bit build.

Where its clock actually is: not the hardware. The Linux world stopped shipping 32-bit x86. Ubuntu dropped i386 years ago, and Debian dropped it with Trixie.

Test (is your OS still shipping?): open a terminal and run uname -m. If it says i686 or i386, and your distro no longer publishes updates for that architecture, then the operating system is the countdown, not the netbook.

---

Four machines, four countdowns, none of them sitting where the symptom points. That is the whole lesson: find the part with a limit, not the part that is complaining.

If any read here is wrong for your machine, say so and I will correct it. The test wins over me.

The install is not the artifact.

Short version: if an old phone only runs, you can still lose it. The running install is not a backup. Keep the flashable file, the recovery, and a note.

Here is the failure worth sitting with. Someone ports a current Android onto a 2013 phone. It boots. It is genuinely good. You flash it, and it is your daily for a year.

Then the maintainer stops. Or the file host dies. Or you factory reset on a bad day and the download link is gone.

Now the phone is stock, and the build that made it usable exists nowhere you can reach. Nothing broke. You kept the running install and never kept the file.

What I would keep for every old device, on a machine that actually gets backed up:

1. The ROM zip, exactly the build you are running. Not the newest one. The one that works.
2. The recovery image you flashed it with. Same rule.
3. The firmware or vendor base, if the ROM needs one. This is the one people forget, and the one that is hardest to find again.
4. A one page note: device, codename, base version, the exact flash tool and version, where each file came from, the date. Plain text, one page, in the same folder as the files.

Why it matters: a phone you can reflash is repairable. A phone whose ROM is gone is a paperweight the day its storage or its OS misbehaves, and it usually misbehaves on a day you needed it.

It costs about a gigabyte per device. The regret costs more.

Same logic for one flash in the other direction: before you flash anything, move what is on the phone off the phone. The install is not the artifact, and neither is the data sitting only in internal storage.

Old hardware does not die of old age. It dies of missing files.

Have a device like this sitting in a drawer? Free first read, no charge, no pitch: [email protected]. Tell me the model and what it does now.

A 2015 Xperia came to the bench stuck in a bootloop. Someone had tried a modern build over an old 5.1.1 stock base. The phone never came back up.

On the cable, it wasn't dead. The flash tool could still reach it. But where the device name should have been, the log printed Unknown and a loader date. That line is where most people give up and order a new phone.

It doesn't mean the phone is dead. It means the tool couldn't handshake the phone's loader. The phone is usually right there, in flash mode, waiting. You fix the handshake, not the phone.

The ladder that brought it back, in order:

1. Flash-mode discipline. The phone only listens if it enters the mode properly: cable in while holding volume down, green light, nothing else running. Sounds too dumb to matter. It's the first thing to rule out.

2. The USB side. Old flash-mode drivers go stale or hide as ghost entries. Delete the unknown ones in Device Manager, rescan, reinstall the flash-mode driver. A bad driver looks exactly like a dead phone from the chair.

3. The era rule. Flash tools and firmware bases age together. An old loader won't handshake with a current tool generation. Here: the old base needed Flashtool 0.9.18.6. The Nougat-era firmware needed 0.9.36.0. Match the tool generation to the firmware generation and the handshake comes back.

Once the old full-stock base was back, the phone stopped being a brick. Nougat went on. Then a current-era build went on clean. Both boot. Which one it ends up living on is a taste question, not a rescue question.

The order I'd tell anyone holding a bootloop: full stock first, from the right era, then climb. Don't stack a modern build on a broken old base. And don't take the tool's word about the phone's health. It can't read what it can't handshake.

If you're stuck on a device right now, tell me what it's doing. First read is free.

Andrew, from the bench. paper.wf/andrew-61

Two phones, one bench. One from 2013, one from 2015.

The older one is running a system build from this March. The younger one took a modern install and couldn't live there; it's back on an eight-year-old version, where it behaves. Both flashed clean. Only one stayed.

Same bench, three things that actually decide an old phone's fate:

1. Memory. Modern apps and modern systems don't fit in 2GB. No build is clean enough to fix arithmetic. This is the wall that most “it's so slow” complaints are standing in front of.

2. Heat. A hot chip in a small body throttles exactly when you finally ask it for something. More RAM won't fix a hand warmer.

3. The maintainer. A phone stays alive while at least one person still builds for its codename. When the last one stops, the phone dies with good silicon inside. Check this before the calendar: a 2013 model with an active maintainer outruns a 2017 one without.

The order people usually check: the calendar. The order that matters: memory, then maintainer, then heat, then calendar.

This is a pattern off one bench, not a lab. If you're stuck on a device right now, tell me what it's doing. First read is free.

Andrew, from the bench. paper.wf/andrew-61