Raspberry-Pi on marek@mahut.dev

I plugged my AutoSD CI pipeline into my car

Sat, 13 Jun 2026 00:00:00 +0000

Few days ago I built a CI pipeline that flashes AutoSD onto a Raspberry Pi 4 and tests it on real hardware. It builds the image, flips an SD-Wire mux, power-cycles the board through a smart plug, waits for SSH, and runs a pytest suite — on every push. That was the fun part.

This is the sequel, and it has a sillier premise: what if the same pipeline also tested my actual car?

Testing AutoSD on a Raspberry Pi 4 with Jumpstarter

Sat, 30 May 2026 00:00:00 +0000

This started as a weekend project. I had a Raspberry Pi 4, some spare hardware lying around, and a question: could I set up a fully automated CI pipeline that builds an automotive Linux image and validates it on real hardware — end to end, no manual steps — in a single day? And how many club-mates would it take?

The answer is 4, and here’s how it works.

The testbench. SD Wire circled at the bottom — this is what lets the runner flash the card without touching it. Shelly Plug S circled at the top — smart outlet for remote power control.

AutoSD is the CentOS Automotive SIG’s Linux distribution aimed at in-vehicle software. It’s an ostree-based OS with a real-time kernel, built for the kind of reliability requirements you’d find in a car. I wanted a proper test setup: not just “does it boot”, but a fully automated pipeline that builds the image, flashes it to real hardware, and runs a test suite on every single push — no manual steps, no “works on my machine.”

Repurposing My Raspberry Pi 5 (16 GB) for MicroShift

Thu, 08 Jan 2026 00:00:00 +0000

My Raspberry Pi 5 with 16 GB of RAM had been sitting mostly idle for a few months — running the usual homelab suspects, nothing that really pushed it. Then MicroShift caught my eye. A single-binary OpenShift/Kubernetes distro built for edge devices, maintained by Red Hat, targeting exactly the kind of constrained ARM hardware I had on my desk. I decided to give it a proper shot.

Why MicroShift

I’ve been working with OpenShift professionally for a while, and the appeal of having a real OCP-compatible cluster at home — one that speaks the same APIs, uses the same RBAC model, and supports the same operator patterns — is hard to overstate. Alternatives like k3s or microk8s are fine, but they diverge enough that you’re always translating. MicroShift is a subset, not a fork. Anything I test locally maps directly to what runs in production.