identityapproved's blog

Netgear Stora in 2026: a long, painful guide for anyone who finds this plastic curse in a drawer

2026-03-20

Netgear Stora in 2026: a long, painful guide for anyone who finds this plastic curse in a drawer

I spent way too much time making a Netgear Stora boot a usable Linux system in 2026.

It now works.

That is not the same as saying it was worth it.

This post is for the next poor soul who finds one of these things, thinks “nice, old NAS, maybe I can reuse it”, and then accidentally loses several evenings to an underpowered ARM box with a broken software ecosystem, prehistoric bootloader behavior, dead vendor software, misleading old guides, and just enough success to keep you from throwing it into the trash immediately.

So here is the full story:

What the machine is

The Netgear Stora is an old Marvell Kirkwood-based NAS with a vendor stack from another geological era.

By the end of this process, mine was running:

Linux stora 3.10.26-stora #2 Tue Jan 14 00:11:18 MSK 2014 armv5tel GNU/Linux

That one line already tells you most of the problem:

This machine is not “retro but charming.”
It is “retro and hostile.”

The idea

The original plan sounded reasonable:

On paper, fine.

In reality, every single layer fought back.

Step 1: serial console, because of course

The first thing I had to do was attach a USB-to-TTL serial adapter.

That means:

Eventually the serial wiring was correct and I got into U-Boot.

That was the first tiny victory.

The machine booted and showed:

Marvell>>

At that moment it felt like progress.

In hindsight, that was just the machine luring me deeper.

Step 2: old guides are half-right and half-dead

The old OpenStora / Debian install guides are not completely useless, but they are not something you can just follow line by line in 2026.

The rough flow still matters:

But the actual ecosystem around those steps is decayed.

The first big example: the old Debian installer path points to Debian squeeze era images and mirror assumptions.

That means you can get surprisingly far and then hit a wall like:

Which is not your fault. It is because you are trying to use ancient installer components in a modern network reality.

So yes, the guide is useful as a skeleton.

No, it is not a living install guide.

Step 3: TFTP, old U-Boot, and dumb firewall problems

To load installer/kernel images, I needed a TFTP server on my Arch host.

That part sounds easy until you remember:

The actual chain of nonsense looked like this:

  1. U-Boot tried to TFTP boot
  2. nothing loaded
  3. I chased Ethernet link issues
  4. I rebooted the box multiple times
  5. eventually discovered the host firewall was blocking UDP 69
  6. opened that
  7. suddenly TFTP worked

Classic embedded experience:
you spend most of your time fixing infrastructure around the actual task.

Step 4: machine ID nonsense

Once I successfully loaded the installer kernel and initrd into RAM, I hit this:

Error: unrecognized/unsupported machine ID (r1 = 0x0000020f)

That is where the guide says to do:

setenv mainlineLinux yes
setenv arcNumber 2743

Reasonable.

Except on this box, those values appeared to be set in RAM, but the kernel still kept seeing the old machine ID.

So then I had to discover the actual trick:

So this part was not:

“set two variables and continue”

It was:

“set variables, discover they seem ignored, suspect insanity, save environment, reset, retry, confirm the ancient bootloader only respects them after persistence”

That is the kind of machine this is.

Step 5: the original installer path is basically dead

After fixing the machine ID, the old Debian installer could boot.

Great.

Then it wanted package mirrors for squeeze.

Not great.

I tried the archive route. It still failed while downloading installer components.

At that point the message was clear:

This is where the project stopped being “install Debian on old hardware” and became “cross-bootstrap a foreign-arch root filesystem by hand because the official path rotted years ago.”

Again: if your goal is a convenient NAS, this is the moment you should reconsider your life choices.

Step 6: build the system by hand on a USB stick

So I moved the USB stick back to my main machine and built the system manually.

The rough process:

This part was actually more reliable than the old installer.

Not easier.

Just more honest.

At least when it broke, it broke in ways that made technical sense.

Step 7: Bookworm was a trap

My first manual rootfs build used Debian 12 Bookworm.

It booted.

That sounds like success.

It was not.

Bookworm userspace on this old 3.10.26 Stora kernel produced all sorts of subtle breakage. The most annoying one was SSH.

Symptoms:

When I finally forced sshd into foreground debug mode, the real story appeared:

In plain language:

