Yesterday was Wednesday. No meetings, no unusual schedule, just a normal workday and one very optimistic thought: I would set up an Orange Pi Zero 3 in maybe twenty minutes.

That did not happen.

This is the story of the setup before the setup was actually stable. Not the “everything works now” version. This is the part with the microSD card, the long evening of configuration, and the point where I had to admit that starting over was the smartest option.

Part 1: The MicroSD Card Saga

The Setup

I had:

  • 1x Orange Pi Zero 3
  • 1x microSD card
  • 1x Mac
  • 1x Balena Etcher
  • 1x completely unjustified confidence

The plan was simple:

  1. Download DietPi
  2. Flash it to the microSD card
  3. Edit dietpi.txt
  4. Boot the board
  5. SSH in and continue from there

Reality had other plans.

The MicroSD Moment

Flashing the card on the Mac worked fine. The problem started right after that, when I tried to touch the files again.

macOS responded with the usual level of enthusiasm:

The disk you attached was not readable by this computer.

So there I was with a microSD card that:

  • had DietPi on it
  • was no longer useful from macOS
  • could not be edited the way I expected before first boot

That changed the whole workflow. Instead of “flash, tweak, boot,” it became “flash, boot, see what happens.” Later, when things went wrong, the same card became the way back out: remove it, plug it into the Mac, and reflash from scratch.

The Workaround

I did not have a Linux machine nearby, and I did not want to stop for a VM detour just to edit one config file. So I inserted the card into the Orange Pi and hoped DietPi’s first-boot automation would do enough to get me moving.

Luckily, it did.

Part 2: The Long Wednesday Night of Configuration

The First Boot

Card in. Power connected. Ethernet connected. Then the usual small-board suspense where you watch LEDs and pretend you are still calm.

DietPi booted, and to its credit, the automation was actually useful. The settings I cared about were already close to what I wanted:

AUTO_SETUP_LOCALE=en_US.UTF-8
AUTO_SETUP_TIMEZONE=Europe/Riga
AUTO_SETUP_NET_ETHERNET_ENABLED=1
AUTO_SETUP_NET_WIFI_ENABLED=0
AUTO_SETUP_NET_HOSTNAME=orangepi

That was the first good surprise of the day. No manual edit from the Mac, no disaster on first boot.

Installing Pi-hole Late in the Evening

By evening, the project had quietly turned into a full systems session.

The commands were simple enough:

ssh root@orangepi.local
dietpi-config
dietpi-software

The actual work was not simple. I was going through the basic setup, installing Pi-hole, sorting out upstream DNS, and making sure the machine was not just reachable but usable.

At one point, it felt like I was almost done.

I was not done.

The DNS Test

This was the moment where the setup turned from “normal install” into “long evening debugging session”:

nslookup example.com <local-dns-server>
REFUSED

That one word cost time.

What followed was a long loop of checking services, verifying what DietPi had installed, confirming that the resolver path was really complete, and fixing the pieces that were only half-configured. Nothing about it was especially glamorous. It was just a slow march through infrastructure reality.

Eventually the test stopped failing, and that mattered more than elegance.

Part 3: The SSH Access Problem

The Next Login

Later, when I tried to reconnect, the board was clearly still alive. Some services were responding. The system had not crashed. But SSH was suddenly no longer cooperative.

ssh root@orangepi.local
Permission denied, please try again.

Again:

Permission denied, please try again.

This is the kind of message that looks small until it happens on a headless device you are trying to trust.

The Investigation

What made it annoying was that the machine was not dead. Enough of it worked to make the failure feel personal.

  • the board was online
  • services were running
  • web interfaces responded
  • SSH was the part that stopped being dependable

That is a bad combination. A machine that is half-accessible is harder to reason about than one that is fully broken.

The most likely explanation was simple: somewhere during setup, the access state had changed in a way I no longer trusted. I could keep digging, or I could stop pretending this was still a clean system.

Part 4: Starting Over

The Decision

This was the hard part, mostly because restarting always feels like admitting defeat.

But by that point the math was obvious:

  • keep debugging a system with uncertain access
  • or spend twenty-something minutes reflashing the card and get back to a known state

I chose the second option.

The Process

This was the reset loop:

  1. Power off the board
  2. Pull out the microSD card
  3. Put it back into the Mac
  4. Open Balena Etcher again
  5. Flash a fresh DietPi image
  6. Reinsert the card
  7. Boot again
  8. Reconnect over SSH

Nothing about it was clever. It was just effective.

And this time, it worked the way it should have.

Part 5: Where the Day Ended

After the reset, the setup was much calmer. Reinstalling the basic pieces went faster because the path was already familiar and, more importantly, the machine was back in a state I could trust.

That was the real outcome of Wednesday. Not just “the board works,” but “the board works and I understand why.”

The audio part turned into its own separate problem, so I am leaving that for another post. This one is only about the first chapter: the SD card loop, the long evening configuration session, and the decision to wipe the card and begin again.