Turning Your Starlink Mini into a Real Telemetry Device - How to bridge Starlink Mini into MQTT and Node-RED for real-time monitoring and automation

Image
  If you’re running a remote station, digital voice system or any kind of modern connected ham infrastructure, your internet link is no longer “just internet” — it’s part of your station. Starlink Mini gives you portable, high-availability connectivity, but out of the box it’s still a black box. You can see “online/offline,” but you can’t easily observe performance, uptime, obstruction trends or state changes in a way that integrates with the rest of your telemetry systems. That’s exactly what the starlink-mini-mqtt-node-red-1 project solves. This project creates a bridge between Starlink Mini, MQTT and Node-RED, allowing you to treat your satellite link like any other piece of instrumented infrastructure in your shack. What It Does The system polls Starlink Mini status data and publishes it into MQTT topics that can be consumed by: - Node-RED - Home Assistant - Grafana - InfluxDB - Custom automation workflows Once it’s in MQTT, it becomes part of your normal telemetry pipeline. Ty...

Raspberry Pi Imager and Trixie 11-24: When Your Custom Settings Just Disappear

 





I just spent a frustrating morning/afternoon trying to deploy a new Raspberry Pi image for testing a script I developed. It should have been simple - flash the latest Raspberry Pi OS Lite (Trixie), configure SSH keys and hostname in the Imager, boot them up, and get to work. 

Except none of my customization settings actually applied. At all.

Here's what happened and how I fixed it.

The Problem


I was using Raspberry Pi Imager v2.0.0 to flash the latest Raspberry Pi OS Lite (64-bit) Trixie release dated 2024-11-24. I went through the OS customization dialog like I always do:

Set a custom hostname
Configured my SSH public key for authentication
Set my timezone
Configured WiFi settings
Set my username and password

Clicked "Write," waited for it to finish, popped the SD card into a Pi, and... nothing. The Pi booted to the initial setup wizard asking me to configure keyboard, mouse, and locale. All the customizations I'd carefully entered were completely ignored.

I tried again thinking I'd made a mistake, I tried deleting preferences, using different computers, older versions of Raspberry Pi Imager, etc. Same results. The customization settings simply weren't being applied on first boot.

What's Actually Broken

After some digging and finding GitHub issue #1320 on the rpi-imager repository, I learned I wasn't alone. Multiple people are reporting the same problem specifically with:

1. SSH public key authentication - When you choose to use SSH keys instead of password auth, it                  seems to break the entire customization process
2. Hostname settings - Not being applied
3. Username configuration - Ignored
4. Locale settings - Timezone and keyboard layout not set

The weirdest part? If you use SSH password authentication instead of public key, everything works fine. But I don't want to use passwords - that defeats the entire point of having SSH keys.

Apparently this is related to Raspberry Pi OS moving from their custom initialization system to cloud-init. During this transition, something broke in how the Imager's customization settings get processed by newer Trixie images. The old custom rpi-imager stuff was stripped out in preparation for cloud-init, but cloud-init support isn't fully implemented yet. So we're in this awkward in-between state where neither system works properly.

The Fix: Roll Back to October 1st Release

The solution is surprisingly simple: use an older Trixie image that still has the working customization system.

Instead of using the latest image (2024-11-24) that the Imager downloads by default, manually download the October 1st, 2024 release of Trixie:

Direct download link:
https://downloads.raspberrypi.com/raspioslitearm64/images/raspioslitearm64-2025-10-02/

(Yes, the folder says 2025-10-02, but the image inside is dated 2024-10-01. Don't ask me about the date confusion - it's probably a mirror/upload timestamp thing.)

How to Use the Older Image

Option 1: Use Custom Image in Imager

1. Download the October 1st image from the link above
2. Open Raspberry Pi Imager
3. Click "Choose OS"
4. Scroll to the bottom and select "Use custom"
5. Point it to your downloaded image file
6. Configure your customization settings as normal
7. Write to your SD card

Your settings will actually apply this time.

Option 2: Direct Download and Flash

If you're comfortable with command-line tools or other imaging software:

# Download the working image
wget https://downloads.raspberrypi.com/raspios_lite_arm64/images/raspios_lite_arm64-2025-10-02/2024-10-01-raspios-bookworm-arm64-lite.img.xz

# Extract it
unxz 2024-10-01-raspios-bookworm-arm64-lite.img.xz

# Flash with dd (replace /dev/sdX with your actual SD card device)
sudo dd if=2024-10-01-raspios-bookworm-arm64-lite.img of=/dev/sdX bs=4M status=progress conv=fsync

Then manually configure your settings by editing files in the boot partition before first boot, if you prefer that approach.

What I Actually Did

I downloaded the October 1st image, used it as a custom image in Raspberry Pi Imager v2.0.0, and configured all my settings:

Hostname: testpi
SSH: Public key authentication (copied my Ed25519 public key)
Username: My standard deployment username
WiFi: My network credentials
Locale: America/Los_Angeles timezone, US keyboard

Wrote it to the SD card, popped it in the Pi, powered it up, and... it worked. All settings applied correctly. The Pi booted directly to a configured system, SSH was enabled with my key, hostname was set, everything was ready to go.

This is how it's supposed to work.

What About Updates?

You might be wondering: "If I use an older image, won't I be out of date?"

Not really. Once the Pi boots and you can SSH in, just run:
sudo apt update
sudo apt upgrade -y

This brings the system completely up to date with the latest packages, including kernel updates. You'll end up at the same patch level as the November image, but with working customization.

The October 1st image is only about a month older. It's not like we're using something from last year.

Why This Matters for My Setup

I'm deploying multiple Raspberry Pis for testing and infrastructure builds. Each one needs:

A unique hostname for DNS
SSH key authentication only (no passwords)
Proper timezone settings for logging
Automated deployment without manual intervention

When the customization doesn't work, I have to:

1. Boot the Pi with a monitor and keyboard attached
2. Go through the setup wizard manually
3. Enable SSH
4. Add my public key to authorized_keys
5. Configure hostname
6. Set timezone

Multiply that by five or six Pis and it's an entire afternoon wasted on manual configuration that should have been automated.

With the October 1st image, I can flash all the cards in advance, configure them all identically (except for hostnames), and then deploy them to their locations. When they boot up, they're ready to go. This is especially important for remote deployments where I don't have easy physical access.

The Bigger Picture

This is a great example of why I always keep older, known-working images around. When new releases come out, I don't immediately trash the old ones. I test the new release first and if something's broken, I roll back.

It's also why I'm a bit wary of major OS transitions. The move from Bookworm to Trixie is generally solid, but this customization issue shows that complex migrations (like moving to cloud-init) can introduce unexpected breakage.

I'm looking forward to proper cloud-init support. Cloud-init is the standard for automated cloud instance provisioning, and having it on Raspberry Pi OS will be great for automated deployments. But right now, we're in the transition period where the old system is partially removed and the new system isn't fully implemented.

When Will This Be Fixed?

According to the GitHub issue, the Raspberry Pi team is aware of this and is working on proper cloud-init support. Once that's fully implemented and tested, the Imager customization should work reliably again.

Until then, the October 1st image is your friend.

Other Reports

The GitHub issue (#1320) has multiple people confirming this problem:

Settings completely ignored when public key SSH is selected
Initial setup wizard appearing when it shouldn't
Hostnames reverting to default
Locale settings not applied

It's not just me. This is a real, reproducible bug affecting the latest Trixie release when used with Raspberry Pi Imager v2.0.0.

Some people also report issues with the Imager itself, where certain combinations of settings cause failures. The SSH public key authentication option seems to be the main trigger - if you use password auth instead, things mostly work. But that's a workaround, not a solution.

My Recommendation

Until this gets fixed in a newer Trixie release:

1. Download the October 1st Trixie image and keep it locally
2. Use it as a custom image in Raspberry Pi Imager for any new deployments
3. Configure your customization settings as normal - they'll actually work
4. After first boot, run apt update/upgrade to get current packages
This gives you a working, up-to-date system without the hassle of manual configuration.

And if you're doing any kind of automated or remote deployment where you can't easily fix configuration issues after the fact, this is even more critical. Don't trust the latest image right now - use the October 1st release.

The Links You Need

Working Trixie image (2024-10-01):
https://downloads.raspberrypi.com/raspioslitearm64/images/raspioslitearm64-2025-10-02/

GitHub issue tracking this problem:
https://github.com/raspberrypi/rpi-imager/issues/1320

Hopefully this saves someone else the morning/afternoon I lost figuring this out. When the Raspberry Pi Imager's customization settings mysteriously stop working, it's not you - it's a known bug with the latest Trixie release. Roll back to October 1st and you'll be fine.

73
 
P.S. - If you're reading this months from now, check if there's a newer Trixie release available. The cloud-init implementation might be finished by then, and newer images should work properly. But for now, October 1st is the way to go.


Comments

Popular posts from this blog

How To Get Precise Time Outside Your Shack

How To Set Up Your Own Remote Station

How to Put Your AllStar Node on 44Net Connect

Why You Might Want To Set Up Your Raspberry Pi Internet Web Server on 44Net

Building a Secure Web Portal on 44Net Without VPN Headaches

A Non-Programmers Guide on How To Use AI to Write Your Own Custom Ham Radio Computer Applications

Why You Should Use SSH Keys Instead of Passwords on Your Raspberry Pi

Internet Remote Software Defined Radio (SDR) Receivers – A Starter Guide

Automated Server Failover for Remote Stations

Wifi Network Clock Review: Great Features <$40 With A Security Concern

Ham RSS News Feeds

Amateur Radio Daily

ARRL News

Zero Retries