Bookworm booted, but parts of the modern userspace were too new for this ancient vendor kernel.

So yes, Bookworm could boot.

No, Bookworm was not a sane base for this machine.

That entire branch of work got thrown away.

Step 8: rebuild again, this time with Bullseye

So I rebuilt the USB rootfs again, this time with Debian 11 Bullseye armel.

This was the “less modern, less broken” compromise.

That second rebuild involved repeating almost the entire manual process:

This time the result was much better:

At that point the box finally stopped fighting every single login.

Step 9: U-Boot is a petty little goblin

Even after Bullseye booted properly, U-Boot was still annoying.

Problems included:

I eventually got to a stable boot flow by breaking everything into short env vars and using simpler commands.

Then I made the automatic boot path use:

root=LABEL=stora-root

instead of /dev/sda1.

That was one of the most important fixes in the whole project.

Because once I reconnected HDDs, the USB device number changed:

Using the partition label solved the boot-order problem.

That one change made the difference between:

Step 10: internal disks, finally

Once USB root boot was stable, I reconnected the internal drives.

One old disk had an NTFS partition with basically nothing useful on it.

The other had no real partition layout worth keeping.

So I wiped and repurposed them.

The final layout became:

Mounted as:

That part actually went well.

Once you are past boot hell, ordinary Linux storage work feels almost luxurious.

Step 11: low-memory weirdness everywhere

Because this machine has very little RAM, stupid package-management and systemd issues kept appearing.

One especially annoying one:

So I had to enlarge /run via tmpfs.

Again: not hard, but another reminder that this box lives on the edge of what modern-ish userspace tolerates.

Nothing is impossible.

Everything is just more brittle than it should be.

Step 12: firewall pain, because modern nftables was too much too

I wanted the Stora to be LAN-only.

So I first tried nftables.

That failed.

Why?

Because the userspace and the old kernel were once again not a friendly pair.

So I had to switch to:

Then I had the classic mistake:

Eventually it worked and survived reboot.

So yes, the Stora is now LAN-only.

But of course even “just apply a small firewall” became another side quest.

What works now

After all that, the machine now does work.

Current stable state:

Practical things that work fine:

For a LAN-only archive / backup target / SFTP box, it is now finally usable.

What does not work well

A lot.

1. The original installer workflow

Dead enough to waste your time.

2. Modern Debian userspace

Bookworm was a trap on this kernel.

3. Modern service expectations

A lot of newer software assumes newer kernels, more RAM, more support.

4. Package availability on Bullseye armel

Spotty enough to be annoying.

5. NFS / Samba dreams

This is not the easy platform for that if you want a pain-free setup.

6. Timekeeping

The clock is still stupid unless you fix it explicitly.

7. Debugging overhead

Every “small” task becomes layered:

8. Trustworthiness

I would not trust this as a serious primary storage device without strong external backups.

It is a hobby box.

Not a serious platform.

The biggest drawbacks

Here is the real warning section.

The hardware is old

Not “vintage cool.”
Just old.

The kernel is old

And tied to this platform in ugly ways.

The bootloader is ancient

And serial interaction is fragile.

The software ecosystem is partially dead

You are standing between:

The effort-to-value ratio is terrible

If your goal is:

you can get something easier, faster, quieter, safer, and more supportable almost anywhere else.

An old mini PC.
A Raspberry Pi-class board.
A used thin client.
A normal x86 box.
Even a random forgotten laptop is often better.

So was it worth it?

As a learning exercise:

Yes.

I learned or reinforced a lot:

As a practical appliance project:

Mostly no.

This machine consumed far more time than it justified.

The only reason it was worth continuing was because I had already fallen into the hole and wanted to get out with something working.

Who should keep one of these?

Only people who enjoy at least some of this:

If that sounds fun, keep it.

If your goal is simply “I want a little NAS,” this is not a project, it is a warning.

Final recommendation

If you have a Netgear Stora and you are asking:

should I revive this?

My honest answer is:

And if you are not specifically curious about embedded Linux archaeology:

throw it in the trash, or at least donate it to someone who enjoys pain more than you do

Because yes, I got it working.

But the fact that it can be made to work is not the same as saying it deserves to.

If you want, I can turn this into a cleaner publishable blog post with a sharper intro, nicer section names, and a more dramatic ending.

← Back to Home